Leer la cascada de un fotograma en el panel de rendimiento

El panel de rendimiento enseña el pipeline entero, etapa por etapa, con sus milisegundos y su recuento de elementos afectados. Con el modelo de las ocho etapas en la cabeza, leerlo deja de ser un ejercicio de interpretación de manchas de colores y pasa a ser una lectura directa: esta banda es el recálculo de estilo, mide catorce milisegundos, afecta a tres mil elementos, ahí está el problema. Lo único que hace falta es saber grabar bien y saber qué nombre tiene cada cosa.

Grabar un perfil que sirva

Cuatro decisiones antes de pulsar el botón, y las cuatro cambian el resultado.

Estrangula la CPU. Un factor de cuatro o de seis aproxima tu portátil a un teléfono de gama media. Sin estrangular, un problema real de un usuario puede costar dos milisegundos en tu máquina y no se ve. Es la opción que más veces se olvida y la que más cambia el diagnóstico.

Activa las capturas de pantalla. Cuestan un poco de tiempo de grabación y a cambio permiten correlacionar un fotograma concreto con lo que se veía. Sin ellas, encontrar el fotograma que te interesa dentro de una grabación de ocho segundos es adivinar.

Graba poco. Tres segundos alrededor de la interacción concreta. Una grabación de treinta segundos es imposible de leer y además el propio perfilador distorsiona más cuanto más tiempo lleva grabando.

Empieza a grabar antes de la interacción y para justo después. El error clásico es grabar, hacer la interacción a los cuatro segundos y buscar después. Lo eficiente es preparar la página en el estado exacto, empezar a grabar, hacer la interacción de inmediato, y parar.

Y una precaución con la caché: si estás midiendo renderizado y no carga, deja la caché activada. Si la desactivas, la mitad del perfil es red y te distrae.

Qué es cada cosa

Los nombres de los eventos han ido cambiando entre versiones del navegador, y la correspondencia con las etapas del pipeline es estable aunque cambien las etiquetas.

Todo eso vive en la pista del hilo principal. Y hay dos pistas más que importan tanto como esa:

La pista de fotogramas. Muestra cada fotograma presentado con su duración, y marca los que se han caído. Es el sitio donde se responde la pregunta “¿estoy perdiendo fotogramas?” sin ambigüedad.

La pista de la GPU. Muestra el trabajo del proceso de gráficos. Cuando esta pista está llena y la del hilo principal vacía, el diagnóstico es completamente distinto, y de eso trata el callout.

Una funcionalidad que merece atención propia: al seleccionar un evento de recálculo de estilo, el panel indica cuántos elementos se han afectado; al seleccionar uno de layout, cuántos nodos necesitaban layout. Esas cifras son más valiosas que los milisegundos, porque no dependen del dispositivo. Un recálculo que toca cuatro mil elementos es un problema en cualquier máquina.

El diagnóstico por banda más ancha

Localizado el fotograma lento, se mira qué banda ocupa más y se aplica la tabla.

Domina el JavaScript. El problema está en tu código, no en el renderizado. Se ataca con las técnicas del hilo principal: hacer menos, trocear, mover fuera del hilo.

Domina el recálculo de estilo. Hay demasiados elementos invalidados. Las causas habituales son un cambio aplicado en un ancestro muy alto que se propaga por herencia, una propiedad personalizada modificada en la raíz, o selectores que obligan a reevaluar más de lo necesario. La corrección es acotar el alcance: aplicar el cambio al subárbol que lo necesita en lugar de al documento.

Domina el layout. Hay demasiados nodos participando en el cálculo de geometría. Puede ser porque el documento es enorme, porque el cambio afecta a un contenedor del que cuelga medio árbol, o porque una estructura de maquetación obliga a recorridos caros. La corrección de fondo es reducir el número de nodos.

Domina la pintura. Se están regenerando listas de dibujo grandes o caras. Las operaciones caras de pintura son las de siempre: sombras grandes, degradados complejos, esquinas redondeadas sobre superficies grandes, y sobre todo desenfoques. La superposición de destellos de pintura enseña el área afectada, y muchas veces la sorpresa es que se está repintando la pantalla entera por un cambio de un elemento pequeño.

Domina el commit o la composición. Hay demasiadas capas. Es el caso que se diagnostica en el panel de capas y no aquí.

Un patrón que conviene reconocer aparte: muchos fotogramas seguidos con la misma forma. Si cada fotograma tiene la misma banda de recálculo de estilo de doce milisegundos, no tienes un fotograma lento: tienes un bucle que invalida el estilo en cada fotograma. Casi siempre es una animación implementada con JavaScript que asigna estilos, o un observador que reacciona a su propio efecto.

El equivalente programático

Todo lo anterior requiere estar delante del navegador. Para dejar la medición puesta y recogerla en producción, la API de fotogramas largos de animación da el mismo desglose, con menos detalle y sin necesidad de nadie mirando:

const fotogramasMalos = [];

new PerformanceObserver((lista) => {
  for (const f of lista.getEntries()) {
    fotogramasMalos.push({
      inicio: Math.round(f.startTime),
      total: Math.round(f.duration),
      script: Math.round(f.renderStart - f.startTime),
      estiloYLayout: Math.round(f.startTime + f.duration - f.styleAndLayoutStart),
      bloqueante: Math.round(f.blockingDuration),
      culpable: f.scripts?.[0]?.sourceURL?.split('/').pop() ?? null,
    });
  }
}).observe({ type: 'long-animation-frame', buffered: true });

addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden' && fotogramasMalos.length) {
    navigator.sendBeacon('/rum-fotogramas', JSON.stringify(fotogramasMalos.slice(0, 30)));
  }
});

El array scripts de cada entrada trae la atribución: qué origen, qué URL y qué tipo de invocación provocó el trabajo. Es la información que convierte un agregado de fotogramas lentos en una lista de ficheros a revisar, y es la razón principal para instrumentar esto aunque solo funcione en una parte de tu tráfico.

La disponibilidad está limitada a los navegadores basados en Chromium en el momento de escribir esto. Como fuente de diagnóstico es suficiente; como métrica de producto para presentar, hay que decir de qué navegadores viene.

Un procedimiento de cinco pasos

Uno: reproduce el problema con la CPU estrangulada y comprueba que se ve en la pista de fotogramas. Si no se ven fotogramas perdidos, no hay problema de renderizado por mucho que lo parezca.

Dos: localiza un fotograma malo representativo, no el peor de todos. El peor suele ser un caso raro; el representativo es el que se repite.

Tres: mira qué banda es la más ancha y aplica la tabla de diagnóstico.

Cuatro: si la pista del hilo principal está vacía, salta al procedimiento de rasterizado y GPU del callout.

Cinco: cambia una sola cosa y vuelve a grabar. El error de método más caro en este panel es tocar tres cosas a la vez, porque después no se sabe cuál funcionó y muchas veces una de las tres empeoró y otra lo compensó.