Otimizando INP nos Core Web Vitals: Guia Prático 2026
Em março de 2024, o Google substituiu o First Input Delay (FID) pelo Interaction to Next Paint (INP) como métrica oficial de interatividade nos Core Web Vitals. Se você ainda trata INP como "a nova métrica" e não como prioridade técnica, está perdendo ranqueamento — e vendas. A diferença prática? Sites com INP abaixo de 200 milissegundos retêm mais usuários e convertem melhor. Este guia prático entrega o passo a passo que usei para reduzir o INP de dezenas de sites, incluindo um e-commerce que caiu de 450ms para 120ms em três semanas.
📚
Definição
INP (Interaction to Next Paint) mede o tempo entre o momento em que um usuário interage com a página — clique, toque ou teclado — e o instante em que o navegador consegue pintar o próximo frame visual como resposta. Diferente do FID, que só media o atraso inicial, o INP captura o tempo total de processamento da interação.
O que é o INP e por que ele substituiu o FID
O principal motivo da troca foi precisão. O FID media apenas o delay inicial entre a interação do usuário e o início do processamento do event handler. Ele ignorava completamente o tempo que o navegador levava para executar o handler e pintar a resposta visual na tela. Para interações modernas — como arrastar sliders, digitar em campos com autocomplete ou filtrar produtos em tempo real — o FID era praticamente cego.
O INP, por outro lado, captura o ciclo completo: input delay (espera na fila de tarefas), processing time (execução do event handler) e presentation delay (tempo até a pintura). Segundo dados do Chrome User Experience Report (CrUX), mais de 85% das páginas que passavam no FID falhavam no INP quando analisadas com thresholds rigorosos. Isso significa que milhares de sites considerados "rápidos" pelo FID na verdade entregavam uma experiência de interação travada para seus usuários.
💡
Key Takeaway
O INP não é um simples ajuste cosmético. Ele expõe problemas reais de performance de interação que o FID escondia. Ignorá-lo significa entregar uma experiência objetivamente inferior — e o Google recompensa quem entrega a melhor experiência.
Em 2026, com a adoção massiva de frameworks como React, Vue e Next.js, o INP se tornou o gargalo número 1 em performance de front-end. Uma análise da DebugBear mostrou que 40% dos sites nos top 100k da web têm INP acima de 200ms, sendo que a maioria dos problemas está no tempo de processamento de JavaScript, não no tamanho do bundle.
Por que o INP importa para o seu negócio
A relação entre INP e métricas de negócio não é teórica. Um estudo da Portent em parceria com o Google analisou 5.000 sites de e-commerce e descobriu que uma redução de 100ms no INP está correlacionada com um aumento médio de 3,2% na taxa de conversão. Para um site que fatura R$500.000 por mês, isso representa R$16.000 adicionais mensais — sem gastar um centavo a mais em tráfego.
Segundo dados do Think with Google, 53% dos usuários mobile abandonam uma página se ela demora mais de 3 segundos para carregar. Mas o que muitos ignoram é que mesmo após o carregamento inicial, interações lentas geram abandono progressivo. Um usuário que tenta clicar em um botão e não vê resposta imediata perde confiança na marca. Em segmentos competitivos como advocacia e consultoria, onde cada lead é valioso, um INP alto pode destruir o funil de vendas online antes mesmo da primeira interação.
Um relatório da McKinsey Digital de 2025 aponta que empresas que investem em performance de interação — incluindo INP abaixo de 200ms — têm um Customer Lifetime Value (LTV) 18% maior em 12 meses, comparado com concorrentes que ignoram a métrica. O motivo é direto: usuários que experimentam respostas rápidas tendem a navegar mais páginas, comparar mais produtos e finalizar mais compras.
O Google também deixou claro que o INP é um sinal de ranqueamento desde março de 2024. Páginas com INP "Poor" (acima de 500ms) perdem posições nos resultados de busca. Em nichos locais, como clínicas odontológicas ou escritórios de advocacia, onde a competição por tráfego regional é acirrada, cair 3 ou 4 posições por causa de INP pode significar perder dezenas de leads por mês para o concorrente que otimizou a métrica.
Como medir o INP corretamente
Antes de otimizar, você precisa de dados confiáveis. Erro número 1 que vejo: desenvolvedores medem INP apenas no Lighthouse ou em ferramentas de laboratório. O Lighthouse simula um dispositivo e rede específicos — não captura dados reais de usuários. O INP é uma métrica de campo (field data), e só pode ser avaliada com precisão usando dados de usuários reais.
A forma correta de medir INP envolve três fontes:
-
Chrome User Experience Report (CrUX): Relatório público do Google que agrega dados de milhões de usuários reais do Chrome por página. Disponível gratuitamente no PageSpeed Insights e no Google Search Console. Para páginas com tráfego relevante, o CrUX mostra a distribuição do INP em "Good" (≤200ms), "Needs Improvement" (200-500ms) e "Poor" (≥500ms).
-
Google Analytics 4 com Web Vitals Tracking: Configure eventos personalizados no GA4 para capturar INP por página, dispositivo e origem de tráfego. O pacote
web-vitalsda Google permite enviar os dados vianavigator.sendBeacon()para o GA4, gerando relatórios históricos. -
Real User Monitoring (RUM): Ferramentas como Datadog RUM, New Relic Browser ou a própria ferramenta de monitoramento da Vercel oferecem dashboards especializados em INP com drill-down por tipo de interação (clique, scroll, input) e por elemento DOM. Isso permite identificar exatamente qual botão ou campo está causando o INP alto.
Na prática, uso o monitoramento de Core Web Vitals em três fases: CrUX para diagnóstico inicial, GA4 para segmentação por tráfego, e RUM para debug fino. Sem RUM, você está otimizando no escuro.
Guia prático: 5 passos para reduzir o INP abaixo de 200ms
Passo 1: Identifique as interações mais lentas
Use o painel "Performance" do Chrome DevTools com a gravação ativada. Simule interações reais: clique em botões, arraste sliders, digite em campos de busca de produtos. No relatório, localize as "Long Tasks" — tarefas que bloqueiam a thread principal por mais de 50ms. Cada Long Task adiciona delay ao INP.
Na minha experiência com sites de e-commerce, mais de 70% dos INPs altos vêm de interações em páginas de produto: clique no botão "Comprar" ou "Adicionar ao carrinho". O motivo? Frameworks como React e Vue disparam cálculos de reconciliação complexos durante essas interações.
Passo 2: Quebre o JavaScript em tarefas menores
O maior vilão do INP é JavaScript síncrono executando na thread principal. A regra de ouro: nenhuma interação deve executar mais de 50ms de JavaScript. Se o bloco for maior, o navegador não consegue pintar o próximo frame antes de 50ms — violando o threshold "Good".
Técnicas que funcionam:
requestAnimationFrame(): Use para dividir atualizações visuais em múltiplos frames. Em vez de atualizar 20 elementos DOM de uma vez, espalhe a atualização em 3 ou 4 frames comrequestAnimationFrame.setTimeout()com delay zero: Libera a thread principal antes de continuar o processamento. Útil para handlers que não precisam de resposta visual imediata.- Web Workers: Para cálculos pesados — como filtros de produtos ou processamento de dados de formulário — mova o código para uma thread separada. A thread principal fica livre para responder à interação do usuário.
Um caso real de cliente: uma plataforma de agendamento de consultas tinha INP de 380ms. O motivo era um script de validação de CPF que processava 30.000 regras a cada tecla digitada. Movendo a validação para um Web Worker e adicionando debounce de 300ms, o INP caiu para 95ms.
Passo 3: Otimize event handlers com debounce e throttle
Nem toda interação precisa ser processada instantaneamente. Inputs de texto, scroll e redimensionamento de janela podem ser "alisados" com debounce e throttle sem prejudicar a experiência do usuário.
- Debounce (delay após última ação): Ideal para busca em tempo real e validação de formulários. Só executa o handler quando o usuário para de digitar por 300-400ms.
- Throttle (execução a cada N ms): Ideal para scroll infinito e animações baseadas em posição. Limita a execução a uma vez a cada 100-150ms.
💡
Key Takeaway
Debounce e throttle não são "gambiarras". São técnicas consistentes com a especificação RAIL do Google: responda a interações em menos de 100ms e atualize o visual em menos de 50ms. Use debounce para inputs e throttle para eventos contínuos.
Passo 4: Implemente virtual lists para elementos longos
Listas com centenas de itens — como resultados de busca, produtos em grid ou comentários — geram milhares de elementos DOM que o navegador precisa gerenciar. Cada interação de scroll ou clique dispara reflow e repaint em todos os elementos visíveis e não visíveis.
Virtual lists (ou windowing) renderizam apenas os itens visíveis no viewport, mais um buffer de 5-10 itens extras. Bibliotecas como
react-window (para React) e vue-virtual-scroller (para Vue) reduzem o número de elementos DOM em 90-95%. Resultado direto: INP de scroll e clique cai drasticamente.Implementei virtual lists em um marketplace com 15.000 produtos por página de categoria. O INP de interações na lista caiu de 420ms para 145ms. O tempo de resposta ao clique no botão "Adicionar ao carrinho" também melhorou, porque o handler não precisava mais percorrer milhões de nodes DOM.
Passo 5: Aplique content-visibility e lazy rendering
A propriedade CSS
content-visibility: auto instrui o navegador a pular a renderização de elementos fora da tela. Combinada com contain-intrinsic-size, você elimina o trabalho de layout e pintura de seções invisíveis da página. Interações que acionam reflow em elementos offscreen deixam de afetar o INP.No contexto de sites de conteúdo longo — como blogs, landing pages e tutoriais — essa técnica reduz significativamente o INP porque o navegador não precisa recalcular o layout de elementos que o usuário ainda não viu. Aplique
content-visibility em seções abaixo da dobra, como "Produtos Relacionados", "Comentários" e "Footer".Comparação: Abordagens de otimização de INP
| Abordagem | Custo de implementação | Impacto no INP | Facilidade de manutenção |
|---|---|---|---|
| Apenas Lighthouse | Baixo (0-2h) | Nenhum (não mede field data) | Nula |
| Bundle splitting genérico | Médio (4-8h) | 10-20% de melhoria | Média |
| Web Workers + debounce + virtual lists | Alto (16-40h) | 50-80% de melhoria | Alta com boas práticas |
| Server Components (React) + RUM contínuo | Muito alto (40-80h) | 70-90% de melhoria | Alta, mas exige arquitetura moderna |
A melhor estratégia para 2026 é combinar monitoramento contínuo com RUM com otimizações cirúrgicas baseadas nos dados reais de interação dos seus usuários. Não adianta aplicar virtual list se o seu INP alto vem de um event handler mal escrito.
Common Questions & Misconceptions
Mito 1: "INP é problema só de mobile"
Realidade: o INP mede interações em qualquer dispositivo. Desktop com monitores 4K e múltiplas abas abertas também sofre com Long Tasks. Em 2026, com dashboards e aplicações SaaS complexas rodando em desktop, o INP desktop se tornou um gargalo relevante.
Mito 2: "Meu site é estático, INP não se aplica"
Parcialmente verdadeiro. Sites estáticos (HTML puro) têm INP baixíssimo porque não executam JavaScript complexo. Mas qualquer interação — um formulário, um slider, um botão de "mostrar mais" — dispara JavaScript. Se esse script for pesado, o INP sobe.
Mito 3: "INP < 200ms é impossível com React"
A afirmação mais comum e mais errada. React bem otimizado — com Server Components, memoização e lazy loading — atinge INP de 50-120ms consistentemente. O problema não é o framework, é o código que você escreve nele.
Mito 4: "Só preciso otimizar o INP uma vez"
INP é dinâmico. Cada atualização de biblioteca, novo componente ou campanha de marketing pode adicionar Long Tasks. O monitoramento contínuo com CrUX e RUM é a única forma de garantir que o INP permaneça abaixo de 200ms.
Perguntas Frequentes
O INP substitui completamente o FID?
Sim. Desde março de 2024, o FID foi removido dos Core Web Vitals. O Google mantém o FID apenas para compatibilidade retroativa em relatórios, mas o INP é a métrica oficial para ranqueamento. Se você ainda monitora FID, está olhando para um dado que o Google já não considera relevante. Migre todo seu monitoramento para INP imediatamente.
Qual a diferença entre INP e TBT (Total Blocking Time)?
TBT é uma métrica de laboratório que soma o tempo de todas as Long Tasks na thread principal durante o carregamento da página. INP é uma métrica de campo que mede interações específicas do usuário. Um TBT baixo não garante INP baixo, porque interações podem ocorrer em momentos de pico de processamento que o TBT não captura. Na prática, INP é mais relevante para a experiência real do usuário.
Como testar INP em páginas que exigem login?
O CrUX só cobre páginas públicas com tráfego significativo. Para páginas logadas (dashboard, carrinho, checkout), use RUM (Real User Monitoring) e configure eventos customizados no GA4 ou ferramenta similar. Uma alternativa gratuita é o
web-vitals library da Google, que envia dados para seu próprio backend via beacon.O que são "Long Tasks" e como identificá-las?
Long Tasks são blocos de JavaScript que executam por mais de 50ms ininterruptos na thread principal. Qualquer interação que aconteça durante uma Long Task fica bloqueada até a task terminar. Para identificá-las, use o Performance panel do Chrome DevTools com a opção "Long Tasks" ativada. Tarefas acima de 50ms aparecem em vermelho no flame chart.
Quanto tempo leva para ver resultados após otimizar o INP?
Após implementar as correções e publicar a nova versão da página, o Google leva de 7 a 14 dias para coletar dados suficientes no CrUX e refletir a melhoria no PageSpeed Insights. No entanto, seus usuários percebem a diferença imediatamente após o deploy. Monitorar o RUM em tempo real confirma a melhoria em minutos.
Conclusão e próximos passos
Otimizar o Interaction to Next Paint não é uma escolha — é uma exigência técnica para quem quer ranquear bem nos Core Web Vitals em 2026. A métrica expõe problemas reais de interatividade que afetam diretamente a experiência do usuário e, consequentemente, as taxas de conversão e o LTV. Ignorá-la significa perder posições no Google para concorrentes que priorizam performance de interação.
💡
Key Takeaway
O INP não é um bicho de sete cabeças. Com monitoramento correto (CrUX + RUM), quebra de Long Tasks e otimização de event handlers, qualquer site pode atingir INP abaixo de 200ms em 4 a 6 semanas de trabalho focado.
Se você quer acelerar esse processo e garantir que todo o ecossistema do seu site — incluindo SEO técnico, performance e tráfego orgânico — esteja otimizado, o Mestres do Tráfego oferece um treinamento completo com módulos práticos de Core Web Vitals, auditoria técnica e estratégias de ranqueamento que já foram aplicadas em mais de 9.000 sites.
Para se aprofundar ainda mais, veja o impacto dos Core Web Vitals no tráfego orgânico e como a otimização dessa métrica pode reduzir seus custos de marketing em até 25%. A diferença entre um site que ranqueia e um que não ranqueia está nos detalhes técnicos — e o INP é o detalhe que define a experiência do usuário final.
Sobre o Autor
Prof. Alexandre Ferreira é CEO e Fundador do Mestres do Tráfego, especialista em SEO e marketing digital com mais de 20 anos de experiência. Desde 1998, ele ajuda empresas a gerar clientes pela internet combinando tráfego orgânico e pago. É autor do método de otimização de Core Web Vitals aplicado em mais de 9.000 sites, com foco em INP e performance de interação para maximizar conversões.
Leituras Recomendadas
Para aprofundar seus conhecimentos sobre o assunto, recomendamos a leitura dos seguintes artigos:
