O INP mede quanto seu WordPress demora para responder a um clique, e o culpado quase sempre é JavaScript de terceiros. Segundo a web.dev (2024), um INP bom fica abaixo de 200 ms e um ruim passa de 500 ms. Cada chat ou pixel some 50 ms a 150 ms à thread principal. Meça, isole o handle pesado e adie o resto.
O INP é a métrica de Core Web Vitals que registra a latência da pior interação do usuário com a página, do clique até o próximo quadro pintado na tela. Desde março de 2024, ele substituiu o antigo FID e passou a valer no ranqueamento do Google. No WordPress, o problema raramente está no tema ou na hospedagem: está no JavaScript de terceiros que trava a thread principal. Este guia mostra como medir o INP, achar o script culpado e baixar a métrica em cinco passos, sem precisar de servidor novo. Para o contexto maior de velocidade, veja os conteúdos de performance WordPress da FULL.
Diagnóstico rápido: O que o INP mede e onde ele falha
O INP no WordPress reprova quando passa de 200 ms, e a faixa “ruim” do Google começa em 500 ms, segundo a web.dev. A diferença para o LCP é direta: o LCP mede a pintura inicial da página, enquanto o INP mede a responsividade de cada interação ao longo da sessão inteira do usuário.
Um site pode carregar rápido e mesmo assim ter INP péssimo se o primeiro clique espera a thread principal liberar. A tabela abaixo separa as três métricas para você saber qual gargalo está atacando antes de mexer no código.
| Métrica | O que mede | Limite “bom” (Google) | Causa comum no WordPress |
|---|---|---|---|
| INP | Latência da interação até o próximo quadro pintado | Abaixo de 200 ms | JavaScript de terceiros bloqueando a thread principal |
| LCP | Tempo até pintar o maior elemento visível | Abaixo de 2,5 s | Imagem grande sem otimização ou TTFB alto |
| CLS | Estabilidade visual durante o carregamento | Abaixo de 0,1 | Fontes e anúncios sem dimensão reservada |
Nos tickets de performance da FULL (150 mil sites), o padrão se repete: o site abre rápido, mas o INP fica vermelho porque o clique espera scripts de chat e remarketing. Para entender o conjunto completo das três métricas, o guia de Core Web Vitals no WordPress detalha cada uma com exemplos.
Por que o INP do WordPress quase sempre é JavaScript
O INP degrada porque a thread principal do navegador só processa uma tarefa por vez, e cada script de terceiros enfileira trabalho nessa fila. Em testes de campo, scripts de chat, pixels de remarketing e ferramentas de A/B costumam somar de 50 ms a 150 ms cada um ao tempo de resposta do primeiro clique do usuário.
A relação causal é específica e observável. JavaScript de terceiros carregado no head sem defer, com a thread principal já ocupada, resulta em INP acima de 500 ms no primeiro clique, mesmo num site que pontua bem em LCP. Esse é o gargalo que o INP (Interaction to Next Paint) foi criado para expor, e que o antigo FID não enxergava porque media só o primeiro toque. Na maioria dos casos testados, o problema some quando você adia os scripts certos, sem trocar de hospedagem nem reescrever o tema.
Passo a passo: Como reduzir o INP no WordPress
Reduzir o INP no WordPress segue uma ordem que evita retrabalho: primeiro medir no campo, depois isolar o handle culpado, e só então aplicar o adiamento. Pular a medição de campo é o erro mais comum, porque o resultado varia conforme o dispositivo real do usuário.
Os cinco passos abaixo usam ferramentas gratuitas (PageSpeed Insights, Chrome DevTools e CrUX) antes de qualquer plugin pago, e cada etapa tem um check de validação claro para você confirmar o ganho antes de seguir para a próxima.
Legenda: o relatório de campo do PageSpeed Insights mostra o INP real dos usuários, não só o valor de laboratório.
Passo 1: Meça o INP de campo no PageSpeed insights
Comece medindo o INP real no PageSpeed Insights, que puxa os dados de campo do CrUX (Chrome User Experience Report). O valor que importa é o da seção “Descubra o que seus usuários reais estão experimentando”, não o de laboratório, porque o INP depende de cliques reais. Anote o número: acima de 200 ms já precisa de ação, acima de 500 ms é prioridade. Rode a medição no mobile, onde a thread principal é mais lenta e o INP costuma ser pior.
Passo 2: Reproduza a interação lenta no chrome DevTools
Abra o site no Chrome, ative a aba Performance do Chrome DevTools e grave enquanto repete o clique que parece travar. O painel mostra as long tasks (tarefas acima de 50 ms) que bloqueiam a thread principal durante a interação. Identifique qual arquivo .js aparece no topo das tarefas longas: na prática, é o script que está segurando o INP. Esse passo transforma o número abstrato do passo 1 em um culpado com nome de arquivo.
Passo 3: Identifique os scripts de terceiros pelo nome
Liste os scripts que não são essenciais para o primeiro clique: chat de atendimento, pixel do Meta, Google Tag Manager, ferramentas de A/B e widgets de prova social. Confronte essa lista com as long tasks do passo 2. Em sites WordPress que chegam ao suporte da FULL, o chat e o pixel de remarketing são os dois nomes que mais aparecem segurando o INP. Marque quais podem rodar depois da interação, porque esses serão os que você vai adiar no passo 4.
Passo 4: Adie o JavaScript não essencial com WP Rocket ou Perfmatters
Use o Delay JavaScript Execution do WP Rocket ou o controle de scripts do Perfmatters para adiar a execução até a primeira interação. Atenção à relação causal: o Delay JavaScript Execution ativo com um script de evento essencial sem exclusão faz o clique ficar sem resposta até o usuário interagir de novo. Por isso, exclua do delay os handles que precisam responder ao primeiro toque e adie só chat, pixel e analytics. A configuração correta do WP Rocket mostra onde fica cada exclusão.
Passo 5: Valide o ganho e monitore por 28 dias
Depois de aplicar o adiamento, rode de novo o PageSpeed Insights e confirme a queda no INP de laboratório. Os dados de campo do CrUX, porém, levam até 28 dias para refletir a mudança, porque a janela do relatório é móvel. Por isso, monitore o INP de campo por quatro semanas antes de declarar o problema resolvido. Se o número não cair, volte ao passo 2: provavelmente sobrou um script essencial na thread principal que ainda não foi adiado.
Quanto custa otimizar o INP: Ferramentas e o bundle FULL
Otimizar o INP no WordPress não exige servidor novo, mas exige os plugins certos, e é aí que o custo avulso pesa. O WP Rocket custa cerca de US$59 por site por ano em licença individual, e o Perfmatters soma outra licença anual. Quem cuida de vários sites multiplica essa conta a cada renovação.
No plano PRO da FULL, por R$849, você ativa o bundle completo com WP Rocket, Perfmatters e mais 15 plugins premium já incluídos, em qualquer hospedagem. Diluído pelos sites que o plano cobre, isso fica em torno de R$85 por site, contra a soma das licenças avulsas pagas em dólar. A vantagem é dupla: um custo previsível por site e os mesmos plugins de cache que derrubam o INP já licenciados, sem precisar comprar cada um separado nem controlar datas de renovação. Veja os planos da FULL para comparar a conta por site da sua operação antes de renovar qualquer licença individual.
Quando o INP não é o seu gargalo principal
Nem todo site lento sofre desse problema: se a página demora a aparecer, o gargalo é LCP ou TTFB, não responsividade. A métrica de interação só vira prioridade quando a página pinta rápido mas o clique demora a responder. A árvore abaixo ajuda a decidir onde investir o esforço antes de mexer em qualquer script.
- Se a página demora a aparecer e o INP está abaixo de 200 ms → ataque o LCP e o TTFB do WordPress primeiro.
- Se a página pinta rápido mas o clique trava → o INP é o gargalo; siga os cinco passos.
- Se o INP só é ruim no mobile → priorize adiar JavaScript, porque a thread principal do celular é mais lenta.
- Se o INP piora só em páginas com chat ou formulário → exclua o handle essencial do delay e adie o resto.
A relação entre as três métricas resume a decisão: o INP mede a interação, o LCP a pintura inicial e o CLS a estabilidade. Atacar a métrica errada gasta esforço; para renderização bloqueada, use o guia de remover JS e CSS de bloqueio.
Próximos passos para deixar o WordPress responsivo
O INP recompensa quem trata a causa, não o sintoma: medir no campo, achar o script que trava a thread principal e adiar só o que não precisa rodar no clique. Em testes de campo, esse ciclo resolve a maioria dos casos sem trocar de hospedagem, porque o gargalo costuma ser JavaScript de terceiros, não o servidor. Comece pelo passo 1 hoje, monitore por 28 dias e ajuste a lista de exclusões conforme o resultado. Para seguir aprendendo a acelerar o site, o FULL Academy reúne tutoriais, guias e reviews de performance em um só lugar, e o guia como acelerar o WordPress conecta o INP às demais métricas de velocidade.
Perguntas frequentes sobre INP no WordPress
Por que o INP do meu site WordPress piora depois de instalar plugins de marketing?
Porque cada plugin de marketing injeta JavaScript de terceiros que disputa a thread principal do navegador. Chat, pixel de remarketing e ferramentas de A/B somam de 50 ms a 150 ms cada um ao tempo de resposta do clique. Como o INP mede a pior interação da sessão, basta um desses scripts segurar a thread para a métrica passar de 200 ms. A correção é adiar a execução desses scripts até depois da primeira interação do usuário.
É possível melhorar o INP sem remover os scripts de terceiros?
Sim, e essa é a abordagem recomendada na maioria dos casos. Você não precisa remover o chat ou o pixel: basta adiar a execução deles com o Delay JavaScript Execution do WP Rocket ou o controle de scripts do Perfmatters. Os scripts rodam normalmente, mas só depois da primeira interação, o que libera a thread principal para responder ao clique. Exclua do adiamento apenas os handles essenciais ao primeiro toque, como formulários de checkout.
Qual a diferença entre INP e o antigo FID nos Core Web Vitals?
O FID media apenas o atraso da primeira interação com a página, enquanto o INP mede a latência da pior interação ao longo de toda a sessão. Desde março de 2024, o INP substituiu o FID nos Core Web Vitals do Google justamente porque o FID era fácil demais de passar e não refletia a experiência completa. Um site podia ter FID bom e INP ruim, escondendo cliques lentos que aconteciam depois do carregamento inicial.
Quanto tempo de INP o Google considera bom no WordPress?
O Google considera bom um INP abaixo de 200 ms, segundo a documentação da web.dev. A faixa “precisa de melhoria” vai de 200 ms a 500 ms, e acima de 500 ms o INP é classificado como ruim. Esses limites são medidos no percentil 75 dos carregamentos, separados entre mobile e desktop. No WordPress, o mobile costuma ser o ambiente mais crítico, porque a thread principal do celular processa JavaScript mais devagar que a do desktop.
O que o INP mede exatamente na experiência do usuário?
O INP mede o tempo entre o usuário interagir (clique, toque ou tecla) e o navegador pintar o próximo quadro como resposta visual. Ele captura a interação mais lenta da sessão, não a média, o que o torna um indicador honesto de responsividade. Um INP de 350 ms significa que o usuário esperou um terço de segundo para ver o site reagir ao toque. Quanto mais JavaScript bloqueando a thread principal, maior esse tempo de espera.
















