Otimização de imagens — guia prático

Tudo que o ImageLens avalia, com o porquê de cada regra e exemplos lado a lado.

1. Sirva no tamanho real exibido

Se uma imagem aparece em 320×320 na tela mas o arquivo tem 1080×1080, você está enviando ~10× mais pixels do que o necessário. Mobile paga isso em bateria, dados e tempo de carregamento.

Por quê: O navegador precisa baixar e decodificar o arquivo inteiro antes de redimensionar. Quanto mais pixels, mais memória e mais tempo. Para telas retina, sirva no máximo 2× o tamanho exibido.

Uso na LP	Largura recomendada	Peso ideal
Ícone / avatar	64–128px	≤ 20 KB
Card pequeno	320–480px	≤ 60 KB
Card grande	600–800px	≤ 120 KB
Hero mobile	600–900px	≤ 150 KB
Hero desktop	1200–1600px	≤ 250 KB

Quer testar uma imagem específica? Use a aba Otimizar imagem.

2. Use WebP ou AVIF no lugar de PNG/JPG

Formatos modernos comprimem muito melhor sem perda visível de qualidade.

AVIF — melhor compressão atual (~50% menor que JPEG). Ideal para fotos.
WebP — ótimo equilíbrio entre tamanho e suporte. Padrão recomendado.
PNG — só para logos, ícones e arte com transparência.
JPEG — fotos quando não puder usar WebP/AVIF.
SVG — vetorial, escala sem perda. Ideal para ícones e logos.

Por quê: Trocar um JPEG hero de 400 KB por AVIF normalmente cai para 120–180 KB com qualidade visualmente igual. Em mobile 4G isso é a diferença entre um LCP de 2.8s e 1.4s.

Você pode converter usando a aba Otimizar imagem deste site, ou ferramentas como Squoosh e TinyPNG.

3. srcset e sizes — uma imagem para cada tela

Com srcset você fornece várias versões da imagem; o navegador escolhe a melhor para a tela atual (largura + densidade de pixel).

Por quê: Sem srcset, o mesmo arquivo pesado vai para o iPhone SE e para o monitor 4K. Você desperdiça banda em telas pequenas.

Faça assim

<img
  src="/img/produto-640.webp"
  srcset="
    /img/produto-320.webp 320w,
    /img/produto-640.webp 640w,
    /img/produto-1080.webp 1080w"
  sizes="(max-width: 768px) 80vw, 320px"
  alt="..."
  width="640" height="640"
  loading="lazy" decoding="async"
/>

O navegador escolhe a versão certa por viewport e DPR.

Evite

<img
  src="/img/produto-1080.png"
  alt="..."
/>

Mesmo arquivo grande para todos. Sem dimensões → CLS.

4. Lazy loading abaixo da dobra (mas nunca no LCP)

Use loading="lazy" em imagens que ficam abaixo da primeira tela. Nunca aplique no hero ou na imagem do LCP.

Por quê: Com lazy, o navegador adia o download até a imagem chegar perto do viewport. No hero/LCP isso atrasa a renderização do maior elemento — exatamente o que o Core Web Vital mede.

Faça assim

<!-- Hero / LCP: prioridade alta -->
<img src="/hero.webp" alt="..."
  fetchpriority="high" decoding="async" />

<!-- Abaixo da dobra: lazy -->
<img src="/depoimento.webp" alt="..."
  loading="lazy" decoding="async" />

Evite

<!-- Lazy no hero atrasa o LCP -->
<img src="/hero.webp" alt="..."
  loading="lazy" />

5. Priorize a imagem do LCP

LCP (Largest Contentful Paint) é o tempo até o maior elemento visível aparecer — quase sempre uma imagem hero. É um dos três Core Web Vitals do Google.

Por quê: fetchpriority="high" e <link rel="preload"> dizem ao navegador "comece a baixar isso antes de qualquer outra coisa". Sem isso, ele descobre a imagem só depois de processar o HTML inteiro.

<!-- No <head> -->
<link rel="preload" as="image"
  href="/hero-1200.webp"
  imagesrcset="/hero-600.webp 600w, /hero-1200.webp 1200w"
  imagesizes="100vw" />

<!-- No <body> -->
<img src="/hero-1200.webp" alt="..."
  width="1200" height="800"
  fetchpriority="high" decoding="async" />

6. Sempre defina width e height

Mesmo que o CSS redimensione, declare width e height com a proporção original. O navegador reserva o espaço antes da imagem carregar.

Por quê: Sem dimensões, o conteúdo abaixo da imagem é empurrado quando ela aparece — isso é CLS (Cumulative Layout Shift), outro Core Web Vital. Pior ainda, leitores tocam no botão errado quando o layout pula.

Clique em "Recarregar" e observe o pulo de layout no card da direita.

Com width/height (sem CLS)

Texto abaixo da imagem permanece estável.

Sem dimensões (CLS)

Texto abaixo da imagem é empurrado quando ela carrega.

Faça assim

<img src="/foto.webp" alt="..."
  width="640" height="360" />

Espaço reservado → zero layout shift.

Evite

<img src="/foto.webp" alt="..." />

Conteúdo abaixo pula quando a imagem chega.

7. Cuidado com background-image em CSS

O navegador descobre background-image tarde no pipeline — só depois de baixar e parsear o CSS. Para imagens críticas (hero, LCP), prefira <img>.

Por quê: Tags <img> são detectadas pelo preload scanner do navegador assim que o HTML chega. background-image espera o CSSOM ser construído. Diferença típica: 200–600ms no LCP.

Faça assim

<!-- Hero como <img> -->
<img src="/hero.webp" alt="..."
  fetchpriority="high" />

Detectado imediatamente pelo preload scanner.

Evite

<!-- Hero como background -->
<div class="hero" style="background-image: url(/hero.webp)"></div>

Só baixa depois do CSS — atrasa o LCP.

8. Checklist final

Tamanho real conferido (no máximo 2× o exibido)
Convertida para WebP ou AVIF
Variantes responsivas com srcset + sizes
loading="lazy" em imagens fora da dobra
fetchpriority="high" + preload no hero
width e height sempre declarados
alt descritivo (acessibilidade e SEO)
PageSpeed Insights re-rodado e LCP < 2.5s