Core Web Vitals no WordPress: o guia prático de 2026 (LCP, INP e CLS)

Core Web Vitals são as três métricas que o Google usa para medir a experiência real de quem visita o seu site — e são sinal de ranqueamento. Neste guia explico o que cada métrica significa, como medi-las do jeito certo no WordPress e o que efetivamente move o ponteiro (com a ordem de prioridade que uso nos meus projetos).

As três métricas, traduzidas

O Google avalia os dados de campo — medições de usuários reais do Chrome (relatório CrUX), no percentil 75. Ou seja: não basta ficar verde num teste de laboratório; a experiência precisa ser boa para a maioria dos seus visitantes reais, na rede e no celular deles.

Como medir do jeito certo

1. PageSpeed Insights: mostra campo (CrUX) e laboratório (Lighthouse) lado a lado. Olhe primeiro o campo — é o que ranqueia.
2. Google Search Console → Experiência: lista grupos de URLs com problema — perfeito para priorizar (ex.: “todas as páginas de produto estão ruins de LCP”).
3. Chrome DevTools: para investigar a causa. A aba Performance mostra o elemento do LCP, as tarefas longas de JavaScript que degradam o INP, e cada layout shift do CLS. O passo a passo completo está no meu guia de otimização de sites WordPress lentos.

Como melhorar o LCP no WordPress

O LCP quase sempre é a imagem de destaque ou o título do hero. As correções, em ordem de impacto:

• TTFB primeiro: se o servidor demora 800 ms para responder, o LCP já nasce perdido. Hospedagem decente + cache de página + CDN.
• Não aplique lazy load na imagem do LCP — é um erro comum de configuração de plugin: a imagem principal deve carregar imediatamente (e de preferência com fetchpriority="high").
• Imagem no formato e tamanho certos: WebP/AVIF, dimensionada para o container real.
• CSS crítico inline e fontes com font-display: swap para o texto do hero não esperar download de fonte.

Como melhorar o INP

INP substituiu o FID e é hoje a métrica que mais reprova sites WordPress. O vilão é sempre o mesmo: JavaScript demais.

• Remova ou adie scripts de terceiros que não geram receita (pixels duplicados, chats abandonados, heatmaps esquecidos);
• Plugins de página (builders, sliders, pop-ups) carregam JS em tudo — condicione ao que cada página realmente usa;
• Cuidado com “otimizações” agressivas de delay de JS: elas melhoram nota de laboratório mas podem piorar o INP real, porque todo o JS pendente executa de uma vez na primeira interação do usuário.

Na prática: em lojas WooCommerce, INP ruim costuma vir de tema pesado + excesso de plugins de frontend. Antes de otimizar linha a linha, vale a auditoria de performance da loja — remover 3 plugins redundantes rende mais que mil micro-otimizações.

Como melhorar o CLS

• Toda imagem com width e height (ou aspect-ratio) para o navegador reservar o espaço;
• Reserve altura para banners, embeds e anúncios que carregam depois;
• Fontes: preload da fonte principal evita troca visível de texto;
• Cuidado com barras/pop-ups injetados no topo da página após o carregamento — empurram todo o conteúdo para baixo.

A ordem de prioridade que uso nos projetos

1. Servidor e TTFB (base de tudo);
2. Cache de página + CDN;
3. Imagem do LCP (formato, tamanho, prioridade);
4. Dieta de JavaScript (INP);
5. Dimensões de mídia e fontes (CLS);
6. Medir de novo com dados de campo e iterar.

Foi essa sequência que levou projetos do meu portfólio a TTFB de ~0,16 s e páginas iniciais abaixo de 500 KB em produção.

Plugins de otimização resolvem sozinhos?

Plugins de cache e otimização (WP Rocket, LiteSpeed Cache, Perfmatters e afins) são ferramentas excelentes — nas mãos de quem sabe o que cada botão faz. Os problemas que encontro em auditoria quase nunca são falta de plugin, e sim configuração:

• “Remover CSS não usado” ativado sem safelist, quebrando menus e componentes interativos silenciosamente;
• Delay de JavaScript aplicado a scripts essenciais — a página congela na primeira interação do usuário (INP explode);
• Lazy load aplicado à imagem principal do hero, atrasando o LCP que deveria proteger;
• Dois plugins de otimização ativos ao mesmo tempo, disputando as mesmas otimizações com resultado imprevisível.

A regra que sigo: primeiro corrigir a causa (servidor, imagem, excesso de JS), depois configurar a ferramenta — e sempre validar com dados de campo, não só com a nota do laboratório.

Rotina de monitoramento que recomendo

1. Semanal: olhada rápida no relatório de Experiência do Search Console (2 minutos — só para pegar regressão cedo);
2. Mensal: PageSpeed nas 3–5 páginas que geram receita (home, produto campeão, checkout/contato) com registro dos números;
3. A cada plugin ou mudança de tema: medir antes e depois — a maioria das regressões nasce aqui;
4. Trimestral: auditoria completa com DevTools, do tipo que detalho no guia de diagnóstico de lentidão.

Quer os três verdes sem virar especialista?

O relatório técnico completo (R$ 690) entrega a auditoria dos seus Core Web Vitals com dados de campo, as causas exatas por tipo de página e o plano de correção priorizado — e o diagnóstico inicial é gratuito. Solicitar diagnóstico gratuito →

Perguntas frequentes

Core Web Vitals afetam mesmo o ranqueamento?

Sim — são sinal de ranqueamento confirmado pelo Google desde 2021 (com INP substituindo o FID em 2024). Não são o fator dominante, mas em mercados competitivos desempatam posições, além de melhorarem conversão.

Qual a diferença entre dados de laboratório e de campo?

Laboratório (Lighthouse) é uma simulação na hora do teste; campo (CrUX) é a medição dos seus usuários reais nos últimos 28 dias. O Google ranqueia pelo campo — otimize para ele.

Por que minha nota do PageSpeed é alta mas os Web Vitals reprovam?

Porque a nota é de laboratório e os Web Vitals reportados são de campo. Delay agressivo de JavaScript, por exemplo, engana o laboratório e piora a experiência real. É o caso clássico que encontro em auditorias.

Em quanto tempo os Web Vitals melhoram depois das correções?

O relatório de campo é uma janela móvel de 28 dias — melhoras reais aparecem gradualmente ao longo de 2 a 4 semanas após a correção.