INP (Interaction to Next Paint)

Interaction to Next Paint (INP) é a métrica oficial do Google que mede a responsividade de uma página web considerando todas as interações do usuário ao longo da sessão. Substituiu o FID (First Input Delay) em 12 de março de 2024 e é uma das três métricas que compõem o Core Web Vitals atual, junto com LCP e CLS. O INP avalia o tempo entre uma interação (clique, toque, tecla) e a próxima atualização visual da página.

O que é o INP (Interaction to Next Paint)?

INP é uma métrica de campo do Google que captura a pior interação relevante de uma sessão de navegação. Quando o usuário clica em um botão, toca em um link ou digita em um campo, o navegador precisa processar o evento, executar o handler em JavaScript e desenhar a próxima atualização visual na tela. O INP mede esse ciclo inteiro em milissegundos.

A métrica entrou em vigor oficialmente em 12 de março de 2024, substituindo o FID como sinal de interatividade dos Core Web Vitals. Hoje compõe junto com LCP e CLS o conjunto de métricas que o Google usa para avaliar experiência de página em buscas mobile e desktop.

O INP é coletado em campo via Chrome User Experience Report (CrUX) e em laboratório através de simulação no Lighthouse e DevTools. Diferente de métricas de carregamento, INP exige interação real do usuário para ser registrado, então só aparece quando há tráfego suficiente.

Para sites WordPress brasileiros, o INP é o ponto fraco mais comum nos Core Web Vitals. Plugins pesados, builders como Elementor com muitos widgets ativos, scripts de terceiros (chat, pixel, analytics) e formulários complexos costumam puxar o INP para cima sem afetar LCP ou CLS.

Por que o INP substituiu o FID em 2024?

O FID tinha duas limitações graves. Mediu apenas a primeira interação da sessão e capturou apenas o atraso de início, não o tempo total até a resposta visual. Sites podiam mostrar FID excelente (abaixo de 100ms) e ainda assim travar o usuário em interações subsequentes, com handlers lentos ou animações pesadas.

O INP corrige isso medindo todas as interações relevantes e capturando o ciclo completo: input delay (atraso até o handler começar), processing time (execução do handler) e presentation delay (tempo até a próxima pintura na tela). Resultado: a métrica reflete melhor o que o usuário sente.

O Google anunciou a substituição com mais de um ano de antecedência. Sites bem otimizados para FID nem sempre passaram para INP — especialmente e-commerces com filtros JavaScript pesados, dashboards e portais com muito conteúdo dinâmico. Quem ignorou o aviso viu queda de score no PageSpeed Insights logo após março de 2024.

A discussão técnica sobre FID ainda tem valor histórico e educacional, mas o que importa hoje para ranking e otimização é o INP.

Como o INP é calculado?

O INP é a soma de três fases que acontecem entre a interação do usuário e a atualização visual seguinte. O navegador mede cada fase em milissegundos e o INP final é o tempo total. Em sessões com muitas interações, o Google considera o percentil 98 — pega a interação mais lenta entre cada 50 registradas, capturando o pior caso típico.

Input delay

É o tempo entre o usuário interagir e o navegador conseguir começar a executar o handler do evento. Esse atraso acontece quando a thread principal está ocupada com outras tarefas (Long Tasks, scripts de inicialização, parsing). Reduzir JavaScript de terceiros e adiar scripts não-críticos ataca essa fase.

Processing time

É o tempo gasto executando o JavaScript que responde à interação — código do tema, plugins, listeners de eventos. Handlers complexos que rodam loops grandes, fazem requisições síncronas ou disparam atualizações de DOM pesadas inflam essa fase. Quebrar tarefas grandes em chunks menores e usar setTimeout ou requestIdleCallback ajuda.

Presentation delay

É o tempo entre o handler terminar e o navegador conseguir pintar a próxima atualização visual. Layouts complexos, animações JavaScript em propriedades de layout (top, left, width) e renderização de listas grandes inflam essa fase. Preferir CSS animations em propriedades transform e opacity é o caminho mais direto de otimização.

Quais são os limites de pontuação do INP?

O Google define três faixas oficiais de classificação para o INP. A meta para qualquer site é manter o percentil 75 das sessões dentro da faixa Good — ou seja, 75% dos usuários precisam ter INP abaixo de 200 milissegundos para o site ser considerado otimizado.

• Good (Bom): menor ou igual a 200 milissegundos
• Needs Improvement (Precisa melhorar): entre 200 e 500 milissegundos
• Poor (Ruim): maior que 500 milissegundos

Para comparar com a métrica anterior, os limites do FID legacy eram menos exigentes em termos absolutos: bom até 100ms, precisa melhorar entre 100 e 300ms, ruim acima de 300ms. Essa diferença numérica engana — o INP captura mais coisa, então passar nele é mais difícil mesmo em sites que tinham FID excelente.

Sites na faixa Poor sofrem rebaixamento direto em buscas competitivas. Sites na faixa Needs Improvement não são penalizados, mas perdem espaço em snippets e experiências de busca enriquecidas. Acima de tudo, INP ruim afeta percepção de qualidade — visitante clica, espera, abandona.

Como medir o INP do seu site WordPress

Existem quatro ferramentas principais para medir INP, gratuitas e oficiais. Cada uma tem um uso específico — combinar todas dá visibilidade completa.

PageSpeed Insights

Acesse pagespeed.web.dev e digite a URL. A seção “Discover what your real users are experiencing” mostra o INP do percentil 75 com dados de campo do CrUX dos últimos 28 dias. É a fonte oficial que o Google usa para ranking. Se a página tem tráfego baixo, aparece “data unavailable” — neste caso, use Lighthouse para estimar via TBT.

Chrome DevTools

Abra o Chrome no site, F12, painel Performance. Grave uma sessão interagindo com a página. O DevTools marca cada interação com tempo total e quebra em input delay, processing e presentation. É a ferramenta para diagnóstico técnico real, sem depender de tráfego acumulado.

Web Vitals Extension

Extensão oficial do Google para Chrome. Mostra LCP, CLS e INP em tempo real enquanto você navega. Útil para QA — testa rapidamente várias páginas do site sem precisar publicar nada. Tem opção de console logging para inspecionar cada interação detalhadamente.

Search Console

Em Google Search Console, na seção Core Web Vitals, o relatório agrupa todas as URLs do site por faixa (Good, Needs Improvement, Poor). É a visão estratégica — mostra quantas páginas do site precisam de otimização e prioriza por volume de tráfego.

Como melhorar o INP no WordPress

Otimizar INP em WordPress envolve atacar JavaScript pesado, handlers lentos e renderização cara. As ações abaixo estão em ordem de impacto: comece pela primeira, meça, depois siga para a próxima.

Reduzir JavaScript de terceiros

Pixels, chats, replays de sessão, ferramentas de heatmap e tags de analytics costumam carregar dezenas de KB de JS executado durante o load. Audite com PageSpeed Insights na seção “Reduce JavaScript execution time” e remova tudo que não traz valor mensurável. Plugins como Asset CleanUp e Perfmatter desativam scripts por página.

Otimizar event handlers

Handlers que rodam código pesado bloqueiam a thread. Substitua loops grandes por iteradores assíncronos, use debounce em eventos como scroll e input, evite manipulação direta de DOM dentro de handlers de clique. Para WordPress, o gargalo costuma estar em plugins de formulário e widgets de carrinho do WooCommerce.

Quebrar tarefas longas

Long Tasks (>50ms na thread principal) são a causa raiz de INP alto. Identifique no Chrome DevTools, painel Performance. Quebre tarefas grandes em chunks menores usando setTimeout(fn, 0) entre processamentos para liberar a thread.

Usar requestIdleCallback

Tarefas não-críticas (analytics, lazy-init de widgets, pré-cálculos) devem rodar em requestIdleCallback. O navegador agenda essas tarefas para momentos de ociosidade, sem competir com interações do usuário. Plugins modernos já usam esse padrão.

Plugin de cache adequado

Cache resolve TTFB e LCP, não INP diretamente. Mas plugins como WP Rocket, LiteSpeed Cache e Perfmatter têm opções específicas para INP: delay JS until interaction, defer não-crítico, exclusão de scripts por página. Combine com lazy loading e minificação de JS.

Otimize as Core Web Vitals do seu site WordPress com a FULL Services. Conheça nossos planos PRO.

INP vs FID vs LCP vs CLS: como cada métrica afeta SEO

Os Core Web Vitals atuais são três: LCP (carregamento), INP (interatividade) e CLS (estabilidade visual). FID foi descontinuado em 2024 e não conta mais para ranking. Cada uma mede um aspecto diferente da experiência e tem limites próprios.

LCP (Largest Contentful Paint) mede quando o maior elemento visível da página termina de renderizar. Limite Good: até 2,5 segundos. Atacado com cache, otimização de imagens, hospedagem rápida e CDN.

CLS (Cumulative Layout Shift) mede quanto o layout pula durante o carregamento. Limite Good: abaixo de 0,1. Atacado com dimensões fixas em imagens, reserva de espaço para anúncios e fontes com font-display swap.

O Google usa as três como sinais combinados. Para a página ser considerada otimizada, todas precisam estar na faixa Good. Falhar em uma derruba o conjunto. Use Lighthouse e performance WordPress contínuos para monitorar.

Perguntas frequentes sobre o INP

O FID ainda é usado pelo Google? Não. Foi descontinuado em 12 de março de 2024 e substituído pelo INP como métrica oficial de interatividade dos Core Web Vitals.

O INP afeta o ranking do Google? Sim. É uma das três métricas oficiais do Core Web Vitals que compõem sinais de página, junto com LCP e CLS, em buscas mobile e desktop.

Qual ferramenta gratuita mede o INP? PageSpeed Insights, Chrome DevTools, Web Vitals Extension e Google Search Console. Todas são oficiais do Google e gratuitas.

Qual deve ser o INP ideal? Abaixo de 200 milissegundos para classificação Good. Entre 200 e 500ms é Needs Improvement. Acima de 500ms é Poor.

Por que meu INP está alto mesmo com o site rápido? O INP mede a pior interação da sessão, não a primeira nem o carregamento. JavaScript pesado, event handlers mal otimizados e renderização cara afetam a métrica mesmo em sites com bom LCP. Um e-commerce com filtros em JavaScript pode ter LCP excelente e INP ruim porque o filtro processa muitos itens a cada clique.

Sites WordPress com muitos plugins, builders visuais e integrações de terceiros são justamente os que mais sofrem com INP. Em vez de revisar plugin por plugin manualmente, a FULL Services entrega o WP Rocket já licenciado e configurado dentro da stack profissional, com cache, controle granular de JavaScript por página, lazy loading inteligente e tuning específico para reduzir Long Tasks. É a forma de manter os Core Web Vitals dentro do verde mesmo em sites complexos com muitos plugins ativos.