Como melhorar Core Web Vitals no WordPress

Como melhorar Core Web Vitals no WordPress

Um site WordPress lento não é um problema estético — é uma falha técnica com causa rastreável. Cache mal configurado, imagens pesadas, JavaScript bloqueando a renderização, layout que "pula" durante o carregamento. Cada um desses sintomas aparece em uma métrica específica dos Core Web Vitals, e cada métrica tem uma correção diferente. Este guia mostra como identificar qual métrica está ruim, aplicar a correção certa na ordem certa e confirmar a melhoria.

O que são LCP, INP e CLS

Os Core Web Vitals são três métricas que medem a experiência real de carregamento e interação de uma página:

• LCP (Largest Contentful Paint) — mede o tempo até o maior elemento visível (geralmente uma imagem ou bloco de texto) terminar de renderizar. É um indicador de velocidade percebida do carregamento.
• INP (Interaction to Next Paint) — mede a latência entre uma interação do usuário (clique, toque, tecla) e a resposta visual da página. Substituiu o antigo FID e reflete a "fluidez" da página durante o uso.
• CLS (Cumulative Layout Shift) — mede o quanto os elementos da página se deslocam inesperadamente durante o carregamento. Um valor alto significa que o layout "pula", empurrando conteúdo enquanto o usuário está lendo ou tentando clicar.

Os limites de referência divulgados pelo Google para essas métricas são:

| Métrica | Bom | Precisa melhorar | Ruim | |---|---|---|---| | LCP | ≤ 2,5 s | ≤ 4,0 s | > 4,0 s | | INP | ≤ 200 ms | ≤ 500 ms | > 500 ms | | CLS | ≤ 0,1 | ≤ 0,25 | > 0,25 |

Diagnóstico: descobrir qual métrica está ruim

Antes de mexer em qualquer plugin, você precisa saber qual métrica está falhando e em quais páginas. Otimizar sem diagnóstico é chute — e chute costuma quebrar mais do que conserta.

PageSpeed Insights (dados de laboratório + de campo)

1. Abra pagespeed.web.dev e cole a URL da home e de pelo menos uma página interna importante (um post, uma landing, o /contato).
2. Rode a análise em Mobile e depois em Desktop — mobile é o cenário mais crítico para a maioria dos sites.
3. Anote os três valores (LCP, INP, CLS) das duas seções:

• Descubra o que os usuários reais estão vivenciando — dados de campo (CrUX), representam usuários reais nos últimos 28 dias.
• Diagnosticar problemas de desempenho — dados de laboratório (Lighthouse), simulados na hora, úteis para depurar.

1. Marque qual métrica está fora do limite "Bom" e em qual dispositivo.

Search Console — relatório de Core Web Vitals

O Search Console mostra o comportamento agregado das URLs do seu site com base em dados reais de usuários:

1. Acesse Search Console → Experiência → Core Web Vitals.
2. Veja os relatórios separados de Mobile e Desktop.
3. Clique em cada categoria ("Ruim", "Precisa melhorar") para ver os grupos de URLs afetados e a métrica específica que falhou.

Esse relatório é mais confiável para decidir prioridades que uma única medição do PageSpeed, porque agrega usuários reais em vez de uma execução isolada.

Priorização

Depois de coletar os dados, priorize assim:

• LCP ruim → problema de carregamento (imagem hero, hospedagem, cache, CSS crítico).
• INP ruim → problema de JavaScript (scripts de terceiros, plugins pesados, temas mal codados).
• CLS ruim → problema de layout (imagens sem dimensão, fontes web, anúncios, embeds).

Ataque a métrica que tem o maior volume de URLs afetadas primeiro.

Configurar cache de página no WordPress

Cache de página é a otimização com melhor relação esforço/resultado no WordPress. Uma página cacheada é servida como HTML estático, pulando toda a execução do PHP e as consultas ao banco — o que costuma reduzir drasticamente o TTFB (Time to First Byte), componente direto do LCP.

Escolha de plugin de cache

Três opções cobrem a maioria dos cenários:

• WP Rocket — pago, configuração praticamente "ligar e esquecer". Já vem com cache de página, cache de browser, GZIP, otimização de CSS/JS, lazy-load, preload e integração fácil com CDNs. Boa escolha se você quer resolver rápido sem ficar mexendo em opções.
• LiteSpeed Cache — gratuito, obrigatório se sua hospedagem usa servidor LiteSpeed (ele usa o cache no nível do servidor, muito mais rápido que qualquer cache em PHP). Inclui integração com QUIC.cloud para CDN.
• W3 Total Cache — gratuito, altamente configurável, mas exige mais conhecimento técnico. Boa opção quando você precisa de controle fino ou tem uma stack customizada.

Configuração mínima recomendada

Independente do plugin escolhido, ligue estas opções:

1. Page Cache — gera HTML estático para visitantes não logados.
2. Browser Cache — envia cabeçalhos Cache-Control para que assets estáticos (imagens, CSS, JS, fontes) sejam armazenados no navegador do visitante.
3. GZIP ou Brotli — compressão de resposta HTTP. Brotli comprime mais que GZIP; use se seu servidor suportar.
4. Object Cache (opcional, Redis/Memcached) — cacheia consultas do banco. Faz diferença em sites com muitas categorias, WooCommerce ou plugins que fazem muitas queries.

Após ativar o cache, limpe todo o cache existente e teste algumas páginas em modo anônimo. Verifique nos cabeçalhos da resposta (aba Network do DevTools) se aparece algo como x-cache: HIT ou cf-cache-status: HIT.

Configurar CDN

Uma CDN (Content Delivery Network) serve seus assets a partir de servidores geograficamente próximos ao visitante, reduzindo latência de rede — que impacta LCP diretamente.

Cloudflare é a opção mais comum para WordPress porque tem plano gratuito, é fácil de configurar e oferece cache de borda, GZIP/Brotli, HTTP/3 e proteção básica contra ataques. O fluxo básico:

1. Crie uma conta no Cloudflare e adicione seu domínio.
2. Aponte os nameservers do domínio para os do Cloudflare (feito no registrador — Registro.br, GoDaddy etc.).
3. Ative SSL em modo Full (strict) se seu servidor de origem já tem certificado válido.
4. Em Speed → Optimization, ative Auto Minify (HTML/CSS/JS) e Brotli.
5. Em Caching → Configuration, ative Auto Minify se o plugin de cache não estiver fazendo.

Se estiver usando LiteSpeed Cache, a alternativa é o QUIC.cloud, que integra nativamente com o plugin e cacheia páginas inteiras na borda (não só assets).

Otimizar imagens para reduzir LCP

Imagens são, quase sempre, o elemento LCP. Otimizar imagens costuma ser o maior ganho de LCP em sites WordPress.

Converter para WebP ou AVIF

WebP e AVIF geram arquivos menores que JPEG/PNG com qualidade equivalente. Plugins que fazem a conversão automática:

• Imagify, ShortPixel, EWWW Image Optimizer — convertem no upload e podem processar imagens antigas em lote.
• LiteSpeed Cache — inclui otimização de imagem via QUIC.cloud no plano gratuito.

Configure o plugin para servir a versão WebP/AVIF via <picture> ou reescrita no servidor, com fallback para JPEG em navegadores antigos.

Dimensionar corretamente

Nunca sirva uma imagem de 3000px de largura para exibir em um container de 800px. O WordPress já gera múltiplos tamanhos automaticamente ao fazer upload — o problema é o tema ou plugin usar o tamanho errado.

Verifique no DevTools: clique com o botão direito na imagem LCP → Inspecionar → veja o atributo src e compare com a largura real de exibição. Se houver disparidade grande, ajuste o srcset do tema para servir tamanhos apropriados.

Usar srcset

O atributo srcset permite ao navegador escolher a melhor imagem para o dispositivo:

``html <img src="foto-800.webp" srcset="foto-400.webp 400w, foto-800.webp 800w, foto-1200.webp 1200w" sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px" width="800" height="600" alt="descrição" /> ``

O WordPress gera srcset automaticamente desde a versão 4.4. Se seu tema não estiver usando, é bug — não desative essa funcionalidade.

Lazy-loading (exceto na imagem LCP)

Lazy-loading atrasa o carregamento de imagens abaixo do fold, economizando banda. Mas nunca aplique lazy-loading na imagem LCP — isso vai piorar o LCP em vez de melhorar.

• Imagens do WordPress recebem loading="lazy" por padrão desde 5.5.
• No editor de blocos, verifique se a imagem hero da página inicial e das landings não tem lazy-loading.
• Alguns plugins de cache aplicam lazy-loading em tudo automaticamente — exclua manualmente a imagem LCP nas configurações.

Preload da imagem LCP

Um preload informa ao navegador para começar a baixar a imagem hero o mais cedo possível, antes mesmo do parser encontrar a tag <img>:

``html <link rel="preload" as="image" href="/hero.webp" imagesrcset="/hero-800.webp 800w, /hero-1600.webp 1600w" imagesizes="100vw" fetchpriority="high" /> ``

WP Rocket e LiteSpeed Cache têm opções para adicionar isso automaticamente. Alternativa: usar fetchpriority="high" diretamente na tag <img> da imagem hero — funciona em navegadores modernos e dispensa o preload manual.

Otimizar JavaScript e CSS

JavaScript é a principal causa de INP ruim e um dos maiores ofensores de LCP. CSS render-blocking atrasa a renderização inicial e piora LCP.

Adiar JS não crítico

Todo <script> sem defer ou async bloqueia a renderização enquanto é baixado e executado:

• defer — baixa em paralelo, executa depois do HTML parseado, preserva ordem. Use para scripts que dependem do DOM.
• async — baixa em paralelo, executa assim que baixa. Use para scripts independentes (analytics, tag manager).

Plugins de cache oferecem essa otimização com nomes como "Load JavaScript deferred" (WP Rocket) ou "Load JS Deferred" (LiteSpeed). Ligue e teste — alguns scripts críticos (jQuery em temas antigos, por exemplo) podem quebrar se adiados e precisam ser excluídos manualmente.

Remover scripts desnecessários

Muitos sites carregam scripts em todas as páginas quando só precisam em uma:

• Formulário de contato (Contact Form 7, WPForms) carregando em toda página que não tem formulário.
• Scripts do WooCommerce em páginas fora da loja.
• Scripts de embeds (YouTube, Twitter) que só existem em posts específicos.

Perfmatters é um plugin específico para isso: permite desativar scripts e estilos por URL, drasticamente reduzindo o payload de JS por página.

Minificar e combinar

Minificar (remover espaços, comentários) reduz o tamanho dos arquivos. Combinar (juntar múltiplos arquivos em um) pode reduzir a quantidade de requisições — mas em servidores com HTTP/2 e HTTP/3, combinar pode piorar (perde-se paralelização). Teste antes/depois.

CSS: inline do crítico e remoção do não usado

• CSS crítico — o subconjunto de CSS necessário para renderizar o above-the-fold. Inline no <head> acelera LCP. WP Rocket, LiteSpeed Cache e Autoptimize geram automaticamente.
• CSS não usado — arquivos ou regras carregados mas nunca aplicados. LiteSpeed Cache tem "Remove Unused CSS", WP Rocket tem "Optimize CSS delivery". Cuidado: essas otimizações podem quebrar layouts que carregam CSS dinamicamente, então teste páginas variadas.

Autoptimize e Perfmatters combinados

Se você não usa um plugin all-in-one como WP Rocket ou LiteSpeed Cache, a combinação Autoptimize + Perfmatters cobre boa parte das otimizações:

• Autoptimize — minifica e combina CSS/JS, inline do CSS crítico.
• Perfmatters — desativa scripts por URL, controle fino sobre heartbeat, revisões e outros comportamentos do WordPress.

Escolher hospedagem e servidor

Depois de otimizar cache, imagens e código, se o TTFB (tempo até o primeiro byte, visível no PageSpeed em "Server response time") continuar alto — acima de 600 ms —, o gargalo é a hospedagem.

Servidor web

• LiteSpeed — geralmente o mais rápido para WordPress, especialmente combinado com o plugin LiteSpeed Cache (que usa cache no nível do servidor, não em PHP).
• Nginx — rápido, comum em hospedagens gerenciadas.
• Apache — o mais tradicional, funciona bem, mas costuma exigir mais afinamento (mod_pagespeed, cache reverso) para performance equivalente.

Hospedagem gerenciada vs compartilhada

• Hospedagem compartilhada barata — o servidor é compartilhado com dezenas ou centenas de sites. TTFB imprevisível, recursos limitados. Costuma ser insuficiente para LCP bom.
• Hospedagem gerenciada de WordPress — Kinsta, WP Engine, Rocket.net, Hostinger Managed, entre outras. Servidor dedicado ou containers isolados, cache no nível do servidor, CDN incluída. Custa mais, mas resolve o TTFB.
• VPS — controle total, mas exige administração de servidor. Só faz sentido se você tem quem administre.

Critérios de escolha

1. TTFB abaixo de 400 ms medido em várias regiões.
2. HTTP/2 e HTTP/3 habilitados.
3. PHP 8.x ou superior com OPcache.
4. SSL grátis via Let's Encrypt.
5. Backup automático e ambiente de staging.

Corrigir CLS (Cumulative Layout Shift)

CLS costuma ser a métrica mais fácil de corrigir porque tem causas específicas e identificáveis.

Definir dimensões explícitas

Toda imagem, iframe, vídeo e ad deve ter width e height no HTML:

``html <img src="foto.webp" width="800" height="600" alt="..." /> <iframe src="..." width="560" height="315"></iframe> ``

O navegador reserva o espaço antes mesmo do arquivo carregar, evitando o "pulo" do layout. O WordPress adiciona dimensões automaticamente em imagens inseridas pelo editor, mas embeds e iframes manuais frequentemente ficam sem.

Reservar espaço para anúncios e embeds

Se sua página tem AdSense, um bloco de comentários que carrega assíncrono, ou embeds de terceiros, use CSS para reservar o espaço:

``css .ad-slot { min-height: 250px; min-width: 300px; } ``

Assim, quando o conteúdo carregar depois, ele preenche um espaço já reservado em vez de empurrar o resto da página.

Evitar injeção de conteúdo acima do fold

Banners de cookies, avisos de promoção e popups que aparecem depois de segundos empurram tudo para baixo. Se precisar exibir, use overlay/modal em vez de conteúdo no fluxo do documento. Se o banner tem que ficar no topo, renderize-o já no HTML inicial em vez de injetar via JS.

font-display adequado

Fontes web que carregam depois do texto costumam causar o "FOIT" (texto invisível) ou "FOUT" (troca visual da fonte), gerando CLS. Configure:

``css @font-face { font-family: 'Inter'; src: url('/fonts/inter.woff2') format('woff2'); font-display: swap; } ``

swap mostra o texto imediatamente com a fonte fallback e troca quando a web font chega. Combine com preload da fonte principal:

``html <link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin /> ``

Medir resultado e iterar

Otimização é ciclo, não evento único. Depois de cada mudança:

Remedir no PageSpeed Insights

• Rode em modo anônimo para evitar interferência de extensões.
• Rode duas ou três vezes — resultados de laboratório variam por conta de latência de rede.
• Compare o antes/depois na mesma URL, mesmo dispositivo.

Comparar lab vs field data

• Lab data (Lighthouse) — simulado, imediato, útil para depurar. Reflete a mudança que você acabou de fazer.
• Field data (CrUX) — dados reais de usuários agregados nos últimos 28 dias. Só reflete melhorias depois desse período de acumulação.

Se o lab data melhorou mas o field data ainda está ruim, aguarde. O relatório do Search Console e a seção "Descubra o que os usuários reais estão vivenciando" do PageSpeed Insights levam até 28 dias para refletir totalmente as mudanças.

Ciclo de iteração

1. Medir baseline.
2. Aplicar UMA mudança relevante.
3. Remedir imediatamente (lab data).
4. Se piorou, reverter. Se melhorou, seguir.
5. Repetir para próxima otimização.
6. Após aplicar todas as correções, aguardar 28 dias e verificar o field data no Search Console.

Mudar várias coisas ao mesmo tempo torna impossível saber o que funcionou e o que quebrou. Uma otimização por vez, medindo entre elas.

Ordem sugerida das otimizações

Se está começando do zero, siga esta ordem — cada etapa geralmente destrava a próxima:

1. Cache de página (maior ganho isolado, praticamente sem risco).
2. CDN (reduz latência para visitantes distantes).
3. Otimização de imagens (WebP/AVIF, dimensões, srcset, preload da LCP).
4. JS/CSS (defer, remover scripts desnecessários, CSS crítico).
5. CLS (dimensões, reservar espaço, font-display).
6. Hospedagem (só se TTFB continuar alto após 1-4).

Depois de estabilizar, volte ao Search Console mensalmente. Uma atualização de tema, um plugin novo ou uma imagem sem dimensão em um post recente pode reintroduzir o problema — o ciclo de medição é permanente, não pontual.