O que é INP (Interaction to Next Paint)?

INP significa Interaction to Next Paint — tempo de interação até a próxima renderização. Em português: o INP mede quanto tempo o navegador leva para responder visualmente após o usuário fazer uma interação (clique, toque na tela, teclada).

Se o usuário clica em um botão e a página demora 600ms para dar qualquer resposta visual (mudar cor do botão, abrir menu, navegar), o INP é 600ms. Isso é considerado "ruim" pelo Google.

Por que o INP substituiu o FID?

O FID (First Input Delay) media apenas o primeiro clique do usuário na página. Era fácil de passar — bastava carregar o JavaScript crítico rápido no início e o FID ficava baixo, mesmo que o resto da sessão fosse lento.

O INP é mais rigoroso: ele mede todas as interações durante a sessão e usa o pior percentil 75. Se seu menu hamburger abre rápido mas o formulário de contato trava por 800ms quando o usuário digita, o INP vai refletir isso — mesmo que o FID fosse bom.

Causas mais comuns de INP alto no WordPress

1. JavaScript pesado bloqueando a thread principal

A principal causa de INP alto é JavaScript executando na main thread (thread principal do navegador) quando o usuário tenta interagir. O navegador processa JavaScript e responde a interações na mesma thread — quando há JS pesado rodando, a resposta ao clique do usuário fica "na fila".

No WordPress, os culpados mais comuns são: plugins de formulário com validação pesada, construtores de página (Elementor, Divi) com muitos scripts, plugins de chat ao vivo e scripts de analytics mal implementados.

2. Event handlers lentos

Quando você clica em algo, o navegador executa o event handler do JavaScript correspondente. Se esse handler faz muita coisa de uma vez — consulta ao DOM, cálculos, animações — o tempo de processamento eleva o INP.

Exemplo clássico: um plugin de filtro de produtos no WooCommerce que, ao clicar em um filtro, faz uma requisição AJAX pesada de forma síncrona antes de atualizar a tela.

3. Conteúdo renderizado após interação (paint delay)

O INP mede até o próximo paint — não só o fim do processamento. Se o JavaScript termina de rodar em 50ms mas o navegador demora mais 300ms para renderizar a mudança visual (por layout thrashing ou repaint excessivo), o INP ainda vai ser 350ms.

4. Scripts de terceiros carregando na thread principal

Google Tag Manager com muitas tags, pixels de remarketing (Meta, Google Ads), scripts de chat (Intercom, Zendesk, JivoChat) — cada um desses executa JavaScript que compete com as interações do usuário pela thread principal.

Como medir o INP do seu site

PageSpeed Insights

Acesse pagespeed.web.dev e insira a URL do seu site. Na seção "Dados de campo" você vê o INP real (baseado no Chrome UX Report). Na seção "Diagnóstico", o PageSpeed identifica scripts que bloqueiam a thread principal.

Chrome DevTools — Performance

Com DevTools aberto (F12), vá em "Performance" e clique em Record. Interaja com a página (clique em menus, botões, formulários) e pare a gravação. No flamegraph, procure "Long Tasks" (tarefas acima de 50ms marcadas em vermelho) — essas são as principais contribuidoras para INP alto.

Web Vitals Extension

A extensão "Web Vitals" do Chrome mostra o INP em tempo real enquanto você navega no site. É a forma mais rápida de identificar quais interações específicas estão com problema.

Como reduzir o INP no WordPress

Passo 1 — Identificar os scripts culpados

No PageSpeed Insights, veja a seção "Reduza o trabalho da thread JavaScript principal" e "Evite tarefas longas". Isso lista os arquivos JS com maior impacto. Se forem plugins específicos, considere alternativas mais leves.

Passo 2 — Usar defer e async corretamente

Scripts carregados com defer executam após o HTML ser processado e não bloqueiam o carregamento. Scripts com async executam assim que baixam, podendo ainda bloquear. Para melhorar INP, prefira defer em scripts que não são críticos para a primeira interação.

No WP Rocket e LiteSpeed Cache, isso está em File Optimization > "Load JS deferred".

Passo 3 — Remover ou substituir scripts pesados de terceiros

Avalie cada script de terceiro pelo impacto real no negócio:

• Google Tag Manager com 15+ tags: audite e remova tags não utilizadas
• Chat ao vivo: se a taxa de uso for baixa, considere um botão de WhatsApp estático no lugar de scripts de 200KB
• Pixel do Facebook: carregue com defer ou via GTM com disparo na primeira interação

Passo 4 — Quebrar Long Tasks com setTimeout

Para event handlers pesados no código próprio, use setTimeout(0) para quebrar o processamento em partes menores, liberando a thread principal entre cada chunk:

// Em vez de processar tudo de uma vez:
element.addEventListener('click', () => {
  processarDados(); // 400ms bloqueando a thread
  atualizarUI();
});

// Quebrar em partes:
element.addEventListener('click', () => {
  atualizarUI(); // Resposta visual imediata (~10ms)
  setTimeout(() => {
    processarDados(); // Processamento pesado após o paint
  }, 0);
});

Checklist de otimização de INP

• Medir INP com PageSpeed Insights e Web Vitals Extension
• Identificar Long Tasks no Chrome DevTools > Performance
• Ativar "Load JS deferred" no plugin de cache
• Auditar scripts de terceiros (GTM, chat, pixels) e remover os não essenciais
• Testar em dispositivo mobile de entrada (ou com CPU throttling 4x no DevTools)
• Monitorar via Google Search Console > Experiência da Página

Erros comuns na tentativa de melhorar INP

Erro 1 — Focar só no LCP e ignorar o INP

LCP (velocidade de carregamento) e INP (responsividade a interações) são métricas diferentes. É comum ver sites com LCP excelente mas INP ruim — o site carrega rápido mas trava quando o usuário clica em algo. O Google avalia as três métricas (LCP, INP, CLS) e uma nota ruim em qualquer uma impacta o ranking.

Erro 2 — Otimizar apenas a home e esquecer páginas internas

O INP é medido em todas as páginas onde o usuário interage. Se a página de produto, o blog ou o formulário de contato têm scripts pesados, o INP dessas páginas será ruim — mesmo que a home seja perfeita. Use o Google Search Console para ver o INP por grupo de URLs.

Erro 3 — Usar dados de laboratório como referência principal

O PageSpeed Insights tem dois modos: "dados de campo" (usuários reais, via CrUX) e "dados de laboratório" (simulação). O Google usa dados de campo para ranqueamento. Um site pode ter excelente nota em laboratório mas INP ruim em campo — porque usuários reais com celulares lentos e conexões instáveis experimentam a página diferente da simulação.

Quando chamar um especialista

• INP ruim mesmo após aplicar defer e remover scripts de terceiros
• Construtores de página (Elementor, Divi) como causa identificada — a solução pode exigir refatoração do tema
• WooCommerce com filtros ou buscas dinâmicas gerando Long Tasks
• Queda de posições no Google Search Console após março de 2024 (quando o INP entrou no Core Web Vitals)

Perguntas frequentes sobre INP alto

INP ruim sempre derruba posições no Google?

Core Web Vitals (incluindo INP) é um fator de ranqueamento, mas não o único. Sites com conteúdo muito relevante podem manter posições mesmo com INP ruim. Mas quando dois sites concorrem pela mesma palavra-chave com qualidade de conteúdo equivalente, o que tem melhores Core Web Vitals tende a ganhar. E para cliques em anúncios do Google (Quality Score), o INP impacta diretamente o custo por clique.

O Elementor causa INP alto?

O Elementor carrega scripts próprios que podem contribuir para INP alto, especialmente em páginas com muitos widgets animados ou formulários. As versões mais recentes melhoraram isso, mas ainda é um dos construtores mais pesados. Se o INP ruim estiver concentrado em páginas Elementor, avaliar a migração para um tema mais leve (ou reconstruir as páginas com HTML/CSS customizado) costuma ser a solução mais eficaz a longo prazo.

Quanto tempo para o Google reconhecer a melhora no INP?

O CrUX (Chrome UX Report) que alimenta o PageSpeed e o Search Console é atualizado mensalmente com dados dos últimos 28 dias. Depois de corrigir o INP, você precisa aguardar usuários reais interagirem com a página melhorada. Em 4-8 semanas você consegue ver a melhora refletida nos dados de campo do PageSpeed Insights.

Conclusão: por onde começar

Se o INP do seu site está acima de 200ms, o caminho é:

1. Medir com PageSpeed Insights (dados de campo) e identificar as páginas com problema
2. Diagnosticar com Chrome DevTools > Performance quais scripts estão causando Long Tasks nessas páginas
3. Agir com as soluções de maior impacto: defer em scripts pesados, remoção de scripts de terceiros desnecessários
4. Monitorar via Search Console > Experiência da Página nas próximas semanas

INP é um problema técnico com solução técnica — mas exige diagnóstico preciso. Aplicar otimizações genéricas sem identificar a causa real raramente resolve.