O INP Pune Analytics Pesado: Por Que Seu Rastreador Está na Thread Principal
Interaction to Next Paint é o Core Web Vital que mais sites reprovam, e dados de campo mostram que scripts de rastreamento de comportamento são uma das principais causas. A solução é enviar menos trabalho para a thread principal.
O Interaction to Next Paint (INP) é o Core Web Vital que os desenvolvedores mais reprovam, e o motivo está dentro do seu <head>. O INP se tornou um Core Web Vital estável em 2024, substituindo o First Input Delay, e mede algo que o FID nunca conseguiu: o quão responsiva uma página permanece em cada clique, toque e tecla durante todo o seu ciclo de vida.
A métrica é implacável com o tipo de JavaScript que o analytics de vigilância carrega. Se o seu rastreador faz trabalho relevante na thread principal, cada interação dos seus usuários herda esse custo.
O Que o INP Realmente Mede
O INP relata a latência das interações no percentil 75 de todos os cliques, toques e teclas pressionadas em uma página. Uma pontuação de 200 ms ou menos é "boa"; de 200 a 500 ms "precisa de melhoria"; acima de 500 ms é "ruim".
Cada interação se divide em três fases:
- Atraso de entrada (input delay) — tempo até que seus event handlers consigam começar, porque a thread principal está ocupada.
- Duração de processamento — tempo que os callbacks dos seus event handlers levam para executar.
- Atraso de apresentação (presentation delay) — tempo entre o término do callback e o momento em que o navegador renderiza o próximo frame.
Analytics pesado prejudica as três fases. Um rastreador que analisa um bundle grande, avalia lógica de consentimento, agrupa uma fila de tag manager ou lê o layout para montar um fingerprint ocupa a thread principal exatamente quando o usuário tenta interagir.
Tarefas Longas São o Mecanismo
O navegador não consegue processar uma interação enquanto uma tarefa está em execução. Qualquer tarefa que dure mais de 50 ms é uma tarefa longa, e a parte que excede os 50 ms é tempo morto durante o qual os cliques se acumulam na fila.
Um tag manager que carrega e executa de forma síncrona uma dúzia de scripts de fornecedores produz uma cascata de tarefas longas. O usuário clica, nada acontece, ele clica de novo — e quando a thread principal finalmente libera, as entradas enfileiradas disparam todas de uma vez.
Isso não é teórico. O Web Almanac de 2024 do HTTP Archive descobriu que páginas com scripts de comportamento do usuário — session replay, mapas de calor, analytics comportamental — alcançaram bom INP apenas 37% das vezes no mobile, contra 60% no desktop. Scripts de gerenciamento de consentimento, os banners que essas ferramentas exigem, passaram no INP em apenas 53% das páginas mobile. A instrumentação que deveria "entender os usuários" está ativamente degradando a experiência deles.
A Arquitetura Que Evita Isso
A solução é estrutural, não uma flag que você ativa. Envie menos código e mantenha-o fora do caminho crítico.
Um rastreador privacy-first pode ser pequeno o suficiente para que sua análise e execução nunca contem como uma tarefa longa. O rastreador da Monoid tem cerca de 2 KB, não tem dependências, não define cookies e não lê o layout — portanto não há nada para fazer fingerprint e nada pesado para executar. Ele registra um pageview com uma única requisição keepalive e, fora isso, permanece ocioso:
fetch('/collect', {
method: 'POST',
keepalive: true,
body: JSON.stringify({ site_id, path: location.pathname })
})
keepalive: true permite que a requisição sobreviva à página sem segurar a thread principal, então a navegação e o unload nunca ficam bloqueados esperando um beacon.
Quando você executar seus próprios scripts, ceda a thread principal entre blocos de trabalho para que as interações enfileiradas possam rodar:
async function processQueue(items) {
for (const item of items) {
handle(item)
if (navigator.scheduling?.isInputPending?.()) {
await scheduler.yield()
}
}
}
scheduler.yield() divide uma tarefa longa em pedaços e retoma com prioridade, de modo que um script de terceiros não consiga furar a fila à frente da sua continuação.
Meça em Campo, Não em Laboratório
O Lighthouse não consegue reportar o INP, porque o INP só existe quando uma pessoa real interage. Ferramentas de laboratório estimam; elas não medem responsividade.
Use dados de campo. O Chrome User Experience Report (CrUX) agrega interações reais de usuários do Chrome que optaram por participar, e o relatório de Core Web Vitals do Search Console mostra os mesmos dados por grupo de URL. Se o seu INP no CrUX está bom mas o Total Blocking Time de laboratório está alto, você tem folga; se o INP no CrUX está ruim, seus usuários já estão sentindo.
O argumento de privacidade e o argumento de performance convergem aqui. Um rastreador que não lê armazenamento, não monta fingerprint e não carrega uma cascata de fornecedores quase não tem o que fazer na thread principal — e é exatamente por isso que ele nunca aparece no seu INP. Vigilância é cara em milissegundos, não apenas em confiança.
Comments
Loading comments…