Core Web Vitals numa ficha de produto: reduzir LCP sem sacrificar as imagens

Desde 2021, a Google usa os Core Web Vitals como sinal de ranking. Em 2026, o seu peso continuou a aumentar, e as fichas de produto são o principal palco disso: imagens de alta resolução, sliders, botões de adicionar ao carrinho, reviews dinâmicas — tudo o que degrada a performance.

Eis como otimizar as 3 métricas que contam (LCP, CLS, INP) numa ficha de produto sem perder qualidade visual nem UX.

Os 3 Core Web Vitals em 2026

LCP (Largest Contentful Paint) — o tempo até o maior elemento visível (tipicamente a imagem principal do produto) aparecer. Objetivo: <2,5 s.

CLS (Cumulative Layout Shift) — a estabilidade visual: os elementos não devem saltar durante o carregamento. Objetivo: <0,1.

INP (Interaction to Next Paint) — desde março de 2024, o INP substitui o FID. Mede o atraso entre um clique do utilizador (adicionar ao carrinho, abrir um menu) e a resposta visual. Objetivo: <200 ms.

Uma ficha de produto que passa os 3 limiares na zona verde tem vantagem de ranking face às que não passam. A diferença pode representar 3-5 posições num keyword competitivo.

LCP na imagem hero: o grande trabalho

Em 90% das fichas de produto, o LCP é a imagem hero (a primeira imagem do produto). O seu peso e o seu tempo de carregamento determinam tudo.

Formato de imagem

• WebP: 25-35% mais leve do que JPEG, suportado em todo o lado em 2026. O padrão.
• AVIF: 40-50% mais leve do que JPEG, melhor qualidade. Suportado por Chrome/Firefox/Safari desde 2022. Dar prioridade quando possível.
• JPEG: fallback apenas para navegadores muito antigos (<1% do tráfego em 2026).

Sirva o formato certo consoante o navegador com <picture>:

<picture>
  <source srcset="/product.avif" type="image/avif" />
  <source srcset="/product.webp" type="image/webp" />
  <img src="/product.jpg" alt="..." />
</picture>

Dimensões e densidade

Uma imagem hero apresentada a 600×600 pixels no ecrã não deve pesar 4000×4000 pixels. Sirva a imagem no tamanho certo + versão 2x para ecrãs retina:

<img
  src="/product-600.webp"
  srcset="/product-600.webp 1x, /product-1200.webp 2x"
  width="600"
  height="600"
  alt="..."
/>

No Shopify, a sintaxe Liquid img_url: '600x600' trata disso automaticamente. No WooCommerce, via WP Fastest Image Optimizer ou Smush.

Lazy-loading inteligente

Não aplique lazy-load à imagem hero (a primeira imagem visível): ela deve carregar imediatamente. Adicione fetchpriority="high":

<img
  src="/product-hero.webp"
  fetchpriority="high"
  loading="eager"
  alt="..."
/>

Aplique lazy-load a tudo o resto (imagens secundárias, reviews com fotos, produtos semelhantes no fim da página):

<img
  src="/product-thumbnail.webp"
  loading="lazy"
  alt="..."
/>

CDN e cache

Todas as imagens de produto devem passar por um CDN (Cloudflare, Fastly, Bunny). Ganho típico em LCP: 30-50% na Europa, 50-70% fora da Europa.

O Shopify inclui o seu próprio CDN (Fastly). O WooCommerce exige uma configuração explícita.

CLS: causas e correções

O CLS numa ficha de produto vem principalmente de:

Imagens sem dimensões

<!-- ❌ Causa CLS -->
<img src="/product.webp" alt="..." />

<!-- ✅ Reserva o espaço -->
<img src="/product.webp" width="600" height="600" alt="..." />

Mesmo numa imagem responsive (CSS que faz override de width/height), especifique os atributos HTML — servem de hint para reservar o espaço antes do carregamento.

Anúncios ou banners que aparecem tarde

Um banner "Envio grátis a partir de 50 €" que aparece 500ms depois do load e empurra todo o conteúdo para baixo = CLS catastrófico.

Solução: reserve o espaço no HTML inicial com min-height, e preencha o conteúdo depois.

Fontes web que mudam o tamanho do texto

Se carregar uma fonte custom, ela chega com atraso. Durante esse tempo, o texto aparece numa fonte fallback com métricas diferentes. Quando a fonte final chega, tudo mexe.

Solução: font-display: optional ou font-display: swap com size-adjust correspondente:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100%; /* Match fallback metrics */
}

Carrossel / slider de imagens de produto

Os sliders são uma causa frequente de CLS se estiverem mal implementados. Regras:

• Fixar a altura do contentor do slider (height: 600px, por exemplo)
• Não usar paginação JS que mude a altura ao clicar
• As thumbnails têm as suas dimensões especificadas

INP: adicionar ao carrinho e outras interações críticas

O INP mede o pior atraso de resposta às interações do utilizador. Numa ficha de produto, as interações-chave são:

• Clique em "Adicionar ao carrinho"
• Mudança de variante (tamanho, cor)
• Abertura de um menu burger
• Scroll num carrossel

Causas típicas de INP elevado:

JavaScript bloqueante

As bibliotecas third-party (Facebook Pixel, Google Tag Manager, Hotjar, widgets de reviews) são as primeiras culpadas. Cada script que corre no main thread bloqueia as interações.

Soluções:

• Carregar scripts third-party com defer ou async quando possível
• Deslocar para um Web Worker se for crítico
• Consolidar os pixels analytics num único tag (GTM)
• Atrasos voluntários: não carregar Hotjar antes de 3 segundos após o First Contentful Paint

Handlers JavaScript pesados no clique

Um clique em "Adicionar ao carrinho" que dispara 5 chamadas API, anima 3 elementos e abre uma modal pode demorar 500ms a responder.

Otimizações:

• Optimistic UI: mostre imediatamente o feedback (o botão muda de estado), mesmo que a API demore 300ms a responder
• Debounce nos handlers: evite relançar cálculos em cada hover
• Mova as animações para CSS em vez de JS quando possível

Hydration em SPA / frameworks

Se usa React/Next/Vue, a hydration inicial pode bloquear o main thread durante 1-2 segundos. Durante esse tempo, os cliques não funcionam.

Soluções:

• Server-side rendering com conteúdo interativo limitado no início
• Progressive hydration: hidratar primeiro as partes críticas
• Em Next.js 16+, use "use client" com parcimónia — quanto mais server for o componente, melhor o INP

Ferramentas de medição

Lab tools (dados simulados, úteis em desenvolvimento):

• PageSpeed Insights — rápido, público
• Lighthouse (integrado no Chrome DevTools) — detalhado
• WebPageTest — mais configuração, testes em vários dispositivos

Field data (dados reais de utilizadores, críticos para a Google):

• Chrome User Experience Report (CrUX) — dados agregados públicos
• Google Search Console → Core Web Vitals — o seu site em específico
• PostHog, Vercel Analytics, Cloudflare Web Analytics — monitorização contínua

Regra importante: só o field data conta para o ranking. Uma pontuação perfeita em lab com más pontuações em field = nenhum efeito positivo em SEO.

Por plataforma

Shopify

O Shopify fornece Core Web Vitals decentes por defeito. Os temas oficiais (Dawn, Studio, Crave) estão otimizados. Os maus Core Web Vitals no Shopify vêm quase sempre de:

• Apps third-party que injetam JS pesado
• Temas premium de terceiros mal otimizados
• Imagens não comprimidas

Auditoria no Shopify: remova apps inúteis (Online Store → Apps), use um tema oficial recente, comprima as imagens.

WooCommerce

Mais variabilidade consoante o alojamento e os plugins. Stack recomendada:

• Alojamento performante: Kinsta, WP Engine, Hostinger Cloud (não um partilhado low-cost)
• Tema leve: Storefront oficial ou um tema personalizado otimizado (não Divi nem Avada)
• Apenas plugins essenciais
• Plugin de cache: WP Rocket, Cache Enabler
• Plugin de otimização de imagens: ShortPixel, Imagify

Headless

Em Next.js com next/image, otimização automática. Num frontend custom: implemente manualmente (formatos, lazy, fetchpriority).

FAQ

Quanto tempo demora até a Google ter em conta as melhorias de Core Web Vitals?

28 dias de "field data" são agregados para o CrUX. Depois de um deployment de otimizações, conte com 4-6 semanas até a pontuação da Google refletir a realidade. Tenha paciência, não reverta ao fim de 1 semana.

Os Core Web Vitals são mais importantes do que o conteúdo para o ranking?

Não. O conteúdo (relevância, qualidade, backlinks) continua a ser o fator dominante. Os Core Web Vitals são um tie-breaker: entre duas páginas equivalentes em conteúdo, a que tiver melhores CWV fica melhor posicionada. Degradar o conteúdo para ganhar em CWV é contraproducente.

Posso ficar na zona verde sem CDN?

Para um site FR com audiência apenas em FR, sim — se o seu servidor estiver em França e bem configurado. Para internacional, o CDN é quase obrigatório. O Cloudflare gratuito chega em 80% dos casos.

Tenho de sacrificar a qualidade da imagem para ganhar em LCP?

Não. A configuração certa (WebP/AVIF + dimensões + CDN + fetchpriority) permite ter uma imagem 600×600 com 40 KB e qualidade equivalente a um JPEG de 200 KB. O sacrifício deixou de ser necessário desde 2023.

Os Core Web Vitals são os mesmos em mobile e desktop?

Os limiares sim, mas as pontuações são medidas separadamente pela Google. Uma página pode estar "Good" em desktop e "Poor" em mobile (é frequente). A Google usa principalmente as métricas mobile para o ranking (Mobile-First Indexing).

Quanto dinheiro investir na otimização de CWV?

Enquadramento: se as suas páginas já estão em "Good", não vale a pena investir mais. Se estiver em "Needs improvement", 1-3 semanas de desenvolvimento nos principais fixes (imagens, scripts third-party, CDN) costumam bastar. Se estiver em "Poor" em todo o site, pode ser necessária uma reformulação técnica — comece por uma auditoria completa.

---

Ecomptimize otimiza automaticamente os Core Web Vitals nas fichas de produto do seu catálogo. Veja Ecomptimize para Shopify ou Ecomptimize para WooCommerce.

---