O que é INP?
INP, sigla de Interaction to Next Paint (em tradução livre, da interação à próxima renderização), é a métrica que mede quanto tempo a página demora para dar resposta visual depois que o usuário clica, toca ou pressiona uma tecla. Um INP alto significa página travada: o usuário age e a tela demora a reagir.
O INP integra os Core Web Vitals e, em março de 2024, substituiu o FID (First Input Delay) como métrica oficial de interatividade do Google. A troca ampliou a medição: o FID observava apenas o atraso da primeira interação, enquanto o INP considera todas as interações da visita e reporta a mais lenta.
Para o SEO técnico, o INP virou o termômetro da qualidade do JavaScript da página. Scripts pesados, tags de marketing em excesso e processamento longo na thread principal são as causas típicas de interações lentas.
Como calcular o INP?
INP = latência da interação mais lenta da visita (aproximada pelo percentil 98 das interações)O INP é medido durante a navegação real, e cada interação soma três parcelas:
- Atraso de entrada: o tempo entre a ação do usuário e o início do processamento.
- Tempo de processamento: a execução do código associado à interação.
- Atraso de apresentação: o tempo até o navegador pintar o novo quadro na tela.
Exemplo concreto: em um e-commerce, o usuário toca em “adicionar ao carrinho”. O script demora 80 ms para começar, processa por 250 ms e a tela atualiza 70 ms depois, então a interação levou 400 ms. Se essa for a pior interação da visita, o INP é 400 ms, dentro da faixa que precisa melhorar. Após dividir o script em tarefas menores e adiar tags não essenciais, a mesma interação cai para 150 ms e o INP entra na faixa boa.
A medição de usuários reais aparece no PageSpeed Insights e no relatório de Core Web Vitals do Google Search Console.
INP vs FID vs LCP vs CLS: qual a diferença?
| Métrica | O que mede | Quando usar |
|---|---|---|
| INP | A pior latência de interação da visita | Diagnosticar página que trava ao usar |
| FID | Só o atraso da primeira interação | Métrica aposentada pelo Google em 2024 |
| LCP | Tempo até o maior conteúdo aparecer | Diagnosticar carregamento lento |
| CLS | Deslocamentos inesperados de layout | Diagnosticar elementos que pulam |
Veredito: o INP cobre a responsividade da visita inteira, papel que o FID cumpria parcialmente, enquanto LCP e CLS medem carregamento e estabilidade.
Exemplos de uso
- Uma loja virtual percebe INP de 600 ms no mobile causado por dezenas de tags de rastreamento. A revisão do gerenciador de tags e a remoção de scripts abandonados derrubam o INP para menos de 200 ms.
- Um SaaS identifica que o filtro de busca reprocessa a lista inteira a cada tecla digitada. A otimização do código melhora o INP e a experiência de uso ao mesmo tempo.
Valores de referência
A documentação do Google define as faixas, medidas no percentil 75 dos acessos reais:
| Classificação | INP |
|---|---|
| Bom | Até 200 ms |
| Precisa melhorar | De 200 ms a 500 ms |
| Ruim | Acima de 500 ms |
Erros comuns
- Otimizar só o carregamento inicial e ignorar o que acontece quando o usuário interage.
- Acumular tags de marketing e pixels sem revisão, sobrecarregando a thread principal.
- Confiar apenas em testes de laboratório, que não capturam interações reais de usuários.
- Ignorar o mobile, onde processadores mais lentos amplificam qualquer script pesado.
Perguntas frequentes sobre INP
Qual é um bom INP?
O Google considera bom um INP de até 200 milissegundos, medido no percentil 75 dos acessos reais. Entre 200 ms e 500 ms a página precisa melhorar, e acima de 500 ms a responsividade é classificada como ruim. A meta prática é responder a qualquer interação em menos de 200 ms.
Por que o INP substituiu o FID?
O FID media apenas o atraso da primeira interação e ignorava o processamento e a resposta visual. Quase todos os sites passavam no FID, o que reduzia a utilidade da métrica. O INP avalia todas as interações da visita e reporta a pior, refletindo melhor a experiência real de uso.
O que costuma deixar o INP alto?
JavaScript pesado é a causa dominante: tarefas longas na thread principal, excesso de tags de terceiros, event handlers mal otimizados e DOM muito grande. O diagnóstico começa identificando as interações lentas nos dados de campo e depois localizando os scripts responsáveis nos testes de laboratório.