Como Imagens Otimizadas Melhoram o Core Web Vitals

O Google não mede apenas se seu conteúdo é relevante — mede se seu site é agradável de usar. Desde 2021, as métricas Core Web Vitals fazem parte do algoritmo de rankeamento, e imagens mal otimizadas são a causa mais frequente de pontuações ruins nessas métricas.

Neste artigo, você vai entender o que são os Core Web Vitals, como cada uma das métricas é afetada por imagens, e um checklist prático de como otimizar imagens para melhorar sua pontuação — incluindo como o MKT com Marcos — Compressor de Imagens resolve a parte mais impactante do problema.

O que são os Core Web Vitals

Core Web Vitals (CWV) são um conjunto de métricas definidas pelo Google para medir a experiência do usuário em páginas web. Elas foram introduzidas em 2020 e tornaram-se fator de rankeamento em maio de 2021. Em 2024, a métrica INP substituiu o FID como a medida de interatividade.

As três métricas atuais são:

1. LCP — Largest Contentful Paint

O que mede: Quanto tempo leva para o maior elemento de conteúdo da página (imagem, vídeo, ou bloco de texto) ficar visível na viewport do usuário.

Por que importa: LCP representa quando o usuário percebe que a página "carregou" — quando o conteúdo principal está disponível para consumo.

Referências:

• Bom: < 2,5 segundos
• Precisa melhorar: 2,5 a 4,0 segundos
• Ruim: > 4,0 segundos

Relação com imagens: Na maioria dos sites, o elemento de LCP é uma imagem — o banner principal, a foto de destaque do artigo, ou a imagem principal do produto. Uma imagem pesada aqui = LCP ruim.

2. CLS — Cumulative Layout Shift

O que mede: A estabilidade visual da página — quantas vezes e com que intensidade o layout "pula" enquanto a página carrega.

Por que importa: Layout shifts são frustrantes: você vai clicar em um botão e, no momento do clique, uma imagem carrega e empurra tudo para baixo — você clica em outra coisa.

Referências:

• Bom: < 0,1
• Precisa melhorar: 0,1 a 0,25
• Ruim: > 0,25

Relação com imagens: Imagens sem dimensões definidas no HTML são a causa principal de CLS. O navegador não sabe o espaço que a imagem vai ocupar antes de baixá-la, então o layout é recalculado quando ela chega.

3. INP — Interaction to Next Paint

O que mede: O tempo desde que o usuário faz uma interação (clique, toque, digitação) até o próximo frame visual que reflete essa interação.

Referências:

• Bom: < 200 milissegundos
• Precisa melhorar: 200 a 500ms
• Ruim: > 500ms

Relação com imagens: Imagens grandes sendo decodificadas na thread principal podem bloquear a resposta a interações do usuário. Decode de imagens grandes aumenta o INP. Além disso, layouts complexos com muitas imagens aumentam o custo de recalcular o layout após interações.

Como cada métrica é afetada por imagens

Imagens e LCP: o impacto mais direto

O LCP é onde as imagens têm o maior impacto. Considere a sequência de eventos para o LCP:

1. O browser analisa o HTML e identifica o elemento de LCP candidato (geralmente uma imagem)
2. O browser faz a requisição para baixar essa imagem
3. Os bytes da imagem são transferidos da rede
4. A imagem é decodificada pelo CPU
5. O frame com a imagem decodificada é pintado na tela
6. LCP é registrado neste momento

Cada passo pode ser otimizado:

Passo 2 (requisição): Use rel="preload" para imagens de LCP críticas, instruindo o browser a priorizar o download da imagem logo no início do parsing do HTML.

Passo 3 (download): Aqui é onde o tamanho do arquivo importa. Uma imagem de 50 KB baixa 10x mais rápido que uma de 500 KB. O MKT com Marcos — Compressor de Imagens resolve este passo reduzindo o tamanho em 40-80%.

Passo 4 (decode): Imagens menores decodificam mais rápido. Use o formato mais eficiente disponível (WebP ou AVIF em vez de JPG quando possível).

Passo 5 (paint): Imagens nas dimensões corretas (não maiores que o necessário) são pintadas mais eficientemente.

Imagens e CLS: a solução simples que muitos ignoram

O CLS causado por imagens tem uma solução direta: sempre defina width e height nas tags <img>.

<!-- Ruim: causa CLS -->
<img src="foto-produto.webp" alt="Tênis esportivo azul">

<!-- Bom: sem CLS -->
<img src="foto-produto.webp" alt="Tênis esportivo azul" width="800" height="600">

Com as dimensões definidas, o browser reserva o espaço correto antes de baixar a imagem. Não há layout shift.

Mas existe um segundo fator menos conhecido: imagens muito grandes que causam o browser a recalcular o layout demoram mais, aumentando a janela de tempo durante a qual outros shifts podem ocorrer.

Imagens e INP: o impacto no thread principal

O decode de imagens grandes compete com a responsividade da UI pelo thread principal do JavaScript. Uma página com 20 imagens de 500 KB cada que precisam ser decodificadas ao mesmo tempo pode fazer a interface travar por segundos — cada interação do usuário será processada com atraso.

Soluções:

• Imagens menores (menos CPU para decode)
• loading="lazy" para adiar decode de imagens fora da viewport
• Imagens dimensionadas corretamente (não 4K exibidas em 400px)

Checklist completo de otimização de imagens para Core Web Vitals

Checklist de formato e compressão

• Usar WebP ou AVIF em vez de JPG para fotos em sites modernos
• Qualidade 75-85 para imagens fotográficas (não 95-100 desnecessariamente)
• Remover metadados EXIF de imagens publicadas na web
• PNG apenas onde necessário (transparência, screenshots de texto)
• Sem BMP ou TIFF em páginas web

O MKT com Marcos — Compressor de Imagens resolve todos os itens acima em processamento em lote, sem limite de arquivos.

Checklist de dimensões

• Redimensionar para o tamanho de exibição — não servir 4K quando exibe em 800px
• Usar srcset para servir tamanhos diferentes em diferentes telas:

  <img srcset="foto-400.webp 400w, foto-800.webp 800w, foto-1600.webp 1600w"
       sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1600px"
       src="foto-800.webp" alt="...">
  

• Sempre definir width e height no HTML para evitar CLS
• Proporcional ao layout — não imagens mais largas que o container

Checklist de carregamento

• loading="lazy" em imagens abaixo do fold:

  <img src="imagem.webp" loading="lazy" alt="...">
  

• rel="preload" para a imagem de LCP (a maior na primeira viewport):

  <link rel="preload" as="image" href="hero.webp">
  

• fetchpriority="high" na imagem de LCP:

  <img src="hero.webp" fetchpriority="high" alt="...">
  

• decoding="async" em imagens secundárias para não bloquear o thread principal

Checklist de tag <picture> para máxima compatibilidade

<picture>
  <source srcset="imagem.avif" type="image/avif">
  <source srcset="imagem.webp" type="image/webp">
  <img src="imagem.jpg" alt="Descrição" width="800" height="600" loading="lazy">
</picture>

Este código serve AVIF para quem suporta, WebP como fallback, e JPG para navegadores antigos — automaticamente.

Como diagnosticar problemas de imagem com PageSpeed Insights

1. Acesse pagespeed.web.dev
2. Digite a URL da sua página
3. Aguarde a análise (30-60 segundos)
4. Na aba Diagnostics, procure por:
   • "Serve images in next-gen formats" — aviso sobre JPG/PNG
   • "Properly size images" — imagens maiores que o necessário
   • "Efficiently encode images" — imagens não otimizadas
   • "Avoid serving legacy JavaScript to modern browsers" (não relacionado a imagens, mas frequente)

O relatório mostra:

• Quais imagens são problemáticas (com URLs)
• Economia potencial em KB
• Impacto estimado no LCP

Como o MKT com Marcos resolve os principais problemas

O MKT com Marcos — Compressor de Imagens resolve diretamente estes avisos do PageSpeed:

"Serve images in next-gen formats": converta JPG/PNG para WebP ou AVIF em lote. O aviso desaparece para todos os arquivos convertidos.

"Efficiently encode images": a compressão com mozjpeg (para JPG) e encoders otimizados (para WebP/AVIF) reduz o tamanho sem perda visual perceptível.

"Properly size images": use o recurso de redimensionamento do programa para gerar imagens nas dimensões exatas de exibição.

O que o programa não faz (mas você precisa implementar no CMS/HTML):

• Adicionar width e height nas tags <img>
• Implementar loading="lazy" e rel="preload"
• Configurar srcset e sizes

Esses são ajustes de código que dependem do seu CMS ou template.

Exemplo prático: antes e depois

Página de produto de e-commerce — antes da otimização:

• Imagem principal: JPG 2.000×2.000px, 1,8 MB, sem dimensões no HTML
• 4 imagens de galeria: JPG 1.200×1.200px, 900 KB cada
• LCP: 6,2 segundos (Ruim)
• CLS: 0,35 (Ruim)
• Pontuação PageSpeed Mobile: 28/100

Após otimização com MKT com Marcos + ajustes de código:

• Imagem principal: WebP 800×800px (redimensionada), 85 KB, width="800" height="800" no HTML
• 4 imagens de galeria: WebP 600×600px, 35 KB cada
• LCP: 1,8 segundos (Bom)
• CLS: 0,02 (Bom)
• Pontuação PageSpeed Mobile: 74/100

A maior parte dessa melhoria veio da conversão e redimensionamento das imagens com o compressor — o restante de adicionar dimensões no HTML e lazy loading.

---

Perguntas Frequentes

Core Web Vitals realmente afetam o rankeamento no Google?
Sim. O Google confirmou que CWV é um fator de rankeamento desde maio de 2021. Não é o fator mais importante (relevância do conteúdo ainda domina), mas em nichos competitivos pode ser o diferencial entre posições.

Qual Core Web Vital é mais importante para imagens?
LCP, sem dúvida. A maioria dos problemas de LCP em sites comuns vêm de imagens pesadas ou sem preload. CLS é o segundo mais impactado por imagens (sem width/height).

Basta converter para WebP para melhorar o CWV?
É o passo mais impactante, mas não o único. Redimensionar para o tamanho correto e adicionar width/height no HTML são igualmente importantes para LCP e CLS, respectivamente.

Como saber qual é o elemento de LCP da minha página?
No Chrome DevTools (F12), vá em Performance, grave um carregamento da página, e procure pelo marcador "LCP" na linha do tempo. Ou use o PageSpeed Insights — ele mostra o elemento de LCP na seção "Diagnostics".

Lazy loading na imagem de LCP é uma boa ideia?
Não — é um erro comum e crítico. A imagem de LCP está na primeira viewport (parte visível sem scroll) e deve ser carregada imediatamente. Use loading="eager" (ou não especifique, que é o padrão) e adicione fetchpriority="high" nela.

CWV é medido em desktop ou mobile?
Nos dados do Search Console, o Google mede em ambos. Para rankeamento em mobile, o que conta são os dados mobile. E é justamente em mobile (conexões mais lentas, CPUs mais fracos) que imagens pesadas causam mais dano.

---

Comece pela parte mais impactante

Dos muitos fatores que afetam os Core Web Vitals, a otimização de imagens tem o maior ROI: é o passo com menor esforço técnico e maior impacto na pontuação. Converter suas imagens para WebP ou AVIF, redimensioná-las corretamente, e remover metadados desnecessários pode transformar um site lento em um site rápido — sem mudar uma linha de código.

O MKT com Marcos — Compressor de Imagens faz exatamente isso: conversão em lote, redimensionamento, múltiplos formatos modernos, motor Sharp/libvips de nível profissional — gratuito, offline, sem cadastro.

Acesse mktcommarcos.com.br/aplicacoes/compressor-de-imagens e melhore seus Core Web Vitals hoje.