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