Las pistas del timeline y qué mide cada una

Un perfil se lee de arriba abajo y no de izquierda a derecha. Las pistas superiores describen el resultado —qué vio el usuario, cuándo, y a qué ritmo— y las inferiores describen la causa —qué código se ejecutó, qué recursos llegaron, qué hizo el compositor—. Leer un perfil consiste en encontrar el instante malo arriba y bajar en vertical por esa misma columna de tiempo hasta encontrar quién lo produjo. Quien empieza por el gráfico de llamadas se pierde; quien empieza por el resultado casi nunca.

La vista general y el rango

En la parte alta hay una vista comprimida de toda la grabación con capturas de pantalla, una silueta de actividad de CPU coloreada por tipo de trabajo y otra de red. Su función no es informar sino seleccionar: arrastrando sobre ella se acota el rango que muestran todas las pistas de abajo. Todo lo que hagas después opera sobre ese rango.

La costumbre correcta es acotar pronto y agresivamente. Un perfil de doce segundos con el problema en un intervalo de trescientos milisegundos es ilegible hasta que reduces el rango a esos trescientos milisegundos, momento en el que se vuelve obvio. Las capturas de pantalla de la banda superior son la guía para encontrar el instante: se ve dónde la pantalla estaba en blanco, dónde apareció el contenido y dónde se quedó congelada.

Las pistas, de arriba abajo

Fotogramas. Una caja por cada fotograma presentado, con su duración. Es la pista que traduce todo lo demás a la única unidad que percibe el usuario. Un fotograma verde y estrecho es normal; uno ancho es un salto perceptible; un hueco es un fotograma que no llegó a presentarse. Al pasar por encima aparece la miniatura de lo que se veía. Empezar aquí es lo que impide construir teorías sobre trabajo que no molestaba a nadie.

Animaciones. Los intervalos en los que el navegador estaba ejecutando animaciones que él mismo gestiona. Sirve sobre todo para comprobar una hipótesis muy concreta: si la animación aparece en esta pista, la gestiona el motor y puede estar en el compositor; si no aparece y sin embargo algo se mueve, el movimiento lo está haciendo código en el hilo principal, que es una situación completamente distinta.

Tiempos. Los hitos de la carga y tus propias marcas y medidas. Aquí aterrizan las llamadas a la API de rendimiento y las pistas personalizadas. Es la pista que convierte un perfil anónimo en un perfil anotado con el vocabulario de tu aplicación.

Interacciones. Una caja por cada interacción del usuario, desde la entrada hasta que la respuesta se presenta en pantalla. Es la pista de la que sale el diagnóstico de capacidad de respuesta, y su relación con la de fotogramas es directa: una interacción larga cuya caja termina mucho después del clic es exactamente lo que el usuario percibe como “no responde”.

Saltos de disposición. Marcadores en los instantes en que el contenido se movió sin que el usuario lo pidiera. Al seleccionar uno, el panel indica qué elementos se desplazaron, que es la información que convierte una métrica abstracta en un arreglo concreto.

Red. Las peticiones dibujadas sobre la misma escala de tiempo que todo lo demás. Esta es la ventaja de tenerla aquí en lugar de en su panel: se ve la relación temporal entre la llegada de un recurso y el trabajo que dispara. Un script que llega en el segundo dos y produce cuatrocientos milisegundos de ejecución en el segundo dos coma uno es una historia que ningún panel por separado cuenta.

El hilo principal. El gráfico de llamadas del hilo donde se ejecuta tu JavaScript, el cálculo de estilos, la disposición y la construcción de la lista de pintado. Es la pista más densa y la que responde la pregunta “quién lo hizo”. Tiene lección propia por su tamaño.

Rasterización, compositor y GPU. El trabajo que ocurre fuera del hilo principal: convertir la lista de pintado en píxeles, componer las capas y presentar. Aparecen en pistas separadas porque son hilos separados, y esa separación es la clave de por qué algunas animaciones no se bloquean cuando el hilo principal está ocupado.

Trabajadores. Cada worker activo tiene su propia pista con su propio gráfico de llamadas. Ver trabajo ahí es la confirmación de que la descarga a un hilo secundario está funcionando; ver la pista vacía mientras el hilo principal está saturado es la señal de que el worker se creó y no se usa.

El recorrido vertical

El método de lectura consiste en cuatro movimientos, siempre en el mismo orden.

Uno: encontrar el instante malo arriba. En fotogramas, el fotograma largo. En interacciones, la caja larga. En saltos, el marcador. Si ninguna pista superior muestra nada raro, el perfil no contiene el problema y hay que volver a grabar.

Dos: acotar el rango a ese instante, con margen suficiente para ver qué había justo antes.

Tres: bajar en vertical. En esa misma columna de tiempo, mirar qué hay en red, en el hilo principal, en el compositor. Lo que esté ocupando ese intervalo es el candidato.

Cuatro: subir en el gráfico de llamadas desde la función que consume el tiempo hasta encontrar el marco que tú controlas. La hoja del árbol suele ser una función de una librería o del propio navegador, y no es accionable. El primer marco de tu código en el camino sí lo es.

flowchart TB
a[Pista de fotogramas o de interacciones] --> b[Instante malo localizado]
b --> c[Acotar el rango al instante]
c --> d[Bajar en vertical por la misma columna]
d --> e{Que ocupa ese intervalo}
e -->|Red| f[Recurso tardio o bloqueante]
e -->|Hilo principal| g[Tarea larga de script o estilo]
e -->|Compositor o GPU| h[Capas o rasterizado]
e -->|Nada visible| i[Espera externa o proceso ajeno]
g --> j[Subir en el arbol hasta tu propio codigo]
style a fill:#cba6f7,color:#11111b
style c fill:#89b4fa,color:#11111b
style f fill:#f9e2af,color:#11111b
style g fill:#f38ba8,color:#11111b
style h fill:#fab387,color:#11111b
style i fill:#94e2d5,color:#11111b
style j fill:#a6e3a1,color:#11111b

La rama de “nada visible” merece atención porque desconcierta: un hueco en el que el navegador no hace nada y sin embargo el usuario espera. Las causas habituales son que el trabajo está en otro proceso —el proceso del navegador, no el de la página—, que el sistema operativo tenía la CPU ocupada con otra cosa, o que se está esperando una respuesta de red que no aparece porque no la capturaste. Un hueco no es una ausencia de problema, es un problema fuera del alcance de esta grabación.

El panel inferior y las cuatro preguntas

Debajo del timeline hay un panel con varias vistas del mismo rango seleccionado, y cada una responde una pregunta distinta.

La vista de resumen da el reparto del tiempo por categoría de trabajo: script, estilo, disposición, pintado, sistema, inactivo. Es la primera lectura y decide en qué dirección seguir: un reparto dominado por script apunta al código; uno dominado por estilo y disposición apunta al CSS y a los patrones de acceso al DOM; uno dominado por pintado apunta a capas y a efectos caros.

La vista de abajo arriba agrega el tiempo por función sin importar quién la llamó, y responde “qué función consume más tiempo en total”. Es la que encuentra la función pequeña llamada diez mil veces, que en el gráfico de llamadas es invisible porque cada aparición es un píxel.

La vista de árbol de llamadas agrega desde las raíces hacia abajo, y responde “qué actividad de alto nivel consume el tiempo”. Es la que dice si el tiempo se va en manejadores de eventos, en tareas programadas o en trabajo de arranque.

Y el registro de eventos, cuando la versión lo incluye, lista cronológicamente los eventos individuales, que es útil para contar cuántas veces ocurrió algo más que para medir cuánto costó.