INP: o que é o Interaction to Next Paint e como medir e melhorar

O INP (Interaction to Next Paint) mede a responsividade de uma página: o tempo entre o início de uma interação do usuário e o próximo quadro que o navegador pinta. É uma das métricas dos Core Web Vitals.

A documentação do web.dev, publicada em 6 de maio de 2022 e atualizada em 2 de setembro de 2025, descreve como o valor é calculado, quais interações entram na conta e como diagnosticar os casos lentos.

O que é o INP

O INP reporta um único valor que representa a latência de todas as interações feitas na página. Segundo a documentação do Google, é um valor abaixo do qual todas — ou praticamente todas — as interações ficaram. Um INP baixo indica resposta rápida e consistente, não sorte em um momento isolado.

A fonte cita dados de uso do Chrome: 90% do tempo do usuário na página acontece depois do carregamento. Por isso a métrica olha todo o ciclo de vida da página, não só o momento em que ela termina de carregar.

O valor final é a interação de maior latência observada, com descarte de valores atípicos. Em páginas com muitas interações, a documentação ignora a pior interação a cada 50 e reporta o 75º percentil das visualizações de página.

Como a maior parte das páginas não passa de 50 interações, na prática a pior interação tende a ser a reportada.

Os limites: 200 ms e 500 ms

A referência é o 75º percentil dos carregamentos medidos em campo, separado entre celular e desktop:

• Até 200 ms: responsividade boa.
• Acima de 200 ms e até 500 ms: precisa melhorar.
• Acima de 500 ms: responsividade ruim.

A documentação reconhece a dificuldade de rotular responsividade, já que a capacidade dos dispositivos varia muito. Os limites existem para dar uma expectativa alcançável de desenvolvimento diante dessa variação de capacidade.

O que conta como interação

Só 3 tipos de interação entram na conta: clique com o mouse, toque em tela sensível e pressionamento de tecla, em teclado físico ou virtual.

Hover, zoom e rolagem ficam de fora, embora variações desses gestos possam gerar cliques, toques ou teclas que entram na conta.

Interações dentro de iframes também entram na métrica, porque o usuário não sabe o que é um iframe e o que não é. Só que as APIs de JavaScript não acessam o conteúdo de iframes. Essa diferença pode aparecer como divergência entre dados do CrUX e de RUM.

Uma interação não é um evento isolado: é um grupo de handlers que disparam no mesmo gesto lógico. Um toque, por exemplo, envolve pointerdown, pointerup e click. A latência da interação é a da maior duração dentro desse grupo.

As três partes de uma interação

Toda interação se divide em 3 partes: atraso de entrada, duração do processamento e atraso de apresentação.

• Atraso de entrada: tempo até o primeiro callback rodar. Tarefas longas na thread principal podem causar esse atraso.
• Duração do processamento: tempo de execução de todos os callbacks da interação.
• Atraso de apresentação: tempo entre o fim dos callbacks e a pintura do próximo quadro.

INP e FID: o que mudou

O INP é o sucessor do First Input Delay (FID), que media apenas o atraso de entrada da primeira interação. O INP observa todas as interações, do atraso de entrada à execução dos handlers e à pintura do quadro seguinte.

Na prática, o FID avaliava a primeira impressão de carregamento. O INP é mais confiável para medir responsividade, independentemente de quando a interação acontece na vida da página. O histórico e as diferenças entre as métricas aparecem em Core Web Vitals: o que são LCP, INP e CLS.

Quando não existe valor de INP

Uma página pode não reportar INP. A documentação lista 3 motivos:

• O usuário carregou a página, mas nunca clicou, tocou ou digitou.
• A interação se deu só por gestos não medidos, como rolagem e hover.
• O acesso veio de um bot, crawler ou navegador headless sem script de interação.

Como medir INP

O caminho recomendado é medir no campo e só depois ir ao laboratório.

Em campo, primeiro

É no campo que se descobre qual interação está lenta. Um bom Real User Monitoring (RUM) não entrega só o valor de INP: mostra qual interação específica foi responsável, se ela ocorreu durante ou depois do carregamento e de que tipo foi (clique, tecla ou toque).

O INP aparece no PageSpeed Insights quando o site está elegível ao Chrome User Experience Report (CrUX). O dado vem ao menos em nível de origem e, em alguns casos, de URL.

O CrUX diz se há problema, não o que causou o problema. As diferenças entre ferramentas de campo e de laboratório estão em Lighthouse vs PageSpeed Insights vs CrUX.

Depois, no laboratório

O laboratório faz mais sentido quando o campo já apontou interações lentas, porque o valor depende das interações executadas durante o teste. Algumas ferramentas de laboratório que só observam o carregamento não reportam INP. Nesse caso, o Total Blocking Time (TBT) pode servir como proxy razoável, mas não substitui a métrica.

Para reproduzir interações lentas, siga fluxos comuns de usuário. Outra saída é interagir com a página durante o carregamento, quando a thread principal costuma estar mais ocupada.

Medir com JavaScript

Em JavaScript, é preciso medir os event timings de todas as interações e tomar o 98º percentil no descarregamento da página. A biblioteca web-vitals trata a maioria dos casos especiais descritos abaixo, exceto o caso de iframes:

import { onINP } from 'web-vitals';

// Mede e registra o INP em todas as situações em que ele precisa ser reportado
onINP(console.log);

Limites conhecidos da API

A API do INP tem 5 limites conhecidos, que vão de entradas não reportadas a iframes e abas em segundo plano:

• Entradas de evento abaixo de 104 ms não são reportadas por padrão pelos performance observers. O parâmetro durationThreshold pode mudar isso, mas tem mínimo de 16 ms. Observar também a entrada first-input ajuda a garantir que páginas com interações reportem algum valor.
• Calcular percentis exatos exigiria manter todas as amostras em memória. Aproximar guardando apenas as N piores interações — 10 é uma escolha comum — resolve.
• Se a página é restaurada do back/forward cache, o INP deve ser zerado, porque o usuário vive aquilo como uma visita distinta.
• A API não reporta interações dentro de iframes, mas a métrica considera essas interações. Subframes podem enviar suas entradas ao frame pai.
• Usuários deixam abas abertas por dias, e navegadores móveis normalmente não executam callbacks de unload em abas em segundo plano. Por isso o INP deve ser reportado sempre que a página for para segundo plano e também quando for descarregada, com o cálculo final feito no backend.

Para entender como a responsividade se encaixa nos demais sinais que o Google descreve, vale revisar experiência na página: o que o Google considera.