Como reduzir INP no Core Web Vitals no WordPress (2026)

A responsividade do seu site WordPress em 2026 depende diretamente do INP (Interaction to Next Paint), métrica do Core Web Vitals que substituiu o FID como sinal oficial de experiência de página. Para PMEs, melhorar o INP não é apenas técnico: impacta conversão, leads e percepção de qualidade. Neste guia prático, você verá como diagnosticar, priorizar e reduzir o INP no WordPress, com foco no que realmente move o ponteiro.

O que é INP e por que ele importa em 2026

• O INP avalia a responsividade com base nas piores (ou quase piores) interações do usuário durante a visita. Quanto menor, melhor.
• Limiares oficiais: bom < 200 ms; precisa melhorar entre 200 e 500 ms; ruim > 500 ms. Fontes: Google Search Central e web.dev.
• Em 12 de março de 2024, o INP substituiu o FID como Core Web Vital. Em 2026, o Google continua usando o INP como um dos sinais de experiência de página.

Por que isso importa? Respostas lentas geram desistência. Em sites de PMEs, cada clique ou toque que “trava” a tela pode custar um formulário, um orçamento ou uma compra.

Como o Google mede e reporta o INP

• O PageSpeed Insights (PSI) exibe dados de campo (CrUX) do período móvel de 28 dias e reporta o percentil 75 (p75) de cada métrica, incluindo INP, LCP e CLS. Assim, você avalia a experiência real da maioria dos usuários.
• Esses dados são atualizados diariamente, sempre olhando para os últimos 28 dias. Mudanças no site podem levar algumas semanas para “aparecer” no PSI.
• Combine com o Search Console (relatório de Core Web Vitals) para agrupar URLs com problemas semelhantes e priorizar correções em escala.

Dica prática: acompanhe páginas com tráfego e receita primeiro (home, categorias, landing pages e checkout). O ganho no p75 dessas páginas costuma refletir na origem inteira com o tempo.

Diagnóstico: onde nasce um INP alto

O INP é a soma de três componentes:

1. Atraso de entrada (input delay): o quanto o navegador leva para começar a responder.
2. Tempo de processamento: quanto a thread principal fica ocupada com JavaScript e cálculos.
3. Atraso de apresentação: quanto a UI demora para pintar a mudança na tela.

O vilão frequente é JavaScript em excesso e “long tasks” que bloqueiam a thread principal. Ferramentas essenciais:

• Chrome DevTools (Performance + “INP breakdown”): identifique quais tarefas, funções e scripts causam atraso. Reproduza cliques/rolagens lentas, grave uma sessão e verifique a pilha de chamadas e impactos de layout e renderização.
• PSI/CrUX: confirme se os gargalos observados em laboratório coincidem com dados de campo (p75). Se o laboratório aponta problema e o campo não, priorize com base no impacto real.

WordPress: o que mudou e como ajuda a reduzir INP

Desde o WordPress 6.3, o core suporta estratégias de carregamento de scripts com atributos async e defer via wp_register_script/wp_enqueue_script. Isso diminui bloqueios na thread principal e melhora a responsividade — especialmente em temas e plugins que abraçam a estratégia.

Boas práticas no ecossistema:

• WooCommerce e outros plugins vêm migrando scripts para “defer” quando possível, reduzindo bloqueios iniciais.
• O Web Almanac 2024 (HTTP Archive) relata evolução de performance no WP 6.3, com mais de 170 melhorias, incluindo suporte a estratégias de script. Menos JS bloqueando tende a beneficiar LCP, TTFB e, indiretamente, o INP.

Aplicando no seu tema/plugin:

• Priorize scripts críticos e marque o restante como defer/async onde for seguro.
• No functions.php, revise a forma de enfileirar scripts e remova dependências desnecessárias.

Exemplo simples (ilustrativo):

• Use dependências corretas no wp_enqueue_script e, se o script não é crítico para a primeira interação, aplique defer. Verifique compatibilidade antes para não quebrar funcionalidades.

Principais causas de INP alto (e como agir)

1. Long tasks de JavaScript

• Divida tarefas grandes em blocos menores (requestIdleCallback, setTimeout, scheduler APIs quando aplicável).
• Adie execuções não críticas para depois da primeira interação.
• Separe atualização de UI de cálculos pesados — mova computação para Web Workers quando possível.

2. Ouvintes e eventos mal otimizados

• Use passive listeners para eventos de rolagem/touch quando seguro.
• Aplique debounce/throttle em eventos frequentes (scroll, input, resize).
• Evite “layout thrashing”: agrupe leituras e escritas no DOM para não forçar múltiplos reflows.

3. Scripts de terceiros (tags, analytics, chats, widgets)

• Carregue de forma não bloqueante, com defer/async quando suportado.
• Condicione o carregamento de chats/WhatsApp e widgets sociais ao primeiro input ou à visibilidade (IntersectionObserver).
• Revise periodicamente o que é essencial. Terceiros redundantes ou mal configurados são um dos maiores “comedores” de responsividade, como reforçam relatórios do Web Almanac.

4. CSS e renderização

• Evite CSS pesado em interações. Mantenha animações e transições com propriedades que usam a GPU (transform, opacity) quando possível.
• Minimiza repaints/reflows em componentes interativos; prefira técnicas que não forcem recálculo global de layout.

Passo a passo prático para PMEs no WordPress

1. Mapear as piores interações

• Use PSI/CrUX para conferir o p75 do INP das principais páginas.
• No DevTools, reproduza cliques/abertura de menu, filtros, login/checkout e identifique as tarefas que mais pesam.

2. Enxugar e organizar o JavaScript

• Desative plugins não críticos e remova dependências que não são usadas.
• Quebre bundles grandes e carregue sob demanda (code splitting)
• Mova lógicas pesadas para Web Workers.

3. Aplicar defer/async no WordPress 6.3+

• Scripts não essenciais: marcar como defer
• Scripts que não dependem de ordenação: async (testar compatibilidade)
• Garanta que scripts críticos para a primeira interação permaneçam previsíveis.

4. Terceiros sob controle

• Carregue chat/WhatsApp e widgets somente após o primeiro toque/clique ou quando o usuário rolar até a área.
• Centralize tags em um gerenciador com regras claras e evite duplicidades.

5. Refinar a experiência de UI

• Use passive listeners para scroll/touch, debounce/throttle onde faz sentido.
• Evite leituras/escritas alternadas no DOM; agrupe operações.

6. Medir, publicar, revalidar

• Após otimizações, publique e aguarde o ciclo de 28 dias do PSI para avaliar o p75.
• Use o relatório de Core Web Vitals no Search Console para validar grupos de URLs.
• Em laboratório, confirme no DevTools que as long tasks diminuíram e a UI pinta rapidamente após a interação.

Exemplo prático (cenário comum em PMEs)

Imagine um site institucional WordPress com blog e formulários de contato, além de WhatsApp e um widget de chat. O menu mobile apresenta atraso ao abrir e filtros de blog “engasgam”.

• Ações: adiar o carregamento do chat para após o primeiro clique; aplicar defer nos scripts não críticos; remover dois plugins redundantes; mover uma função de cálculo pesada de listagem para um Web Worker; aplicar passive listeners em scroll e throttle em resize.
• Resultado esperado: as interações mais críticas deixam de ser travadas por long tasks, o tempo até a próxima pintura cai significativamente, e o INP tende a sair da faixa “precisa melhorar” para “bom”. A confirmação vem depois no p75 do PSI, com suporte do Search Console.

Como comprovar o progresso

• Acompanhe o p75 do INP no PSI por página e por origem. Lembre que é uma janela de 28 dias — estabilidade é tão importante quanto o pico.
• O Search Console mostrará grupos de URLs que migraram de “ruim/precisa melhorar” para “bom”.
• Em paralelo, use o DevTools para confirmar que as interações alvo (menu, filtro, formulário) estão respondendo dentro de <200 ms em laboratório.

Perguntas frequentes

INP é a mesma coisa que FID?

Não. O INP substituiu o FID em março de 2024 e mede a responsividade de forma mais abrangente, considerando a pior (ou quase pior) interação na visita, não apenas a primeira.

Quanto tempo leva para ver melhoria no PSI/CrUX depois das mudanças?

Como o PSI usa uma janela móvel de 28 dias, efeitos completos podem levar algumas semanas. Em geral, espere 2–4 semanas para perceber o impacto consolidado no p75.

Devo remover todos os scripts de terceiros para melhorar o INP?

Não necessariamente. Priorize o que é essencial para o negócio e carregue o restante de forma não bloqueante, sob demanda ou após o primeiro input. Revisar, adiar e condicionar costuma trazer bons ganhos sem perder funcionalidades chave.

Melhorar a responsividade do seu WordPress em 2026 é um trabalho contínuo: medir, otimizar, validar e repetir. A MConect integra tecnologia, conteúdo e desenvolvimento para atacar o INP onde ele mais impacta seu funil. Quer um diagnóstico gratuito do seu site e um plano de ação prático? Fale com a nossa equipe agora. Conheça nosso serviço de desenvolvimento de sites em WordPress em /servicos/sites e veja como centralizamos resultados e métricas no nosso Painel MConect em /painel.