Core Web Vitals no WooCommerce: guia prático completo de otimização

Por que WooCommerce tem dificuldade com Core Web Vitals

WooCommerce roda sobre WordPress, que roda sobre PHP, que por padrão não tem nenhum mecanismo de cache de página inteira. Cada requisição gera uma nova execução PHP, consultas ao banco de dados, e resposta dinâmica. Sem otimização, uma loja WooCommerce entrega HTML em 800ms a 2s de TTFB — tempo suficiente para condenar o LCP.

Além disso, o ecossistema de plugins do WordPress incentiva a instalação de extensões que cada uma adiciona seu próprio JavaScript, CSS, e às vezes requisições AJAX adicionais. O resultado é uma loja carregando 3MB a 6MB de recursos em cada pageview.

Otimizando LCP no WooCommerce

O LCP em WooCommerce tem dois problemas distintos que precisam ser resolvidos em ordem: primeiro o servidor (TTFB), depois os recursos (imagem/font).

Passo 1 — Cache de página inteira

Sem cache de página, cada visitante espera o PHP gerar o HTML do zero. Com cache, o primeiro visitante espera, e todos os outros recebem o HTML já pronto em milissegundos do disco ou memória. Isso sozinho pode reduzir o LCP de 4s para 1.8s.

Opções por ordem de eficácia:

• Cache no servidor (Nginx/Redis) — mais rápido, requer acesso ao servidor. Use FastCGI Cache no Nginx ou Redis Object Cache + Full Page Cache configurado via nginx.conf
• WP Rocket — plugin pago (~$59/ano), melhor opção para quem não tem acesso ao servidor. Inclui cache de página, minificação, lazy load e preload
• LiteSpeed Cache — gratuito, excelente se a hospedagem usa LiteSpeed. Rivaliza com WP Rocket em hospedagens compatíveis
• W3 Total Cache + CDN — gratuito, mas configuração complexa. Erros de config podem piorar performance

Passo 2 — Hospedagem adequada para WooCommerce

Hospedagem compartilhada genérica é incompatível com lojas WooCommerce acima de 200 pedidos/mês. O TTFB em shared hosting costuma ficar entre 1.2s e 3s — inatingível para LCP ≤2.5s mesmo com cache.

Passo 3 — Imagem LCP otimizada

Identifique o elemento LCP no Chrome DevTools (aba Performance → marcador LCP → clique para ver o elemento). Geralmente é a imagem de destaque do produto ou o banner hero. Para essa imagem específica:

<!-- Imagem LCP: use fetchpriority e preload -->
<link rel="preload" as="image" href="banner-hero.webp"
  imagesrcset="banner-hero-400.webp 400w, banner-hero-800.webp 800w, banner-hero.webp 1200w"
  imagesizes="100vw"/>

<img src="banner-hero.webp"
  srcset="banner-hero-400.webp 400w, banner-hero-800.webp 800w, banner-hero.webp 1200w"
  sizes="100vw"
  fetchpriority="high"
  loading="eager"
  width="1200" height="600"
  alt="Banner principal da loja"/>

Atenção: a imagem LCP NUNCA deve ter loading="lazy". Lazy load atrasa o carregamento e é a causa mais comum de LCP alto em lojas WooCommerce com temas que aplicam lazy load globalmente.

Melhorando INP no WooCommerce

INP (Interaction to Next Paint) mede a responsividade do navegador a todas as interações do usuário — cliques, teclado, toque. No WooCommerce, as principais fontes de INP alto são scripts de terceiros bloqueando a main thread.

Identificando scripts pesados

Abra o Chrome DevTools → aba Performance → grave 5 segundos interagindo com a página. Procure "Long Tasks" (barras vermelhas acima de 50ms) na thread principal. Cada Long Task é um candidato a causa do INP alto.

Scripts mais frequentemente responsáveis por INP alto em WooCommerce:

• Plugins de chat (Tidio, Zendesk, Crisp) — carregam 200-400KB de JS na thread principal
• Pixel do Facebook/Meta — especialmente sem carregamento diferido
• Plugins de slider (Revolution Slider, Slick) — re-calculam layout em cada resize
• Google Tag Manager com tags mal configuradas — cada tag adiciona latência

Diferindo scripts de terceiros

// wp-content/themes/seu-tema/functions.php
// Adicionar defer/async em scripts não-críticos
add_filter('script_loader_tag', function($tag, $handle, $src) {
    $defer_scripts = [
        'tidio-chat',
        'facebook-pixel',
        'google-tag-manager',
    ];
    if (in_array($handle, $defer_scripts)) {
        return str_replace(' src=', ' defer src=', $tag);
    }
    return $tag;
}, 10, 3);

Eliminando CLS no WooCommerce

CLS (Cumulative Layout Shift) penaliza movimentos inesperados de elementos na página. No WooCommerce, há quatro causas clássicas:

1. Banner de cookies sem altura reservada

/* Reservar espaço para o banner antes de ele carregar */
.cookie-banner-placeholder {
  min-height: 72px; /* altura estimada do banner */
}
/* Ou usar position: fixed para o banner não empurrar conteúdo */
.cookie-banner {
  position: fixed;
  bottom: 0;
  left: 0;
  right: 0;
  z-index: 9999;
}

2. Imagens de produto sem aspect-ratio

/* Sempre defina width e height nos elementos img,
   ou use aspect-ratio no CSS para reservar o espaço */
.woocommerce-product-gallery__image img {
  aspect-ratio: 1 / 1; /* quadrado padrão de produto */
  width: 100%;
  height: auto;
}

.woocommerce ul.products li.product a img {
  aspect-ratio: 1 / 1;
  width: 100%;
  height: auto;
  object-fit: cover;
}

3. Web fonts causando FOUT/FOIT

Fonts carregando tarde causam layout shift porque o fallback tem métricas diferentes (largura, altura de linha) da fonte final. Solução: preconectar ao Google Fonts + usar font-display: swap com override de métricas.

/* Preload da fonte principal */
<link rel="preload" href="/wp-content/themes/tema/fonts/principal.woff2"
  as="font" type="font/woff2" crossorigin/>

/* CSS — override de métricas para reduzir CLS */
@font-face {
  font-family: 'MinhaFonte';
  src: url('/fonts/minhafonte.woff2') format('woff2');
  font-display: swap;
  size-adjust: 102%; /* ajustar até minimizar shift */
  ascent-override: 90%;
}

4. Ads e iframes sem tamanho definido

Qualquer iframe ou widget de ad sem width e height explícitos causará CLS quando carregar. Se o tamanho não é previsível, use um placeholder com a altura mínima esperada.

Stack de plugins para performance

Monitoramento contínuo

Performance não é uma tarefa única — cada plugin instalado, cada imagem adicionada, cada promoção com script de countdown pode degradar as métricas. Configure monitoramento que avise antes do Google penalizar.

• Google Search Console → Core Web Vitals → ativar alertas por email para mudanças de status
• PageSpeed Insights API — integre ao seu CI/CD para medir performance a cada deploy
• Uptime Robot (gratuito) — monitore TTFB e disponibilidade da loja 24/7
• SpeedCurve (pago) — monitoramento de LCP/INP/CLS em campo com alertas configuráveis