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

URL: https://lucasferraz.com/blog/inp-na-pratica/
Autor: Lucas Ferraz
Publicado em: 2026-09-23

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.

<blockquote class="citavel"><p>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.</p><p><cite><a href="/">Lucas Ferraz</a>, especialista em SEO</cite></p></blockquote>

| 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](https://lucasferrazseo.com/glossario/core-web-vitals/).

## 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:

```js
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](/blog/javascript-e-crawlers-de-ia/). Menos script no cliente costuma ajudar as duas frentes ao mesmo tempo.

## 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

- web.dev, Interaction to Next Paint (INP) (2025) - https://web.dev/articles/inp
- web.dev, INP passa a ser Core Web Vital (2024) - https://web.dev/blog/inp-cwv-launch
- Chrome for Developers, Long Animation Frames API (2024) - https://developer.chrome.com/docs/web-platform/long-animation-frames
- GoogleChrome, biblioteca web-vitals (README) (2026) - https://github.com/GoogleChrome/web-vitals
- HTTP Archive, Web Almanac 2025, capítulo de performance (2025) - https://almanac.httparchive.org/en/2025/performance

---
Sobre o autor: Especialista em SEO, criação de sites e Generative Engine Optimization, Lucas Ferraz é fundador da agência Lucas Ferraz SEO, sediada em Belo Horizonte, e atua desde 2007 ajudando empresas de todo o Brasil a aparecerem no Google, serem compreendidas por sistemas de inteligência artificial e transformarem buscas em oportunidades comerciais.