Dimensão Core/Dash: LOAF

Dimensão: Long Animation Frames (lurl)

A dimensão LOAF mostra as URLs de scripts que causaram Long Animation Frames durante as sessões dos seus usuários. Cada valor é uma URL de script: um bundle primário, uma tag de analytics de terceiros, um widget de chat, um gerenciador de consentimento ou qualquer outra coisa que tenha rodado por tempo suficiente para bloquear a renderização. Isso é atribuição no nível da origem, não apenas um stack trace que você precisa reconstruir no DevTools.

O CoreDash coleta esses dados usando a Long Animation Frames API (LoAF), que o Chrome traz para substituir a antiga Long Tasks API. Onde a Long Tasks dizia que um frame demorou muito, a LoAF diz quais scripts rodaram dentro daquele frame e quais eram suas URLs. Essa é a diferença que torna essa dimensão útil em produção.

Por que as Long Tasks não eram suficientes

A Long Tasks API (disponível desde 2017) sinalizava qualquer tarefa na main thread que excedesse 50ms, mas quase não oferecia atribuição. Você via que o bloqueio acontecia, mas não o que o causava. Desenvolvedores passavam horas correlacionando timestamps de tarefas com waterfalls de rede, adivinhando qual script era o responsável.

A LoAF API muda isso. Ela reporta objetos PerformanceLongAnimationFrameEntry, cada um contendo um array scripts. Cada entrada nesse array tem um invokerType, uma sourceURL e uma duration. O CoreDash lê a sourceURL de cada script que rodou durante um frame longo e a armazena como o valor da dimensão LOAF. O resultado é uma lista ranqueada de URLs de scripts ordenada pela frequência com que aparecem nos frames longos dos seus usuários.

Como o CoreDash usa os dados da LoAF

Toda vez que uma interação do usuário dispara um frame de animação longo, o CoreDash registra as URLs dos scripts contribuintes junto com a observação do INP. Isso significa que você pode filtrar seus dados de INP por URL da LOAF e ver qual script é responsável pelas suas piores interações. A dimensão agrupa por URL, então você vê uma contagem de quantas sessões envolveram aquele script causando um frame longo.

Entradas típicas que você verá na dimensão LOAF:

• https://www.googletagmanager.com/gtm.js (container do Google Tag Manager)
• https://cdn.cookielaw.org/consent/... (OneTrust ou plataforma de consentimento similar)
• https://js.intercomcdn.com/... (widget de chat)
• /static/js/app.bundle.js (código da sua própria aplicação)
• https://connect.facebook.net/en_US/fbevents.js (Meta Pixel)

Nos dados do CoreDash, scripts de terceiros respondem por frames de animação longos em cerca de 60-70% dos sites. Gerenciadores de tags sozinhos contribuem para frames longos em aproximadamente 45% das propriedades monitoradas. Bundles primários dominam o restante, geralmente devido a re-renders do React ou manipuladores de eventos não otimizados.

Atribuição de INP via LoAF

O INP mede o tempo desde a interação do usuário até a pintura do próximo frame. Se esse intervalo exceder 200ms, o Google classifica a experiência como "precisa de melhorias". Os dados da LoAF dizem qual script rodou durante esse intervalo. Um INP de 280ms onde 210ms são atribuídos a um script de gerenciador de consentimento é um problema completamente diferente de um INP de 280ms onde 190ms vêm do seu próprio manipulador de checkout. A correção é diferente. A equipe responsável é diferente. A urgência é diferente.

Sem a atribuição da LoAF, ambos parecem idênticos no seu histograma de INP. Com ela, você pode direcionar o problema para a pessoa certa imediatamente.

Fluxo de depuração

1. Abra a dimensão LOAF no CoreDash: Ordene por frequência (quantas sessões viram essa URL em um frame longo). A primeira entrada é o seu alvo de maior prioridade.
2. Faça um filtro cruzado com o INP: Aplique o filtro de LOAF na sua visualização da métrica de INP. Verifique se o p75 do INP muda quando você isola as sessões onde aquele script rodou. Um aumento de 30ms+ confirma que o script está contribuindo para a degradação do INP em produção.
3. Classifique como primário ou de terceiros: Seu próprio domínio na URL significa que você controla a correção. Uma URL de CDN de terceiros significa que você precisa remover, adiar ou substituir o script do fornecedor.
4. Aplique a correção e verifique: Para scripts de terceiros, adie o carregamento para depois da primeira interação do usuário usando uma facade ou inicialização adiada. Para código primário, faça o profiling da função específica no Chrome DevTools com CPU throttling em 4x. Faça o deploy da alteração e observe a dimensão LOAF se atualizar dentro de 24-48 horas de tráfego de usuários reais.

Regra prática de engenharia

• Qualquer URL de script individual que apareça em frames longos em mais de 5% das sessões vale a pena investigar. Nessa taxa, ela afeta uma parcela mensurável de usuários reais ao longo do mês.
• Scripts de terceiros não devem rodar durante manipuladores de interação. Se um gerenciador de tags dispara de forma síncrona em um evento de clique, isso é um problema de configuração, não uma limitação do navegador.
• A duração de um frame longo acima de 200ms para um único script é um sinal claro. A LoAF API reporta a duração por script dentro do frame. Qualquer script que consuma 200ms ou mais de um frame é a causa principal de qualquer INP subsequente.
• Scripts primários na lista de LOAF geralmente apontam para overhead do framework. React, Vue e Angular podem produzir frames longos durante atualizações de estado. A URL de LOAF será o seu próprio bundle. Faça o profiling da árvore de componentes, não apenas da rede.

A dimensão LOAF oferece algo que nenhum teste sintético consegue: a prova de quais scripts bloqueiam usuários reais em produção, ranqueados pela frequência no mundo real. Filtre por ela, cruze com seus dados de INP e você terá uma lista priorizada exatamente do que corrigir e em qual ordem.