Otimizar Core Web Vitals no WordPress significa cortar LCP, INP e CLS abaixo do limite do Google. Segundo o web.dev (2024), LCP bom fica abaixo de 2,5 s, INP abaixo de 200 ms e CLS abaixo de 0,1. O maior ganho vem de cache e TTFB, não de plugin extra. Comece medindo o campo, depois ataque o gargalo real.

Core Web Vitals são as três métricas de experiência que o Google usa para medir carregamento, resposta e estabilidade visual de uma página. No WordPress, a maioria das falhas vem de hospedagem lenta, imagens sem dimensão e JavaScript de tema pesado, não do CMS em si. A gente vê no suporte da FULL que o site reprova no PageSpeed Insights mas o dono nem sabe qual das três métricas falhou. Este tutorial mostra como medir cada uma, achar o gargalo e corrigir em 5 passos, com as ferramentas certas e os limites de cada plugin. Para o panorama completo do tema, o hub de conteúdos de performance WordPress reúne os guias relacionados.

Primeiros passos: O que medir antes de otimizar

Antes de mexer em plugin, meça as três métricas: o LCP precisa ficar abaixo de 2,5 s, o INP abaixo de 200 ms e o CLS abaixo de 0,1, no percentil 75 dos acessos reais. Otimizar Core Web Vitals sem saber qual das três falha é desperdício de tempo. A tabela abaixo aponta onde cada uma quebra no WordPress.

O CLS costuma ser o mais barato de resolver, enquanto o LCP depende da infraestrutura. Por isso, antes de instalar um plugin de cache, vale entender por que o tempo de resposta está alto. Nosso guia sobre como reduzir o TTFB no WordPress detalha a parte de servidor que nenhum plugin de cache compensa sozinho.

Por que o score do Lighthouse engana

O score do Lighthouse (laboratório) difere dos Core Web Vitals que o Google usa para ranquear, que vêm do campo (CrUX), com dados reais dos últimos 28 dias. Dá para tirar 95 no Lighthouse e reprovar no Search Console, porque o laboratório roda num ambiente controlado, sem a rede 4G ruim do visitante real.

A gente vê no suporte da FULL clientes que comemoram o número verde do PageSpeed e não entendem por que o ranking não mexe.

O Lighthouse serve para diagnóstico, não para veredito. Use o relatório dele para achar o que corrigir, mas confie no Core Web Vitals de campo do Search Console para saber se passou. A divergência entre laboratório e campo aparece com frequência em sites com cache mal configurado, em que o robô recebe HTML otimizado e o usuário recebe a versão lenta. Confirme sempre nas duas fontes antes de declarar vitória.

Passo a passo: Como otimizar Core Web Vitals no WordPress

Otimizar Core Web Vitals no WordPress segue uma ordem: medir, atacar o LCP via cache e TTFB, estabilizar o CLS, reduzir o INP e revalidar no campo. Pular a medição faz você gastar esforço na métrica errada. Os cinco passos abaixo seguem essa sequência, do gargalo mais pesado (carregamento) ao mais barato (estabilidade visual), e fecham com a revalidação que confirma o ganho.

Passo 1: Meça o campo de dados reais no Search Console

Rode a URL no PageSpeed Insights e leia primeiro o bloco “Dados de campo”, não o “Dados de laboratório”. O campo mostra o LCP, o INP e o CLS reais do percentil 75. Em seguida, abra o relatório de Core Web Vitals do Search Console para ver o agregado do site inteiro por grupo de URLs. Anote qual das três métricas está em vermelho. Sem esse diagnóstico, qualquer otimização vira tentativa e erro.

Passo 2: Ative cache de página e ataque o TTFB

O LCP cai quando o servidor responde rápido, e o cache de página é a correção de maior impacto: ele entrega HTML pronto sem reprocessar PHP a cada visita. Ative o WP Rocket ou o LiteSpeed Cache e confira o TTFB depois. Se o TTFB continuar acima de 600 ms mesmo com cache, o gargalo é a hospedagem, e nenhum plugin resolve. Esse é o ponto que mais reprova: o cache de página acelera o WordPress quando o gargalo não é o servidor.

Passo 3: Estabilize o layout para zerar o CLS

O CLS cai quando todo elemento que carrega depois do texto já tem espaço reservado. Defina width e height em toda imagem, reserve altura para banners e anúncios, e carregue fontes com font-display: swap para evitar o salto de texto. Imagens sem dimensão definida somadas a um carrossel de tema geram reflow no carregamento e empurram o CLS acima de 0,1. Essa correção costuma ser a mais rápida de todas e não depende de infraestrutura.

Passo 4: Reduza o INP cortando JavaScript

O INP melhora quando você tira peso da thread principal: adie scripts não críticos, remova plugins que injetam JavaScript em toda página e limite o que roda no carregamento. O Perfmatters desativa assets por página e o WP Rocket adia a execução de scripts. Cuidado com o Delay JavaScript Execution agressivo: combinado com scripts inline do Elementor PRO, ele melhora o número no laboratório mas quebra a interação real no campo. Teste cada exclusão antes de publicar.

Passo 5: Revalide no campo após 28 dias

Os Core Web Vitals de campo usam uma janela móvel de 28 dias, então o ganho não aparece no dia seguinte. Republique, limpe o cache e aguarde o CrUX acumular acessos reais. Acompanhe o relatório do Search Console semanalmente: a curva de URLs “Boas” sobe de forma gradual, não de uma vez. Se você trocar de plugin a cada dois dias, nunca vai ter dados estáveis para saber o que funcionou. Paciência aqui é parte do método.

Quais ferramentas usar em cada métrica

Cada métrica tem a ferramenta certa: o PageSpeed Insights dá o campo e o laboratório juntos, o Lighthouse roda no Chrome DevTools para depurar, e o CrUX Dashboard mostra a tendência histórica do domínio. Para diagnóstico de imagem e cascata de rede, o GTmetrix complementa com o waterfall. Usar a ferramenta errada leva à conclusão errada: o Lighthouse sozinho não prova aprovação porque não reflete o usuário real.

Segundo o HTTP Archive (2024), que rastreia milhões de páginas por CMS, a mediana de LCP de sites WordPress no mobile ainda fica acima do limite de 2,5 s, o que confirma que a maioria reprova por carregamento, não por estabilidade. Para escolher e comparar as opções, veja nossa lista de ferramentas para testar desempenho no WordPress. Combine duas fontes no mínimo: nunca decida com base num único teste.

Onde os plugins de cache se diferenciam

Os plugins de cache competem em dimensões diferentes, e escolher o errado para o ambiente desperdiça configuração. O WP Rocket compete por simplicidade de configuração; o LiteSpeed Cache, por integração no nível do servidor, e só entrega o máximo em hospedagem LiteSpeed; o Perfmatters, por controle granular de assets por página.

A gente vê no suporte da FULL que boa parte dos conflitos vem de empilhar dois plugins de cache ao mesmo tempo. A escolha certa depende do servidor e do controle que você quer. Para decidir rápido, use a árvore abaixo.

• Se você está em hospedagem LiteSpeed → use o LiteSpeed Cache, que integra no nível do servidor.
• Se você quer configuração simples em qualquer host → use o WP Rocket e ative cache, lazy-loading e adiamento de scripts.
• Se o problema é JavaScript de plugin em páginas específicas → use o Perfmatters para desativar assets por página.
• Se o TTFB continua alto com cache ativo → o gargalo é a hospedagem; troque de servidor antes de instalar mais plugin.

Comparar os melhores plugins de cache para WordPress ajuda a fechar a decisão com base no seu stack. Nunca rode dois plugins de cache de página simultâneos: a dupla camada serve HTML desatualizado.

Imagens e fontes: O ganho barato de LCP e CLS

Imagem é a maior fatia de peso de uma página WordPress, e tratar isso melhora LCP e CLS de uma vez. Converta para WebP, defina width e height em todas e ative lazy-loading nas imagens abaixo da dobra, mantendo a imagem de destaque (a do LCP) com carregamento prioritário.

Aplicar lazy-loading na imagem principal por engano atrasa o LCP em vez de melhorar. O equilíbrio está em adiar o que está fora da tela e priorizar o que aparece primeiro.

O detalhe que escapa: a imagem responsável pelo LCP nunca deve ter lazy-loading, porque o navegador adia o download justamente do elemento que o Google cronometra. Nosso tutorial de lazy load para imagens e vídeos mostra como excluir a imagem de destaque da regra. Combine isso com fontes em font-display: swap e a parte visual dos Core Web Vitals fica resolvida na maioria dos cenários testados.

Acelere o WordPress com o bundle da FULL

Montar essa stack de performance avulsa custa caro: o WP Rocket, o Perfmatters e os demais plugins premium somam centenas de reais por ano em licenças separadas. No plano PRO da FULL, por R$849 ao ano para até 10 sites, sai R$85 por site com todos os plugins inclusos, já atualizados e ativados em um clique.

A gente vê no suporte da FULL que parte do tempo de quem otimiza Core Web Vitals vai embora só gerenciando licença e versão de plugin: em vez de comprar, renovar e atualizar cada plugin de cache e otimização um a um, a stack inteira já chega pronta. Veja os planos da FULL para comparar o que entra em cada um e qual cobre o número de sites que você gerencia.

Legenda: o relatório de campo do Search Console é a fonte que define se o site passou nos Core Web Vitals, não o score de laboratório.

Perguntas frequentes sobre Core Web Vitals no WordPress

Próximos passos para acelerar o site

Otimizar Core Web Vitals no WordPress não é instalar um plugin mágico: é medir o campo, atacar o gargalo real e revalidar com paciência. Comece pelo diagnóstico no PageSpeed Insights e no Search Console, ataque o LCP com cache e TTFB, zere o CLS reservando espaço para imagens e corte JavaScript para o INP. A maior parte do ganho vem de hospedagem e cache, não de empilhar ferramentas. Para continuar aprendendo, o guia acelere o WordPress e o FULL Academy reúnem os tutoriais de performance em um só lugar.