INP Core Web Vitals na prática com dados de campo

O que o INP mede e desde quando?

O INP virou Core Web Vital estável em 12 de março de 2024, no lugar do FID. O FID media só o atraso de entrada da primeira interação. O INP observa todos os cliques, toques e teclas da visita, do gesto até o próximo quadro pintado, e ignora rolagem e cursor parado sobre elementos. O Chrome deu até 9 de setembro de 2024 para quem consumia FID pelas APIs do CrUX e do PageSpeed Insights migrar para o INP.

O valor de uma página é a interação mais lenta da visita, com um desconto: a cada 50 interações, a pior é descartada, para não punir páginas muito interativas por um soluço isolado. O relatório usa o percentil 75 das visitas, separado entre celular e desktop.

O valor de uma página é a interação mais lenta da visita, com um desconto: a cada 50 interações, a pior é descartada, para não punir páginas muito interativas por um soluço isolado.

Lucas Ferraz, especialista em SEO

A equipe do Chrome justifica a métrica com um dado de uso: 90% do tempo que a pessoa passa em uma página acontece depois do carregamento. A definição curta dos três Core Web Vitals está no verbete da agência.

As três fases de uma interação lenta

Toda interação medida pelo INP se divide em atraso de entrada, tempo de processamento e atraso de apresentação. Saber qual fase domina decide a correção, porque cada uma tem causa típica diferente.

A coleção de guias de INP do web.dev separa as correções em dois grupos. Os problemas causados por JavaScript pedem quebrar tarefas longas, reduzir o atraso de entrada e tirar trabalho da thread principal. Os problemas de renderização pedem menos layout forçado, cálculo de estilo mais barato e DOM menor.

Dados de campo antes do laboratório

O diagnóstico de INP começa em dados de campo, porque o laboratório só mede as interações que alguém simular. O CrUX, visível no PageSpeed Insights e no relatório de Core Web Vitals do Search Console, diz se existe problema na origem ou na URL, mas não diz a causa. No laboratório, o Total Blocking Time funciona como indicador aproximado, sem substituir a métrica.

O Web Almanac 2025 dá o tamanho do problema. No celular, 77% dos sites tinham INP bom, contra 74% em 2024. No desktop, 97%. Entre os mil sites mais acessados, a taxa no celular subiu de 53% para 63%. O dado que mais muda a rotina de auditoria é outro: com dados por página, a home tinha 80% de INP bom no celular e as páginas internas, 69%. Em 2024 as duas estavam praticamente empatadas, com 73% e 72%.

O Almanac liga a diferença a filtros, carrosséis, validação de formulário e widgets de terceiros, que costumam morar nas páginas internas. Diagnosticar só a home esconde justamente onde o INP piorou.

LoAF e a atribuição por script

A Long Animation Frames API, estável desde o Chrome 123, registra os quadros cuja renderização atrasou mais de 50 ms e diz quais scripts ocuparam esse tempo. Cada entrada traz a URL de origem do script, a função que o chamou e o tempo gasto em estilo e layout forçados, o campo forcedStyleAndLayoutDuration.

A biblioteca web-vitals, no build de atribuição, cruza esses quadros com a interação que definiu o INP e entrega um resumo pronto. O campo longestScript indica o script mais longo e em qual das três fases ele rodou. Scripts abaixo de 5 ms ficam fora da atribuição. O envio para o próprio servidor cabe em poucas linhas:

import {onINP} from 'web-vitals/attribution';

onINP(({value, attribution}) => {
  const s = attribution.longestScript;
  navigator.sendBeacon('/rum', JSON.stringify({
    inp: Math.round(value),
    alvo: attribution.interactionTarget,
    fase: s ? s.subpart : null,
    script: s ? s.entry.sourceURL : null,
    carregamento: attribution.loadState,
    pagina: location.pathname
  }));
});

Um detalhe da medição por JavaScript: a Event Timing API não reporta, por padrão, eventos abaixo de 104 ms. O web.dev recomenda observar também a entrada first-input, que aparece mesmo abaixo desse limite, para que páginas rápidas com interação reportem algum valor.

Como eu agrupo o diagnóstico?

Prefiro agrupar os dados de INP por modelo de página e por script, porque uma URL isolada raramente junta visitas suficientes. O agrupamento por modelo, como listagem, artigo ou formulário, mostra onde o problema se repete. O agrupamento por script, usando o sourceURL que a LoAF devolve, separa o código próprio do código de terceiros e mostra a quem cabe cada correção.

A mesma lógica vale para o lado da busca com IA. Um site que depende de JavaScript para montar o conteúdo tende a pagar duas vezes: interação lenta para quem visita e texto invisível para os robôs de IA que não renderizam, tema de JavaScript e crawlers de IA. Menos script no cliente costuma ajudar as duas frentes ao mesmo tempo.