INP Core Web Vitals na prática com dados de campo
O INP é o Core Web Vital de responsividade desde 12 de março de 2024, quando substituiu o FID. Ele mede a interação mais lenta da visita, do toque até o próximo quadro pintado, e é considerado bom até 200 ms no percentil 75. O diagnóstico útil começa em dados de campo e usa a Long Animation Frames API para descobrir qual script travou a interação. No Web Almanac 2025, as páginas internas tinham INP pior que a home no celular, por isso a home sozinha não serve de amostra do site.
Principais pontos
- O INP substituiu o FID como Core Web Vital em 12 de março de 2024.
- Um INP de até 200 ms no percentil 75 é bom, entre 200 e 500 ms precisa de melhoria e acima de 500 ms é ruim.
- No Web Almanac 2025, 77% dos sites tinham INP bom no celular, contra 97% no desktop.
- No celular, as páginas internas ficaram atrás da home, com 69% de INP bom contra 80%, segundo o Web Almanac 2025.
- A Long Animation Frames API saiu no Chrome 123 e atribui a scripts específicos os quadros que passam de 50 ms.
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
| Faixa | INP no percentil 75 |
|---|---|
| Bom | Até 200 ms |
| Precisa melhorar | Acima de 200 ms e até 500 ms |
| Ruim | Acima de 500 ms |
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.
| Fase | Vai de | Causa comum |
|---|---|---|
| Atraso de entrada | O gesto até o início do primeiro handler | Tarefa longa ocupando a thread principal |
| Processamento | O início até o fim dos handlers | Handler que faz trabalho demais antes de devolver o controle |
| Apresentação | O fim dos handlers até o quadro na tela | Atualização grande de DOM, cálculo de estilo e layout forçado |
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.
O que a IA desdobra desta pergunta?
Quando alguém faz esta busca em uma IA, o sistema abre subperguntas antes de responder. Estas são as que apareceram na medição, e onde cada uma é respondida.
Perguntas frequentes
Qual é um bom valor de INP?
Até 200 milissegundos no percentil 75 das visitas, medido à parte em celular e em desktop. Entre 200 e 500 milissegundos a página precisa de melhoria, e acima de 500 milissegundos a resposta é considerada ruim. Os limiares estão na documentação do web.dev, mantida pela equipe do Chrome, e valem para dados de campo, não para testes de laboratório.
Por que o PageSpeed Insights não mostra INP para uma página?
Faltam dados de campo suficientes. O INP depende de interações reais de usuários do Chrome, e o CrUX só publica valores quando há volume bastante. Também não há INP quando o visitante apenas rola ou passa o cursor, gestos que a métrica ignora. No laboratório, o Total Blocking Time serve como indicador aproximado, sem substituir o INP.
O que a LoAF acrescenta ao diagnóstico de INP?
A LoAF mostra qual script ocupou o quadro lento. A API, estável desde o Chrome 123, registra quadros de animação acima de 50 milissegundos com URL de origem, função chamadora e tempo de layout forçado. A biblioteca web-vitals, no build de atribuição, cruza esses registros com a interação que definiu o INP da visita.
Fontes citadas
Versão em markdown para agentes de IA: https://lucasferraz.com/blog/inp-na-pratica/md/