Como otimizar INP - Guia Core Web Vitals

INP (Interaction to Next Paint) mede a latência entre uma interação do usuário e a próxima atualização visual da página. A maior parte do tempo que alguém passa numa página acontece depois que ela termina de carregar. É nesse tempo que a pessoa clica, toca e digita, e é essa parte da experiência que o INP mede: quão rápido a página responde quando o usuário interage com ela.

O INP mede o tempo entre uma interação e a renderização do próximo quadro e reporta a pior interação de cada visita à página. O Google considera bom qualquer valor abaixo de 200 milissegundos em field data. Em 2026, 77% das páginas móveis passam no critério geral, mas apenas 63% dos 1.000 sites mais visitados conseguem o mesmo, segundo o Web Almanac 2025. Essa divergência diz tudo sobre a métrica: INP é o gargalo dos sites complexos, que carregam mais scripts de terceiros, dependem de frameworks com hidratação no client e processam mais lógica no JavaScript. Este artigo decompõe INP nas suas três fases oficiais e detalha as correções que têm impacto mensurável.

Para o panorama completo das três métricas, veja antes Como medir, diagnosticar e otimizar Core Web Vitals. Para as as outras métricas do CWV, Como otimizar LCP e Como otimizar CLS.

O que INP mede e por que ele substituiu o FID

O INP mede uma coisa específica: o tempo entre o usuário interagir e a tela mostrar que a interação foi registrada. A cada clique, toque ou tecla, o navegador executa o código associado e desenha o próximo quadro com o resultado visual: o item que entra no carrinho, o menu que abre, o campo que acusa erro. O INP não é uma medida média, mas a maior das latências ao longo da visita. Em páginas com muitas interações, a medida descarta uma das mais lentas a cada 50, para não ser definido por uma travada isolada.

O que o INP não mede é tão importante quanto o que ele mede. Ele não cronometra o efeito completo da ação, como a busca na rede, o dado que volta do servidor ou a tela que se atualiza depois. Ele mede só até o primeiro sinal visual de que algo está acontecendo, porque é esse sinal que dá ao usuário a sensação de que a página está viva. Uma operação pode levar segundos para terminar; o que não pode é demorar para começar a responder. Rolar a página também não conta para o INP, pois o scroll não dispara esse tipo de resposta visual.

A substituição do FID (First Input Delay) pelo INP foi oficializada em 12 de março de 2024. A diferença prática é grande: FID media apenas o atraso da primeira interação do usuário, geralmente em uma página recém-carregada. O INP olha a página inteira, do início ao fim da visita, e com isso passou a enxergar problemas que o FID nunca via, como o menu que custa a abrir, o filtro de catálogo que trava por meio segundo, o formulário que demora a validar ou o accordion com lag, por exemplo.

Os limites oficiais aplicados pelo Google são os seguintes:

O percentil de referência continua sendo o p75 do CrUX (Chrome User Experience Report, a base pública de dados reais de usuários do Chrome), mas com a especificidade de que o que entra no cálculo é o p98 das interações de cada sessão individual. Em outras palavras: para o site passar, 75% dos carregamentos de página precisam ter INP abaixo de 200ms.

INP é também uma métrica relevante para a busca generativa. Sistemas como o Bing, que alimenta ChatGPT Search e Copilot, ponderam sinais de experiência do usuário para selecionar fontes confiáveis em respostas geradas por IA e responsividade é um dos sinais mais óbvios de "site funcional" para um crawler.

As três fases de uma interação medida pelo INP

Toda interação tem três momentos em que pode perder tempo, e o INP soma os três. Pense em alguém clicando em "adicionar ao carrinho".

Primeiro, o clique pode ficar esperando. Se o navegador está ocupado executando outra coisa (um script que ainda está carregando, por exemplo), ele só começa a tratar o clique quando termina essa tarefa. Esse tempo de espera, antes de qualquer código da interação rodar, é o input delay.

Depois, o código da interação roda: a função que adiciona o item, atualiza o estado, recalcula o total. Quanto mais pesada essa lógica, mais demora. Esse é o processing time.

Por fim, o navegador precisa desenhar o resultado na tela: o contador do carrinho que muda, o botão que troca de estado. O tempo entre o código terminar e a tela atualizar é o presentation delay, e é aqui que entram recálculo de layout e animações.

Cada fase tem uma causa típica e uma estratégia de correção própria:

Há uma nuance crítica revelada pelo Web Almanac 2024: a presentation delay é geralmente a maior contribuinte para INP ruim na mediana global. Isto é, o tempo entre o handler terminar de executar e o navegador efetivamente pintar a próxima tela é frequentemente o gargalo, e não o tempo do handler em si. Quando o usuário clica em "adicionar ao carrinho" e a interação demora 400ms, é mais provável que o problema esteja em recálculo de layout ou em animações do que na lógica do handler.

Para INP em sites complexos, atacar presentation delay primeiro costuma trazer ganhos maiores e mais rápidos do que otimizar processing time.

Como medir INP corretamente

INP é a única métrica do Core Web Vitals que só existe em sessão real. Não há "INP da página" no Lighthouse porque a métrica depende de interação humana, e o Lighthouse roda sem interação. Existem três caminhos para medição, com nível de esforço crescente:

1. Extensão Core Web Vitals do Chrome e painel Performance Insights do DevTools. Capturam interações reais com breakdown nas três fases. Ideal para reproduzir um INP ruim localmente, navegar o site como usuário e identificar visualmente as interações lentas.
2. PageSpeed Insights e Search Console. Mostram INP em field data, agregado sem detalhe por interação. Útil para identificar quais URLs têm INP ruim, não para diagnosticar a causa.
3. Long Animation Frames API (LoAF). Estável em Chrome desde a versão 123 (início de 2024), substitui a antiga Long Tasks API com granularidade muito maior, atribui causa por script, por handler e por estilo. Combinada com a biblioteca web-vitals.js attribution build, permite enviar para o seu analytics não só o número do INP mas também qual handler, qual script e qual frame causaram o pior tempo.

Por que sites com frameworks costumam ter INP pior

A divergência mais reveladora dos dados de 2024–2025: 77% das páginas móveis passam em INP no geral, mas apenas 63% dos 1.000 sites mais visitados passam. A explicação é estrutural. Sites populares carregam mais scripts de terceiros (analytics, A/B testing, ads, chat), dependem mais de frameworks com hidratação no client e processam mais lógica em JavaScript por interação.

A hidratação em frameworks como React, Vue e Angular é o caso mais ilustrativo. Na renderização no servidor (SSR), o servidor pode mandar o HTML já pronto para que a página seja exibida mais rápido. O usuário vê a tela montada quase de imediato, só que esse HTML chega "morto": os botões estão lá, mas ainda não fazem nada, porque o JavaScript que liga o comportamento a eles ainda não rodou.

Hidratação é justamente esse processo de dar vida ao HTML. O framework percorre a página e reconecta o comportamento a ela: as funções que respondem a cliques e toques (os event handlers) e o estado da interface. O problema é que isso roda na thread principal e, enquanto roda, a página não consegue responder a cliques. Ou seja, a página parece pronta, mas não está interativa.

O custo disso é mensurável. Em medições públicas, a hidratação do site da Deliveroo consome 1,55 segundo de CPU (com throttling 4×, simulando um processador 4× mais lento), a do Walmart 1,10s e a do Notion 1,8s. Se o usuário toca na tela durante essa janela, o clique fica na fila até a hidratação terminar, e o INP daquela visita dispara para a casa dos 1.000ms.

Não é que determinados frameworks sejam intrinsecamente ruins. O peso vem da hidratação completa, em que o JavaScript do site inteiro precisa rodar no navegador antes de a página responder.

Frameworks como o Astro Islands, por exemplo trata a página como HTML estático por padrão e só hidrata os trechos de fato interativos (as "ilhas", como a caixa de busca ou o filtro de catálogo), deixando o resto (textos, descrições, imagens) sem JavaScript nenhum. O Qwik elimina a hidratação: em vez de reexecutar o framework no navegador, carrega o código de cada interação só quando ela acontece. Os React Server Components enviam ao navegador apenas o JavaScript dos componentes marcados como interativos, mantendo o resto no servidor.

A diferença entre as três e o SSR tradicional é sempre a mesma: quanto menos JavaScript precisa rodar no navegador antes da interatividade, menor o input delay nas primeiras interações. É por isso que, em sites com SSR tradicional e hidratação completa, o p75 de INP raramente cai abaixo de 300ms sem mudança arquitetural. Yielding, debounce e adiamento de scripts ajudam, mas nenhum deles elimina o fato de que o navegador ainda tem de executar o JavaScript da página inteira, e esse custo é, em grande parte, fixo.

As correções com maior impacto real

As correções abaixo estão ordenadas da mais simples para a mais trabalhosa, e vale segui-las nessa ordem: as primeiras custam pouco e costumam resolver boa parte dos casos; só faz sentido partir para as últimas, que envolvem refatoração ou conhecimento específico do framework, se o INP continuar alto.

Renderizar sob demanda o que está fora da tela

A correção mais barata: uma única propriedade CSS (content-visibility) faz o navegador pular o trabalho de desenhar as seções que ainda não chegaram perto da área visível, renderizando-as conforme o usuário rola. Em páginas longas, isso reduz o tempo de cada atualização de tela sem mexer em nenhuma linha de JavaScript.

Adiar e enxugar os scripts de terceiros

Tags de anúncio, chat, testes A/B e analytics costumam ser os maiores responsáveis por travar a página e raramente precisam rodar logo de cara. Carregá-los depois do conteúdo principal com um gatilho pós-carregamento no gerenciador de tags, por exemplo, e revisar periodicamente o que de fato precisa estar ali libera a thread principal para responder ao usuário.

Manter o DOM enxuto

Quanto mais elementos a página tem, mais cara fica cada atualização de tela e isso pesa em toda interação, não só no carregamento. Reduzir a quantidade de elementos, mostrando listas longas aos poucos em vez de tudo de uma vez, deixa o navegador desenhar o próximo quadro mais rápido.

Evitar o layout síncrono forçado (layout thrashing)

Acontece quando o código altera o estilo de um elemento e, na sequência imediata, lê uma medida que depende desse estilo, obrigando o navegador a recalcular o layout na hora. Agrupar todas as leituras e só depois todas as escritas evita esse retrabalho. É uma correção localizada, mas que rende bem onde há listas ou animações.

Dividir tarefas longas e ceder a thread com frequência.

Quando uma função demora muito, ela segura a thread principal e o clique do usuário fica esperando. A ideia é quebrar esse trabalho em pedaços e, entre eles, devolver o controle ao navegador para ele responder às interações pendentes, atualizando primeiro o que aparece na tela e deixando o resto (salvar, validar, recalcular) para logo depois. Em buscas e filtros em tempo real, vale o mesmo princípio: o campo deve responder na hora, enquanto a lista pesada se atualiza um instante depois. Você pode ver mais detalhes sobre isso neste artigo do Google sobre otimização de tarefas longas..

Tirar o trabalho pesado da thread principal (Web Workers)

Cálculos realmente pesados como processar arquivos grandes ou validações complexas podem rodar em paralelo, numa thread separada, deixando a principal livre para responder ao usuário. Tem mais custo de implementação e só compensa acima de certo volume de trabalho, por isso vem depois das correções mais simples.

Aproveitar os recursos do próprio framework.

React, Vue e Angular trazem ferramentas próprias para marcar atualizações como não urgentes, evitar re-renderizações desnecessárias e adiar a hidratação das partes não críticas da página. Exige conhecer bem o framework, por isso essa recomendação fica por último, mas, quando bem aplicada, resolve casos que as correções genéricas não alcançam. Saiba mais na documentação oficial de cada um: React, em useDeferredValue e useTransition; Vue, no guia de performance; Angular, em ignorar subárvores na detecção de mudanças.

O que mudou em INP entre 2024 e 2026

Março 2024. INP substitui FID oficialmente como Core Web Vital. Em paralelo, Chrome 123 estabiliza a Long Animation Frames API, abrindo diagnóstico granular para problemas de responsividade.

Final de 2024. scheduler.yield() estabiliza em Chromium, oferecendo o primeiro padrão nativo de yielding com preservação de prioridade. Frameworks como React, com useTransition e Selective Hydration, ganham tração específica para o problema de INP.

2025. Search Console destaca páginas com INP ruim como prioridade no relatório de Core Web Vitals. A taxa global de aprovação em INP sobe para 77% mobile, mas a gap entre sites populares e a média geral mantém-se em torno de 14 pontos percentuais — sinal de que o problema é estrutural, não conjuntural.

2026. Discussão em aberto entre engenheiros do Chrome team sobre se 200ms é um threshold leniente para devices modernos. Sem mudança oficial até o momento. A direção provável de evolução é endurecer o threshold ou reportar percentis adicionais (p95 da sessão, além do p98).

Como monitorar INP em produção

Quatro práticas operacionais que separam times que sustentam INP dos que vivem ciclo de regressão-correção:

1. RUM (Real User Monitoring, monitoramento de usuários reais) próprio com web-vitals.js attribution. Captura INP por template, por device class (mobile/desktop), por país, com a atribuição de causa via LoAF. Regressão em INP costuma vir concentrada num único template (busca, filtro, checkout) e num único device class — sem segmentação, o problema fica invisível na média.
2. Alerta automático sobre p75 de INP por template. Se exceder 200ms em três dias consecutivos, ticket. Para times com analytics que aceitam alertas declarativos (BigQuery, Looker), uma query agendada resolve.
3. Auditoria pré-launch focada em main thread. Toda feature nova com handler de evento deve passar por Performance panel do DevTools com throttling 4× CPU. O p98 das interações no painel é uma boa aproximação de como a feature vai performar em produção.
4. Revisão trimestral de scripts de terceiros. Inventário do que está carregando, prioridade de cada um, e custo medido em main thread. Sem essa revisão, o número de scripts cresce monotonicamente e o INP regride.

Para sites grandes, o relatório de field data do CrUX no Search Console é insuficiente isoladamente pois mostra dados agregados. RUM próprio com segmentação por template é a única forma de ter sinal acionável.

Perguntas frequentes sobre INP

Scroll conta como interação para INP?

Não. INP mede apenas interações que disparam event handlers — clique, toque, teclado. Scroll passivo não dispara handler por padrão e não é avaliado pela métrica. Scroll com handlers programáticos (onScroll) pode disparar handlers, mas o efeito visual do scroll em si não é considerado.

Preciso trocar de framework para corrigir INP?

Quase nunca. A maioria dos sites consegue chegar em INP abaixo de 200ms aplicando yielding, debounce de re-render, adiamento de scripts terceiros e Selective Hydration onde aplicável sem mudar framework. Trocar arquitetura para Astro Islands ou Qwik faz sentido por outras razões (bundle menor, melhor SEO, simplicidade), não para corrigir INP isoladamente.

Minha página tem INP ruim só em mobile. Por quê?

CPUs mobile, especialmente em Android mais antigos têm de 4 a 8 vezes menos performance que desktop modernos. Tarefas que levam 50ms no desktop levam 200–400ms no celular. A correção é medir INP separadamente em desktop e mobile, e priorizar correções nos templates piores em mobile.

Vale a pena usar Partytown para mover scripts de terceiros para Web Worker?

Para sites com 10+ scripts de terceiros e INP acima de 500ms, sim, o ganho é mensurável. Para sites com 2–3 scripts, o overhead de configuração não compensa. Avaliar caso a caso, e medir antes/depois com RUM em produção, não só com Lighthouse.

Posso ter INP acima de 200ms em uma URL específica e ainda passar no Core Web Vitals?

Sim. INP é avaliado por origin (site inteiro), não por URL individual. Uma página com INP ruim afeta a média geral, mas não reprova o site sozinha. O Search Console indica as piores URLs para corrigir prioritariamente porque costumam estar entre as mais visitadas.

scheduler.yield() funciona no Safari?

Até maio de 2026, ainda não. Safari e Firefox não implementaram a API. O padrão recomendado é detecção de feature + fallback para setTimeout(0). A perda de prioridade no fallback é aceitável para a maioria dos cenários, o ganho principal do yielding é dar à main thread a chance de processar interações pendentes, e isso o setTimeout faz, mesmo sem preservar prioridade.

Qual é a diferença entre scheduler.yield() e requestAnimationFrame?

scheduler.yield() cede a thread principal para que outras tarefas (incluindo interações do usuário) sejam processadas, mas não garante que um paint ocorreu antes da continuação. requestAnimationFrame agenda código para executar exatamente antes do próximo paint. Para responsividade pura, scheduler.yield() é o padrão. Para garantir que a UI atualizou antes de continuar (caso clássico: mostrar um spinner antes de uma tarefa pesada), o padrão requestAnimationFrame + setTimeout é o correto.

---

Para validar se sua página atende ao critério de INP e aos outros 60+ critérios técnicos de SEO, use o SEO Check. Para entender se seu site está preparado para ser citado por motores de busca generativa como ChatGPT, Perplexity e Copilot, use o GEO Check.

Continue lendo

SEO Técnico Análise de SEO: o que verificar e como fazer um diagnóstico 12 min de leitura SEO Técnico Como otimizar CLS - Guia Core Web Vitals 13 min de leitura