Dimensión de Core/Dash: LOAF

Dimensión: Long Animation Frames (lurl)

La dimensión LOAF expone las URL de los scripts que causaron Long Animation Frames durante las sesiones de tus usuarios. Cada valor es una URL de script: un bundle propio, una etiqueta de analítica de terceros, un widget de chat, un gestor de consentimiento o cualquier otra cosa que se haya ejecutado lo suficiente como para bloquear el renderizado. Esto es atribución a nivel de origen, no solo un stack trace que tienes que reconstruir en DevTools.

CoreDash recopila estos datos mediante la Long Animation Frames API (LoAF), que Chrome ofrece como reemplazo de la antigua Long Tasks API. Mientras que Long Tasks te decía que un frame tardaba demasiado, LoAF te dice qué scripts se ejecutaron dentro de ese frame y cuáles eran sus URL. Esa es la distinción que hace que esta dimensión sea útil en producción.

Por qué Long Tasks no era suficiente

La Long Tasks API (disponible desde 2017) marcaba cualquier tarea del main thread que superara los 50 ms, pero casi no ofreciía atribución. Podías ver que había un bloqueo; no podías ver qué lo causaba. Los desarrolladores pasaban horas correlacionando marcas de tiempo de las tareas con los waterfalls de red, adivinando qué script era el responsable.

La API LoAF cambia esto. Reporta objetos PerformanceLongAnimationFrameEntry, cada uno con un array de scripts. Cada entrada de ese array tiene un invokerType, un sourceURL y un duration. CoreDash lee el sourceURL de cada script que se ejecutó durante un frame largo y lo almacena como el valor de la dimensión LOAF. El resultado es una lista clasificada de URL de scripts, ordenada según la frecuencia con la que aparecen en los frames largos de tus usuarios.

Cómo utiliza CoreDash los datos de LoAF

Cada vez que una interacción de usuario activa un frame de animación largo, CoreDash registra las URL de los scripts implicados junto con la observación del INP. Esto significa que puedes filtrar tus datos de INP por URL de LOAF y ver qué script es responsable de tus peores interacciones. La dimensión agrupa por URL, así que verás en cuántas sesiones ese script causó un frame largo.

Entradas típicas que verás en la dimensión LOAF:

• https://www.googletagmanager.com/gtm.js (contenedor de Google Tag Manager)
• https://cdn.cookielaw.org/consent/... (plataforma de consentimiento de OneTrust o similar)
• https://js.intercomcdn.com/... (widget de chat)
• /static/js/app.bundle.js (tu propio código de aplicación)
• https://connect.facebook.net/en_US/fbevents.js (Meta Pixel)

En los datos de CoreDash, los scripts de terceros causan frames de animación largos en aproximadamente el 60-70 % de los sitios. Los gestores de etiquetas contribuyen por sí solos a los frames largos en aproximadamente el 45 % de las propiedades monitorizadas. Los bundles propios dominan el resto, normalmente debido a re-renders de React o event handlers no optimizados.

Atribución del INP mediante LoAF

El INP mide el tiempo desde la interacción del usuario hasta el pintado del siguiente frame. Si ese intervalo supera los 200 ms, Google clasifica la experiencia como "necesita mejorar". Los datos de LoAF te dicen qué script se ejecutó durante ese intervalo. Un INP de 280 ms donde 210 ms se atribuyen a un script del gestor de consentimiento es un problema completamente diferente a un INP de 280 ms donde 190 ms se atribuyen a tu propio manejador de checkout. La solución es diferente. El equipo responsable es diferente. La urgencia es diferente.

Sin la atribución de LoAF, ambos se ven idénticos en tu histograma de INP. Con ella, puedes dirigir el problema a la persona adecuada de inmediato.

Flujo de trabajo de depuración

1. Abre la dimensión LOAF en CoreDash: Ordena por frecuencia (cuántas sesiones vieron esta URL en un frame largo). La primera entrada es tu objetivo de mayor prioridad.
2. Aplica filtros cruzados con el INP: Aplica el filtro de LOAF a tu vista de métricas de INP. Comprueba si el p75 del INP cambia cuando aíslas las sesiones en las que se ejecutó ese script. Un aumento de 30 ms o más confirma que el script está contribuyendo a la degradación del INP en producción.
3. Clasifica como propio o de terceros: Si ves tu propio dominio en la URL, significa que tú controlas la solución. Una URL de CDN de terceros significa que debes eliminar, retrasar o reemplazar el script del proveedor.
4. Aplica la solución y verifica: Para scripts de terceros, pospón la carga hasta después de la primera interacción del usuario usando un facade o una inicialización diferida. Para el código propio, analiza el rendimiento de la función específica en Chrome DevTools con la limitación de CPU a 4x. Despliega el cambio y observa cómo se actualiza la dimensión LOAF en un plazo de 24-48 horas de tráfico real de usuarios.

Regla práctica de ingeniería

• Vale la pena investigar cualquier URL de script individual que aparezca en frames largos en más del 5 % de las sesiones. A ese ritmo, está afectando a una parte medible de usuarios reales a lo largo del mes.
• Los scripts de terceros no deberían ejecutarse durante los manejadores de interacción. Si un gestor de etiquetas se activa de forma síncrona en un evento de clic, eso es un problema de configuración, no una limitación del navegador.
• Una duración de frame largo superior a 200 ms para un solo script es una señal clara. La API LoAF reporta la duración por script dentro del frame. Cualquier script que consuma 200 ms o más de un frame es la causa principal de cualquier INP posterior.
• Los scripts propios en la lista de LOAF a menudo apuntan a la sobrecarga del framework. React, Vue y Angular pueden producir frames largos durante las actualizaciones de estado. La URL de LOAF será tu propio bundle. Analiza el rendimiento del árbol de componentes, no solo de la red.

La dimensión LOAF te ofrece algo que ninguna prueba sintética puede: la prueba de qué scripts bloquean a usuarios reales en producción, clasificados por su frecuencia en el mundo real. Filtra por ella, crúzala con tus datos de INP y obtendrás una lista priorizada de exactamente qué corregir y en qué orden.