Para Core Web Vitals WordPress como melhorar, meça LCP, INP e CLS de campo e ataque hospedagem, cache e mídia. Segundo o web.dev (2024), a meta é LCP até 2,5 s, INP até 200 ms e CLS até 0,1 no percentil 75. O maior ganho vem de servidor com TTFB abaixo de 800 ms e imagem em WebP. Meça antes de mexer.
Os Core Web Vitals são as três métricas com que o Google mede a experiência real de quem acessa o seu site no WordPress. Melhorar os Core Web Vitals no WordPress significa medir LCP, INP e CLS com dados de campo e corrigir a métrica que está ruim, não todas ao mesmo tempo. Este guia faz parte do conteúdo de performance no WordPress da FULL e se aprofunda no guia de aceleração do WordPress. A gente vê no suporte da FULL que a maioria das reprovações vem de poucas causas repetidas: imagem pesada, servidor lento e excesso de script de plugin.
O que são os Core Web Vitals e suas metas
Os Core Web Vitals são três métricas de campo que pontuam carregamento, estabilidade visual e resposta à interação, com metas claras: LCP até 2,5 s, INP até 200 ms e CLS até 0,1 no percentil 75 dos acessos do seu site. O Google usa esses números reais para avaliar a página.
Cada métrica reprova por um motivo diferente, então o caminho é descobrir qual está ruim e tratar exatamente aquela, com a ferramenta certa. A tabela abaixo resume o que cada uma mede e onde validar, antes de partirmos para a otimização passo a passo.
| Métrica | O que mede | Meta (campo) | Onde validar |
|---|---|---|---|
| LCP | Tempo até o maior elemento aparecer | Até 2,5 segundos | PageSpeed Insights |
| INP | Atraso da resposta à interação | Até 200 ms | CrUX e campo do PSI |
| CLS | Deslocamento visual no carregamento | Até 0,1 | Lighthouse e campo |
| TTFB | Resposta inicial do servidor | Até 800 ms | guia de TTFB |
Pré-requisitos: O que medir antes de otimizar
Antes de mexer em qualquer ajuste, tenha em mãos os números de campo dos três Vitals, porque otimizar sem medir leva a tratar o sintoma errado e desperdiçar horas. A grande maioria dos sites que chegam ao suporte da FULL reprova por uma única métrica, não pelas três. Garanta estes pontos antes do passo a passo:
- Acesso ao PageSpeed Insights, que mostra laboratório e campo na mesma tela.
- Os dados de campo do CrUX, que refletem visitantes reais dos últimos 28 dias.
- Um backup completo, porque a otimização mexe em mídia, cache e código.
- A noção de cada métrica: LCP, CLS e INP.
- Hospedagem com TTFB abaixo de 800 ms, base de qualquer Vital aprovado.
Com esses números de Core Web Vitals registrados como ponto de partida, você ataca a métrica certa, evita mexer no que já estava bom e comprova o ganho real com dado depois de cada mudança aplicada.
Passo a passo: Como melhorar os Core Web Vitals no WordPress
Este procedimento ataca as três métricas na ordem do menor custo de correção: primeiro o que se resolve com mídia e layout, depois o que exige enxugar JavaScript. Em média, corrigir LCP e CLS já recupera a aprovação em boa parte dos sites de conteúdo, e o INP entra como ajuste fino no final.
Siga os quatro passos abaixo na sequência, medindo o campo no PageSpeed Insights a cada etapa para confirmar o efeito antes de avançar para a próxima correção.
Passo 1: Meça LCP, INP e CLS de campo
Comece medindo as três métricas com dados de campo, porque sem saber qual reprova você otimiza no escuro e arrisca mexer no que já estava bom. Rode a URL no PageSpeed Insights, anote os valores de partida e cruze com o relatório de Core Web Vitals do Search Console, que agrupa páginas semelhantes. A gente vê no suporte da FULL que a métrica reprovada aponta a causa: LCP costuma ser mídia ou servidor, CLS é layout e INP é script de plugin. Guarde esse retrato inicial para comparar depois de cada correção e provar o ganho com número, não com sensação.
Passo 2: Ative cache e reduza o TTFB do servidor
Ataque a base com cache de página e um servidor de TTFB abaixo de 800 ms, porque o LCP depende muito do tempo de resposta inicial antes de qualquer pixel aparecer. Imagem de destaque sem compressão somada a servidor com TTFB alto entrega LCP acima de 2,5 s no campo, mesmo com plugin de cache ativo. Configure um plugin de cache como o WP Rocket, sirva a imagem principal em WebP comprimido e priorize o carregamento do elemento maior. Resolver hospedagem e mídia de destaque costuma trazer o LCP para baixo dos 2,5 s sem grande esforço, porque são esses dois fatores que dominam o tempo de pintura.
Passo 3: Dimensione a mídia para zerar o CLS
Defina largura e altura para toda imagem, vídeo e iframe, reserve espaço para anúncios e elementos que carregam depois, e evite injetar conteúdo acima do que o leitor já está vendo. Imagens sem dimensão fixa somadas a fontes que trocam durante o load empurram o texto e estouram o CLS acima de 0,1, com elementos pulando na tela. Cuidado com banners e pop-ups tardios. A gente vê no suporte da FULL que apenas dimensionar a mídia resolve a maioria dos casos de CLS, sem tocar no servidor. Manter o layout estável do primeiro ao último frame é o que segura a métrica abaixo de 0,1 e evita o clique no lugar errado.
Passo 4: Enxugue o JavaScript para baixar o INP
Reduza e adie scripts pesados, remova plugins que carregam JavaScript em todas as páginas sem necessidade e quebre tarefas longas na thread principal em pedaços menores. Plugins disparando script em toda página somados a tarefas longas no navegador empurram o INP acima de 200 ms e geram a sensação de site travado ao clicar. Ferramentas como Perfmatters ajudam a desativar scripts por página, e o cache de página reduz o trabalho do servidor. A gente vê no suporte da FULL que INP ruim é quase sempre excesso de script de plugin; enxugar o JavaScript de terceiros costuma trazer a métrica para baixo de 200 ms.
Erros comuns que sabotam os Core Web Vitals
O erro que mais reprova é otimizar no escuro, sem medir o campo, e acabar mexendo no que já estava bom enquanto a causa real segue intocada. Em sites WooCommerce com muitos plugins de checkout, o INP costuma reprovar só na página de carrinho, não na home, e medir apenas a home gera um diagnóstico falso-positivo.
A regressão volta a aparecer semanas depois nos dados de campo do CrUX. Outro tropeço frequente é confiar no laboratório: ele simula um ambiente controlado, enquanto o campo reflete o aparelho mediano do seu público. Há ainda quem empilhe dois plugins de cache, criando dupla camada que serve HTML desatualizado. Cada um desses erros tem correção direta quando você mede a página certa, no dado certo, e isola qual dos Core Web Vitals está reprovando antes de tocar em qualquer configuração do site.
Como validar e manter os Core Web Vitals aprovados
Manter os Core Web Vitals aprovados não é tarefa única: eles mudam conforme você adiciona conteúdo, plugins e mídia, então a manutenção é o que evita regredir sem perceber. Acompanhe o relatório de Core Web Vitals no Search Console a cada 28 dias e rode o PageSpeed Insights sempre que instalar algo novo ou trocar o tema.
Ferramentas distintas cobrem ângulos distintos: o PageSpeed Insights mede página por página sob demanda, o Search Console agrega o site inteiro por grupo de URL e o CrUX entrega o dado de campo bruto da janela de 28 dias. A gente vê no suporte da FULL que site aprovado regride quando o dono instala plugins sem checar o impacto nos Core Web Vitals, e a queda só aparece no campo semanas depois, quando a janela de 28 dias do CrUX finalmente fecha sobre o novo número.
Acelere todos os seus sites sem licença avulsa
Para quem gerencia vários sites e quer plugins premium de performance sem pagar licença avulsa de cada um, o bundle da FULL ativa o pacote a partir de R$849 no plano PRO, com custo de R$85 por site. Em vez de comprar WP Rocket e Perfmatters separados por projeto, você ativa tudo de uma vez.
Assim, cada site se mantém dentro das metas de LCP, INP e CLS conforme cresce. Confira as opções em FULL.services/planos. A gente vê no suporte da FULL que a base sólida de hospedagem somada a plugins de otimização aprova a maioria dos sites sem retrabalho.
Legenda: o relatório de campo aprovado comprova que a correção atingiu as metas reais, não só o laboratório.
Perguntas frequentes
Por que meu site passa no laboratório mas reprova no campo?
O laboratório mede uma simulação controlada, enquanto o campo reflete visitantes reais com dispositivos e conexões variados ao longo de 28 dias. Confie sempre no campo, porque é ele que o Google usa para ranquear: o relatório do CrUX e o Search Console mostram esse dado. Se o laboratório vai bem e o campo não, o gargalo costuma estar no aparelho mediano do seu público. A gente vê no suporte da FULL que essa diferença engana muita gente que comemora cedo.
É possível aprovar nos Core Web Vitals sem trocar de hospedagem?
Sim, é possível em boa parte dos casos, desde que o TTFB do servidor já esteja abaixo de 800 ms. Com cache de página ativo, imagem em WebP e JavaScript enxuto, muitos sites aprovam LCP, INP e CLS sem migrar de host. Quando o TTFB passa de 1,2 s mesmo com cache, aí a hospedagem vira o gargalo real. A gente vê no suporte da FULL que servidor lento é o teto que nenhum plugin supera sozinho.
Qual dos Core Web Vitals é o mais difícil de melhorar no WordPress?
O INP costuma ser o mais trabalhoso, porque exige reduzir o JavaScript de plugins e de terceiros, algo que mexe na estrutura do site. LCP e CLS, em geral, têm correção mais direta, ligada a mídia, servidor e dimensionamento de layout. Para atacar o INP, comece desativando scripts que carregam em páginas onde não são usados, com uma ferramenta como Perfmatters. A gente vê no suporte da FULL que resolver primeiro LCP e CLS e deixar o INP por último é o caminho mais rápido.
Quanto tempo demora para o Search Console refletir uma melhoria de Vitals?
O relatório de Core Web Vitals do Search Console usa a janela de campo de 28 dias do CrUX, então uma correção leva semanas para mover o número de forma estável. O PageSpeed Insights mostra o campo mais cedo, mas ainda como média móvel. Não espere ver verde no dia seguinte: ajuste, monitore e dê tempo ao dado acumular. A gente vê no suporte da FULL que muita gente reverte uma boa correção achando que falhou, quando só faltou esperar a janela fechar.
Plugin de cache resolve os Core Web Vitals sozinho?
Não resolve sozinho quando a base é fraca, embora ajude bastante. Um plugin como WP Rocket acelera entrega e reduz trabalho do servidor, mas não conserta hospedagem com TTFB acima de 1 s nem tema que carrega scripts demais. Combine o cache com imagem leve em WebP, dimensionamento de mídia e menos plugins de JavaScript. A gente vê no suporte da FULL que base sólida somada a plugin de otimização aprova a maioria dos sites, enquanto plugin sobre servidor ruim só maquia o número.
Próximos passos para manter o site aprovado
Melhorar os Core Web Vitals no WordPress se resume a medir o campo primeiro e atacar a métrica certa: cache e servidor para o LCP, dimensionamento de mídia para o CLS e JavaScript enxuto para o INP, sempre confirmando o ganho no PageSpeed Insights e no Search Console. O erro que mais atrapalha é otimizar no escuro, mexendo no que já estava bom enquanto a causa real segue intocada. Trate os Vitals como um piso de qualidade a atingir e manter, não como uma corrida infinita por décimos: alcance LCP até 2,5 s, INP até 200 ms e CLS até 0,1, mantenha a manutenção a cada 28 dias e direcione a energia extra para conteúdo e conversão. Para continuar aprendendo, o FULL Academy reúne tutoriais, guias e reviews num só lugar. Meça o campo, ataque a causa certa e mantenha o site dentro das metas.
















