Dimensão Core/Dash: LOAF

Dimensão: Long Animation Frames (lurl)

A dimensão LOAF expõe 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 executado por tempo suficiente para bloquear a renderização. Esta é uma atribuição a nível de 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 disponibiliza como uma substituição para a antiga Long Tasks API. Enquanto a Long Tasks informava que um frame demorou muito, a LoAF informa quais scripts rodaram dentro desse frame e quais eram suas URLs. Essa é a distinção que torna esta dimensão útil em produção.

Por que a Long Tasks não era suficiente

A Long Tasks API (disponível desde 2017) sinalizava qualquer tarefa na thread principal que excedesse 50ms, mas fornecia quase nenhuma atribuição. Você podia ver que o bloqueio ocorreu; mas não podia ver o que o causou. Desenvolvedores passavam horas correlacionando timestamps de tarefas com network waterfalls, tentando adivinhar 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 possui 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 aciona um long animation frame, 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 pela URL do 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 (contêiner do Google Tag Manager)
• https://cdn.cookielaw.org/consent/... (OneTrust ou plataforma de consentimento semelhante)
• 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 são responsáveis por long animation frames 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-renderizações 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 a você qual script rodou durante esse intervalo. Um INP de 280ms onde 210ms são rastreados até um script de gerenciador de consentimento é um problema completamente diferente de um INP de 280ms onde 190ms são rastreados até o 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 Trabalho de Debugging

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. Filtro cruzado com o INP: Aplique o filtro LOAF à sua visualização de métrica de INP. Verifique se o p75 do INP muda quando você isola sessões onde aquele script rodou. Um aumento de mais 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: O 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, atrasar 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 atrasada. Para código primário, faça o profiling da função específica no Chrome DevTools com o CPU throttling configurado para 4x. Implante a alteração e observe a atualização da dimensão LOAF dentro de 24-48 horas de tráfego de usuários reais.

Regra Prática de Engenharia

• Qualquer URL única de script que apareça em frames longos em mais de 5% das sessões vale a pena ser investigada. Nessa taxa, ela está afetando uma parcela mensurável de usuários reais ao longo do mês.
• Scripts de terceiros não devem rodar durante os 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.
• Uma duração de 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 que se siga.
• Scripts primários na lista de LOAF frequentemente apontam para o overhead de frameworks. React, Vue e Angular podem produzir frames longos durante atualizações de estado. A URL do LOAF será o seu próprio bundle. Faça o profiling da árvore de componentes, não apenas da rede.

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