Core Web Vitals no WordPress: como melhorar LCP, INP e CLS

Core Web Vitals no WordPress: por que importam

Core Web Vitals são as três métricas do Google que medem a experiência real de carregamento (LCP), de resposta a interações (INP) e de estabilidade visual (CLS) de uma página. Se você quer a explicação completa de cada métrica, veja o verbete de Core Web Vitals no glossário. Aqui o foco é prático: como medir e corrigir em um site WordPress.

O Google Search Central recomenda ter boas Core Web Vitals “para ter sucesso na Busca” e diz que elas, junto com outros aspectos de experiência de página, se alinham ao que os sistemas centrais de ranqueamento procuram recompensar. A documentação não promete que bons números levam ao topo: trate performance como parte da base técnica, não como atalho. Se quiser ver onde ela entra no quadro geral, o checklist de SEO técnico organiza todos os blocos de uma auditoria.

Limites oficiais: bom, precisa melhorar e ruim

Os limites abaixo são os publicados pelo web.dev e repetidos no relatório de Core Web Vitals do Search Console. Desde março de 2024, o INP substituiu o antigo FID como métrica oficial de responsividade.

Dois detalhes importam:

• Percentil 75. Uma métrica é considerada boa quando pelo menos 75% das visitas atingem o limite de “bom”. Não é a média.
• Mesmo limite para celular e desktop. O web.dev explica que os limites não são separados por dispositivo, mas o Search Console mostra relatórios separados de celular e desktop. Uma página pode ser boa no desktop e ruim no celular.

Dados de campo x dados de laboratório

O erro mais comum é otimizar a nota do Lighthouse e ignorar o que o Google mede. As duas fontes têm papéis diferentes:

O documento oficial do PageSpeed Insights resume assim: dados de laboratório são úteis para depurar, e dados de campo capturam a experiência real. Quando uma URL não tem visitas suficientes no CrUX, o PageSpeed Insights mostra dados da origem (o site todo). Se nem a origem tiver dados, não aparece nada de campo. Também ficam fora do CrUX páginas que não são públicas, que não retornam status 200 ou que usam noindex.

Como diagnosticar o seu site, passo a passo

Antes de instalar plugins, descubra qual métrica falha, onde e por quê.

1. Abra o relatório de Core Web Vitals no Search Console
   Ele agrupa URLs com experiência parecida e mostra o status de cada grupo, separado por celular e desktop. O status do grupo é sempre o pior entre as métricas: LCP “precisa melhorar” com CLS “ruim” resulta em “ruim”. Se ainda não usa a ferramenta, comece pelo guia do Google Search Console.
2. Mapeie os modelos de página
   No WordPress, os problemas se repetem por template: página inicial, posts, páginas do construtor, categorias, produtos. Escolha uma URL de cada grupo com problema.
3. Rode cada URL no PageSpeed Insights
   Veja primeiro os dados de campo; depois use o Lighthouse para achar o elemento de LCP, as mudanças de layout e as tarefas longas.
4. Identifique o elemento de LCP
   Na maioria dos sites WordPress é a imagem destacada, o banner do topo ou o slider da página inicial. Anote se ele está no HTML inicial ou se é carregado por CSS ou JavaScript.
5. Liste o que roda em cada página
   Plugins que carregam CSS e JS no front-end, chat, pop-ups, pixels, gerenciador de tags e fontes externas. Esse inventário costuma explicar o INP e parte do LCP.
6. Teste em homologação
   Reproduza o problema no laboratório, aplique uma correção por vez e meça de novo.

Como melhorar o LCP no WordPress

O web.dev divide o LCP em quatro partes e sugere uma proporção aproximada para cada uma. Saber qual parte está grande diz onde mexer:

Servidor e cache

Se o TTFB é alto, nenhuma otimização de imagem resolve. Ative cache de página (por plugin ou pela própria hospedagem), use uma CDN para arquivos estáticos e defina uma política de cache eficiente. O web.dev lembra que parâmetros únicos na URL podem causar falhas de cache, e que redirecionamentos extras somam tempo antes do primeiro byte. Um servidor lento também atrapalha o Googlebot, como explica o verbete de crawl budget.

A imagem principal

A regra mais citada pelo web.dev é direta: nunca use lazy loading na imagem de LCP. O WordPress 6.3 passou a adicionar fetchpriority="high" à imagem que considera a provável candidata a LCP (apenas imagens acima de 50.000 pixels de área, por padrão) e refinou a regra que tira o loading="lazy" das primeiras imagens da página. Segundo o anúncio oficial, essa prioridade costuma melhorar o LCP entre 5% e 10%.

Temas, construtores e plugins às vezes desfazem isso: aplicam lazy loading em tudo, usam fundo em CSS ou montam o banner via JavaScript. Confira se a imagem do topo sai assim:

Se a imagem depende de CSS ou JS para ser descoberta, o web.dev recomenda fazer preload com prioridade alta. E use fetchpriority="high" em uma ou duas imagens, no máximo: em mais que isso, a dica perde efeito.

Formato e tamanho

Converta imagens para WebP ou AVIF, comprima e sirva o tamanho adequado à tela. O WordPress aceita AVIF desde a versão 6.5, desde que a biblioteca de imagens do servidor (Imagick ou GD) tenha suporte; dá para conferir em Ferramentas, Saúde do site, aba Informação, seção Manipulação de mídia.

CSS e JavaScript bloqueantes

Segundo o web.dev, quase nunca é necessário colocar scripts síncronos no <head>. Use defer nos scripts que não são críticos, reduza o CSS carregado em páginas que não precisam dele e inline apenas o CSS crítico do topo.

Como melhorar o INP no WordPress

O web.dev divide esse tempo em três fases: atraso de entrada (a página está ocupada e não começa a tratar o clique), tempo de processamento (o código do evento demora para rodar) e atraso de apresentação (o navegador demora para desenhar o resultado). O web.dev recomenda começar pelos dados de campo e depois reproduzir a interação lenta no laboratório.

No WordPress, as causas mais frequentes são:

• Scripts de terceiros em excesso. Chat, pop-up, mapa de calor e dezenas de tags disputam a mesma thread principal. Remova o que não é usado e carregue o resto só onde precisa. Meça o efeito dos cortes nas conversões com o GA4 para SEO.
• Tarefas longas. Menus, filtros de produto e formulários que executam muito código de uma vez travam a página. A recomendação oficial é quebrar o trabalho em tarefas menores e ceder a vez ao navegador (yield), deixando no evento só o necessário para a próxima atualização visual.
• DOM grande. Construtores de página tendem a gerar muitas camadas de <div> aninhadas. Segundo o web.dev, quanto maior o DOM, mais caro fica renderizar a cada interação. Simplificar seções e remover blocos ocultos ajuda.

Como melhorar o CLS no WordPress

O CLS cresce quando algo aparece e empurra o conteúdo que a pessoa já estava lendo. As correções do web.dev se traduzem assim no WordPress:

• Imagens e vídeos sem dimensão. Sempre inclua width e height (ou aspect-ratio no CSS). O editor faz isso nas imagens da biblioteca, mas HTML manual, construtores e widgets podem omitir.
• Anúncios, embeds e iframes. Reserve o espaço com min-height ou aspect-ratio e mantenha a reserva mesmo quando nenhum anúncio for exibido, para o espaço não “fechar” depois.
• Conteúdo injetado no topo. Barras de cookies e banners que empurram a página são clássicos. Prefira sobrepor (overlay) ou reservar espaço.
• Fontes web. A troca da fonte de sistema pela fonte personalizada pode mudar o tamanho do texto. Hospede as fontes localmente quando possível, faça preload das fontes críticas e ajuste o fallback com size-adjust.
• Animações. Anime com transform, e não com top ou left, que provocam mudança de layout.

O font-display: optional, citado pelo web.dev, evita a troca de fonte depois da primeira pintura (em conexões lentas, a fonte personalizada pode não aparecer na primeira visita).

Plugins de performance, tema e hospedagem

Cada categoria de plugin atua em uma parte do problema:

A equipe de performance do WordPress mantém o plugin Performance Lab, com recursos em teste como formatos modernos de imagem e carregamento especulativo. Parte disso já chegou ao núcleo: o WordPress 6.8 faz prefetch de links por padrão (para visitantes não logados e com links permanentes amigáveis).

Tema e construtor. Um tema leve, que carrega só o CSS e o JS dos blocos usados, parte de uma base melhor que temas “multiuso”. Se não dá para trocar, desative módulos sem uso e elimine sliders na primeira dobra. Lembre que o Google usa a versão mobile para indexar, então a experiência no celular é a que importa; veja o guia de mobile-first indexing.

Hospedagem. PHP atualizado, cache no servidor e recursos adequados afetam o TTFB de todas as páginas. Se o TTFB segue alto com cache ativo, o gargalo está no servidor.

Como validar a correção e acompanhar

Como os dados de campo cobrem 28 dias, a melhora não aparece no dia seguinte. O fluxo oficial do Search Console é:

• Corrija todas as URLs do grupo afetado, não só a de exemplo (em geral, a correção é no template).
• Clique em “Iniciar acompanhamento” (Start tracking) no problema. Isso abre uma sessão de monitoramento de 28 dias.
• Aguarde o resultado. O problema é considerado corrigido se não aparecerem novas ocorrências nesse período. Se a validação falhar, corrija o que restou e inicie uma nova validação.
• Priorize os grupos “ruins” antes dos que “precisam melhorar”, como recomenda a ajuda oficial.

Perguntas Frequentes

Quais são os valores ideais de LCP, INP e CLS?

Para ser considerado bom, o LCP deve ficar em até 2,5 segundos, o INP em até 200 milissegundos e o CLS em até 0,1. Os valores valem para o percentil 75 das visitas reais, tanto no celular quanto no desktop.

Por que o PageSpeed Insights dá nota alta, mas o Search Console mostra problema?

Porque a nota vem de um teste de laboratório isolado, e o Search Console usa dados de campo de visitantes reais nos últimos 28 dias. O INP, por exemplo, só existe em campo. Em caso de conflito, priorize os dados de campo.

Um plugin de cache resolve as Core Web Vitals no WordPress?

Ajuda principalmente o LCP, ao reduzir o tempo de resposta do servidor. Não resolve imagens pesadas, lazy loading na imagem do topo, scripts de terceiros que prejudicam o INP nem mudanças de layout causadas por anúncios e fontes.

Quanto tempo leva para o Search Console mostrar a melhora?

Os dados de campo usam uma janela de 28 dias, e a validação de uma correção no relatório também dura 28 dias.