Como o Interaction to Next Paint pontua o seu pior clique

O que é INP (Interaction to Next Paint)?

O Chrome mede o Interaction to Next Paint como a duração da pior interação de uma página, cronometrada do momento em que um visitante clica, toca ou pressiona uma tecla até o momento em que o navegador pinta o frame que mostra o resultado. A métrica cobre a ida e volta inteira: a espera antes de um manipulador de eventos começar, o tempo de execução do próprio manipulador e o trabalho de renderização que vem depois. Instrumente com a biblioteca web-vitals ou com qualquer coletor de campo, e depois leia por rota.

O Chrome conta cliques de mouse, toques em tela sensível ao toque e teclas pressionadas em teclados físicos ou de tela, e rolagem, hover e zoom não produzem amostra de INP nenhuma, segundo a definição da métrica publicada pelo time do Chrome no web.dev (acessada em setembro de 2026). O INP é o único dos três Core Web Vitals que pontua a capacidade de resposta depois de a página ter carregado, e ele não reporta nada até pessoas reais clicarem em coisas, então o número sobre o qual o Google age vem do monitoramento de usuários reais, o real user monitoring, em p75.

Quais são as três fases de uma interação?

Toda interação se divide em input delay (a espera antes do manipulador), processing duration (a execução do manipulador) e presentation delay (a renderização até o frame), e o INP é a soma das três. Cada fase tem um dono diferente dentro do navegador, então um número de INP sozinho não diz nada até você separá-lo.

Fase	Começa quando	Termina quando	O que está queimando o tempo
Input delay	O visitante clica, toca ou pressiona uma tecla	O primeiro callback do evento começa a rodar	Thread principal já ocupada com avaliação de scripts, timers, outros manipuladores
Processing duration	O primeiro callback do evento começa	O último callback termina	O seu próprio código de manipulador, atualizações de estado do framework, trabalho síncrono
Presentation delay	O último callback termina	O navegador pinta o frame seguinte	Recálculo de estilos, layout, paint, tamanho do DOM

A fórmula é uma soma direta:

INP = input delay + processing duration + presentation delay

Um exemplo resolvido. Um visitante toca um chip de filtro em uma listagem de produtos e espera 620ms até a grade mudar:

620ms = 180ms input delay + 90ms processing duration + 350ms presentation delay

O instinto é otimizar o manipulador, e o manipulador é a menor fatia, com 90ms. O presentation delay fica com 56 por cento da interação, então a correção está na renderização: o filtro renderiza de novo 3,000 nós da grade e força um recálculo de estilos completo. Corte o DOM que a interação toca e os 350ms desabam. Reescrever o manipulador economiza 90ms na melhor das hipóteses e sozinho não chega a 200ms.

Um toque, três atrasos

Atraso de entrada180ms

Duração de processamento90ms

Atraso de apresentação350ms

O que é uma boa pontuação de INP?

Os limites do Chrome colocam bom em 200ms ou menos e ruim acima de 500ms, medidos no percentil 75 das visualizações de página e separados por celular e desktop. O time do Chrome publica esses cortes no web.dev, sem mudança até setembro de 2026.

INP em p75	Veredito
200ms ou menos	Bom
Acima de 200ms até 500ms	Precisa melhorar
Acima de 500ms	Ruim

Duzentos milissegundos são um orçamento apertado assim que você divide em três, e a fase que estoura a parte dela primeiro é a que você tem que atacar. Meça a divisão antes de tocar em código: uma caixa de busca falha no processing, uma grade de rolagem infinita falha na presentation.

Por que o INP substituiu o FID, e por que o FID favorecia os sites?

O Google tornou o INP um Core Web Vital em 12 de março de 2024, substituindo o First Input Delay, e o suporte ao FID terminou em 9 de setembro de 2024 (web.dev, time do Chrome). O FID media uma única coisa estreita: o atraso de entrada antes de o primeiro manipulador de eventos da página conseguir começar. Ele nunca cronometrou o manipulador, e nunca cronometrou o paint que vinha depois.

	First Input Delay	Interaction to Next Paint
Qual interação	Só a primeira	A pior da página
Quais fases	Só o input delay	Input delay, processing, presentation
Bom em p75	100ms ou menos	200ms ou menos
Status	Aposentado em 9 de setembro de 2024	Core Web Vital desde 12 de março de 2024

O FID favorecia os sites por duas razões. A primeira interação de uma página é barata para a maioria dos visitantes: fechar um aviso de cookies, colocar o foco em um campo de busca, tocar em aceitar num diálogo de consentimento. As interações caras chegam depois, quando o visitante já se comprometeu com a página, e o FID nunca olhou para elas.

O FID também parava o cronômetro antes de o seu código rodar, então um manipulador de filtro que bloqueava a thread principal por 900ms tirava um FID perfeito enquanto o navegador conseguisse entrar rápido no manipulador. O web.dev diz de forma explícita que contar o tempo de processamento no FID poderia ter empurrado desenvolvedores a embrulhar a lógica do manipulador em um callback assíncrono, tirando ela da tarefa medida sem ajudar a pessoa que espera. O INP fecha os dois buracos.

Qual interação o INP reporta quando uma página tem centenas?

O Chrome reporta a pior interação da página, com uma folga para valores atípicos em páginas movimentadas. Em páginas com 50 interações ou menos, a mais alta vira o INP da página. Acima de 50, o Chrome separa uma interação alta a cada 50 registradas, então uma sessão com 130 interações descarta as duas mais altas e reporta a seguinte.

Duas agregações se empilham aqui, e confundi-las é um erro comum de triagem: a regra da pior interação escolhe um número por visualização de página, e depois o percentil 75 entre as visualizações de página escolhe um número por URL. Leia essa distribuição do jeito que você lê o Largest Contentful Paint, com p75 ao lado de p90 e a contagem de amostras.

O que causa um INP lento, e o que corrige cada causa?

Um INP lento tem três famílias de causa, uma por fase, e cada uma pede uma correção diferente.

O input delay vem de uma thread principal que já está ocupada quando o clique chega: avaliação de scripts durante o carregamento, timers e manipuladores de fetch disputando a mesma thread. Corte a quantidade de JavaScript que chega a rodar, e quebre qualquer long task, ou tarefa longa, acima de 50ms para o navegador ganhar uma brecha onde aceitar a entrada.

A processing duration vem de manipuladores que fazem demais de uma vez. Ceda a thread principal com scheduler.yield() ou setTimeout() para o navegador conseguir pintar um frame intermediário, e adie tudo o que o visitante não precisa na hora atrás de requestAnimationFrame() mais uma cessão. Pinte o retorno primeiro, depois faça o trabalho.

O presentation delay vem da renderização. DOMs grandes custam mais para renderizar do que os pequenos, então achate a árvore e adicione elementos durante a interação em vez de enviá-los de antemão. Estreite o alcance do recálculo de estilos e use content-visibility para pular o trabalho fora da tela. Cace primeiro o layout thrashing: escrever um estilo e ler ele de volta na mesma tarefa força um layout síncrono, e agrupar todas as leituras antes de todas as escritas elimina isso. O mesmo trabalho de renderização move o Cumulative Layout Shift, então confira os dois depois da correção.

Como você encontra a interação que derruba o seu INP?

Olhe as sessões em que um visitante clicou e nada aconteceu. Um INP de 640ms em p75 diz que a página está lenta; não diz qual controle, qual rota nem qual dispositivo.

A Flowsery grava a sessão e sinaliza rage clicks, dead clicks e erros de JavaScript automaticamente, que é como uma interação travada se parece do lado do visitante: o mesmo botão apertado quatro vezes porque nenhum frame chegou a ser pintado. As sessões que coincidem se agrupam em um problema, os problemas se ordenam por quantos usuários batem neles, e cada um chega ao Slack, Linear ou Jira com a gravação e os passos para reproduzir anexados. A coleta roda sobre um script de menos de 10 KB, sem cookies e hospedado na UE, sem amostragem de dados, então as interações lentas não são as que caem fora da amostra.

Perguntas frequentes

O INP mede a rolagem?

Não. O Chrome conta cliques de mouse, toques em tela sensível ao toque e teclas pressionadas, e exclui rolagem, hover e zoom. Uma rolagem travada é uma reclamação real que não produz amostra de INP nenhuma, então diagnostique por frame timing e long tasks.

Por que meu INP é bom no Lighthouse e ruim em campo?

O Lighthouse roda uma interação roteirizada em um dispositivo configurado, e o INP pontua a pior interação que visitantes reais fizeram no hardware deles. O seu teste de laboratório clica no botão que você mandou clicar; os seus visitantes clicam no filtro caro em um Android de quatro anos atrás. Trate o laboratório como checagem de regressão e o campo como veredito.

Ainda devo monitorar o First Input Delay?

Não. O FID deixou de ser Core Web Vital em 12 de março de 2024, e o suporte terminou em 9 de setembro de 2024, então ele não aparece mais no Search Console e não pesa na avaliação. Mova o painel do dashboard para o INP e guarde a série do FID só para ler incidentes antigos.

Um clique lento sozinho pode reprovar a página inteira?

Sozinho, não. A pior interação vira o INP daquela visualização de página, e depois o Google lê o percentil 75 desses valores em todas as visualizações de página da URL. Um clique de 3 segundos em uma sessão não move nada; o mesmo controle lento atingindo um quarto das suas sessões reprova a URL.

Como o INP é medido em uma single-page app?

O INP acumula pela vida inteira da página, então as interações de uma rota ficam na mesma janela de medição que a seguinte até uma navegação dura reiniciá-la. Um clique lento em uma tela de configurações pode ser reportado contra a URL em que o visitante caiu. O suporte do Chrome a soft navigations para partir essas janelas é experimental, então segmente por rota nos seus próprios dados de campo.

Que orçamento por fase mantém o INP abaixo de 200ms?

Cinquenta milissegundos de input delay, 50ms de processing duration e 100ms de presentation delay é uma divisão viável. Meça a divisão real por rota antes de escolher o que corrigir, porque uma caixa de busca carregada de manipuladores e uma grade de produtos carregada de renderização falham no mesmo limite por razões opostas.

O que conta como uma long task, e por que isso importa para o INP?

Uma long task é qualquer bloco ininterrupto de trabalho na thread principal com mais de 50ms, o mesmo limite para o qual apontam as correções do atraso de entrada. Enquanto uma long task roda, o navegador não consegue iniciar um manipulador de evento, então esse tempo entra direto no atraso de entrada. Dividir a long task em partes menores dá ao navegador uma brecha para aceitar o clique e iniciar o manipulador mais cedo.

Como parar o layout thrashing que estica o atraso de apresentação?

O layout thrashing acontece quando o código escreve um estilo e o lê de volta na mesma tarefa, o que força um layout síncrono que o navegador teria adiado. Agrupar todas as leituras antes de todas as escritas na mesma tarefa elimina esse layout forçado junto com o atraso que ele causava. Isso se verifica primeiro dentro do atraso de apresentação, antes do tamanho do DOM e do content-visibility.

Qual ferramenta realmente mede o INP no seu próprio site?

O INP é instrumentado com a biblioteca web-vitals ou outro coletor de campo, lido por rota. Como o INP só reporta algo quando visitantes reais clicam, tocam ou digitam, esse número precisa vir de real user monitoring, não de uma única execução no Lighthouse. O resultado é lido no percentil 75, do mesmo jeito que o Chrome pontua.

Por que o Chrome descarta algumas interações em páginas com muitos cliques?

Acima de 50 interações registradas, o Chrome reserva um valor alto a cada 50 para que alguns poucos outliers não decidam a pontuação da página inteira. Uma página com 130 interações descarta as duas mais altas e reporta a próxima como seu INP. Páginas com 50 interações ou menos pulam essa etapa e usam diretamente a pior interação.