# Core Web Vitals no WordPress: Otimize em 5 passos 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.
Core Web Vitals no WordPress: métrica, limite bom e causa comum
Métrica Limite bom (web.dev) Causa comum no WordPress
LCP abaixo de 2,5 s TTFB alto da hospedagem e imagem de destaque pesada
INP abaixo de 200 ms JavaScript de tema e plugins bloqueando a thread principal
CLS abaixo de 0,1 imagens e anúncios sem dimensão reservada
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. 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

Por que o score de Core Web Vitals do Lighthouse difere do Search Console?

O Lighthouse mede em laboratório, num ambiente controlado, enquanto o Search Console usa dados de campo (CrUX) de usuários reais no percentil 75 dos últimos 28 dias. Dá para tirar 95 no Lighthouse e reprovar no campo, porque o teste de laboratório não reproduz a rede móvel e o aparelho do visitante. Use o Lighthouse para diagnóstico e o Search Console para o veredito de ranking.

É possível passar nos Core Web Vitals sem trocar de hospedagem?

Sim, na maioria dos casos em que o TTFB já fica abaixo de 600 ms com cache de página ativo. Nesse cenário, otimizar imagem, adiar JavaScript e estabilizar o layout resolve LCP, INP e CLS. Mas se o TTFB segue acima de 600 ms mesmo com WP Rocket ou LiteSpeed Cache, o gargalo é o servidor, e aí a troca de hospedagem passa a ser inevitável para chegar ao LCP abaixo de 2,5 s.

Qual métrica de Core Web Vitals pesa mais no ranking do Google?

Nenhuma das três tem peso fixo divulgado, mas o LCP costuma ser o que mais reprova sites WordPress, porque depende de TTFB e imagem pesada. O Google avalia LCP, INP e CLS em conjunto: basta uma das três ficar fora do limite (2,5 s, 200 ms e 0,1) para a URL ser marcada como não "Boa". Por isso vale corrigir a métrica vermelha primeiro, sem ignorar as outras duas.

Quanto tempo o Google leva para atualizar os Core Web Vitals após a otimização?

Cerca de 28 dias, porque o relatório de campo usa uma janela móvel desse período no CrUX. O ganho aparece de forma gradual no Search Console conforme novos acessos reais entram na média, não de um dia para o outro. Trocar de plugin a cada dois dias impede ter dados estáveis. O recomendado é aplicar a correção, limpar o cache e acompanhar a curva semanalmente.

O que causa CLS alto no WordPress na prática?

Elementos que carregam depois do texto e empurram o conteúdo: imagens sem width e height definidos, banners e anúncios sem altura reservada, e fontes que trocam o texto no meio do carregamento. Reservar o espaço de cada elemento e usar font-display: swap costuma derrubar o CLS abaixo de 0,1 rapidamente. É a correção mais barata dos Core Web Vitals, porque não depende de servidor nem de plugin pago.

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