# Core Web Vitals no WordPress: 4 passos para LCP, INP, CLS

Para <strong>Core Web Vitals WordPress como melhorar</strong>, meça LCP, INP e CLS de campo e ataque hospedagem, cache e mídia. Segundo o <a href="https://web.dev/articles/vitals">web.dev (2024)</a>, 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 <a href="https://full.services/performance-wordpress/">performance no WordPress</a> da FULL e se aprofunda no <a href="https://full.services/guias/acelere-o-wordpress/">guia de aceleração do WordPress</a>. 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 <a href="https://full.services/glossario/core-web-vitals/">Core Web Vitals</a> 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.

<table id="metas-core-web-vitals">
<caption>Core Web Vitals no WordPress: metas e onde validar</caption>
<thead>
<tr><th scope="col">Métrica</th><th scope="col">O que mede</th><th scope="col">Meta (campo)</th><th scope="col">Onde validar</th></tr>
</thead>
<tbody>
<tr><th scope="row">LCP</th><td>Tempo até o maior elemento aparecer</td><td>Até 2,5 segundos</td><td>PageSpeed Insights</td></tr>
<tr><th scope="row">INP</th><td>Atraso da resposta à interação</td><td>Até 200 ms</td><td>CrUX e campo do PSI</td></tr>
<tr><th scope="row">CLS</th><td>Deslocamento visual no carregamento</td><td>Até 0,1</td><td>Lighthouse e campo</td></tr>
<tr><th scope="row">TTFB</th><td>Resposta inicial do servidor</td><td>Até 800 ms</td><td><a href="https://full.services/ttfb-wordpress-como-reduzir/">guia de TTFB</a></td></tr>
</tbody>
</table>

## 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 <a href="https://pagespeed.web.dev/">PageSpeed Insights</a>, que mostra laboratório e campo na mesma tela.
- Os dados de campo do <a href="https://full.services/glossario/core-web-vitals/">CrUX</a>, 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: <a href="https://full.services/glossario/lcp/">LCP</a>, <a href="https://full.services/glossario/cls/">CLS</a> e <a href="https://full.services/glossario/inp-interaction-to-next-paint/">INP</a>.
- Hospedagem com <a href="https://full.services/glossario/ttfb/">TTFB</a> 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 <a href="https://pagespeed.web.dev/">PageSpeed Insights</a> 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 <a href="https://full.services/wordpress-lento-afeta-seo/">Search Console</a>, 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 <a href="https://full.services/cache-wordpress-plugin/">plugin de cache</a> como o WP Rocket, sirva a imagem principal em <a href="https://full.services/glossario/webp/">WebP</a> 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 <a href="https://full.services/como-acelerar-wordpress/">cache de página</a> 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 <a href="https://full.services/planos">FULL.services/planos</a>. 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.

<p class="wp-caption-text">Legenda: o relatório de campo aprovado comprova que a correção atingiu as metas reais, não só o laboratório.</p>

<h2 id="faq">Perguntas frequentes</h2>

<details>
<summary>Por que meu site passa no laboratório mas reprova no campo?</summary>
<p>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.</p>
</details>

<details>
<summary>É possível aprovar nos Core Web Vitals sem trocar de hospedagem?</summary>
<p>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.</p>
</details>

<details>
<summary>Qual dos Core Web Vitals é o mais difícil de melhorar no WordPress?</summary>
<p>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.</p>
</details>

<details>
<summary>Quanto tempo demora para o Search Console refletir uma melhoria de Vitals?</summary>
<p>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.</p>
</details>

<details>
<summary>Plugin de cache resolve os Core Web Vitals sozinho?</summary>
<p>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.</p>
</details>

## 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 <a href="https://full.services/academy/">FULL Academy</a> reúne tutoriais, guias e reviews num só lugar. Meça o campo, ataque a causa certa e mantenha o site dentro das metas.
