Core/Dash Dimension: LOAF

Dimension: Long Animation Frames (lurl)

La dimensión LOAF muestra las URLs 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 ejecutó durante el tiempo suficiente 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 usando la Long Animation Frames API (LoAF), que Chrome distribuye como reemplazo de la antigua Long Tasks API. Donde 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 URLs. Esa es la distinción que hace esta dimensión útil en producción.

Por qué las Long Tasks no eran suficientes

La Long Tasks API (disponible desde 2017) marcaba cualquier tarea del hilo principal que excediera 50ms, pero no proporcionaba casi ninguna atribución. Podías ver que ocurría el bloqueo; no podías ver qué lo causaba. Los desarrolladores pasaban horas correlacionando timestamps de tareas con cascadas de red, adivinando qué script era responsable.

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

Cómo CoreDash usa los datos de LoAF

Cada vez que una interacción del usuario desencadena un long animation frame, CoreDash registra las URLs de los scripts contribuyentes junto con la observación de 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 ves un conteo de cuántas sesiones involucraron ese script causando un long frame.

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/... (OneTrust o plataforma de consentimiento 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 representan long animation frames en aproximadamente el 60-70% de los sitios. Los tag managers por sí solos contribuyen a long frames en aproximadamente el 45% de las propiedades monitorizadas. Los bundles propios dominan el resto, generalmente debido a re-renders de React o event handlers no optimizados.

Atribución de INP mediante LoAF

INP mide el tiempo desde la interacción del usuario hasta el siguiente frame paint. Si esa brecha excede los 200ms, Google clasifica la experiencia como "necesita mejora". Los datos de LoAF te dicen qué script se ejecutó durante esa brecha. Un INP de 280ms donde 210ms se rastrean a un script de gestor de consentimiento es un problema completamente diferente a un INP de 280ms donde 190ms se rastrean a tu propio handler 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 correcta inmediatamente.

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 long frame). La entrada superior es tu objetivo de mayor prioridad.
2. Filtra cruzado con INP: Aplica el filtro LOAF a tu vista de la métrica INP. Verifica si el p75 de INP cambia cuando aíslas las sesiones donde se ejecutó ese script. Un aumento de 30ms o más confirma que el script está contribuyendo a la degradación de INP en producción.
3. Clasifica como propio o de terceros: Tu propio dominio en la URL significa que controlas la solución. Una URL de CDN de terceros significa que necesitas eliminar, retrasar o reemplazar el script del proveedor.
4. Aplica la corrección y verifica: Para scripts de terceros, retrasa la carga hasta después de la primera interacción del usuario usando una fachada o inicialización diferida. Para código propio, perfila la función específica en Chrome DevTools con CPU throttling configurado a 4x. Despliega el cambio y observa la actualización de la dimensión LOAF dentro de las 24-48 horas de tráfico de usuarios reales.

Regla práctica de ingeniería

• Cualquier URL de script individual que aparezca en long frames en más del 5% de las sesiones merece investigación. A esa tasa, está afectando a una porción medible de usuarios reales a lo largo del mes.
• Los scripts de terceros no deberían ejecutarse durante los handlers de interacción. Si un tag manager se ejecuta sincrónicamente en un evento de clic, eso es un problema de configuración, no una limitación del navegador.
• Una duración de long frame superior a 200ms para un solo script es una señal clara. La LoAF API reporta la duración por script dentro del frame. Cualquier script que consuma 200ms o más de un frame es la causa principal de cualquier INP que siga.
• Los scripts propios en la lista LOAF a menudo apuntan a sobrecarga del framework. React, Vue y Angular pueden producir long frames durante las actualizaciones de estado. La URL de LoAF será tu propio bundle. Perfila el árbol de componentes, no solo la red.

La dimensión LOAF te proporciona algo que ningún test sintético puede: prueba de qué scripts bloquean a los usuarios reales en producción, clasificados por frecuencia real. Filtra por ella, cruza la referencia con tus datos de INP, y tendrás una lista priorizada de exactamente qué corregir y en qué orden.