O Vilão Silencioso Que 90% dos Sites Não Consegue Identificar
Se o seu site carrega em 5+ segundos no celular, a causa número 1 não é o JavaScript, não é o CSS, não é o servidor. São as imagens. Estudo do HTTP Archive mostra que imagens representam 51% do peso total de uma página web média. Em sites mal otimizados, esse número chega a 80%.
O Google usa o LCP (Largest Contentful Paint) como métrica de ranqueamento, e o elemento LCP é, em 75% dos sites, uma imagem — geralmente o hero/banner principal. Se essa imagem demora para carregar, seu ranqueamento despenca.
Neste artigo, vou abrir o arsenal técnico para resolver isso em 1 tarde.
1. O Padrão Atual de Imagens em 2026 (E Por Que JPEG Não Serve Mais)
A evolução dos formatos de imagem para web:
| Formato | Compressão vs JPEG | Suporte Navegadores | Qualidade Visual | Caso de Uso |
|---|---|---|---|---|
| JPEG | Baseline (péssimo) | 100% | Boa | Legacy (evite) |
| PNG | Pior que JPEG (sem compressão com perda) | 100% | Excelente | Logos, ícones (com transparência) |
| WebP | -30% em média | 98% | Excelente | Padrão 2020-2024 |
| AVIF | -50% em média vs JPEG | 96% (todos os navegadores modernos em 2026) | Superior | Padrão 2026 |
| JPEG XL | -40% em média | 50% (suporte limitado) | Excelente | Futuro (não use agora) |
Recomendação Alpha Code: AVIF com fallback para WebP. Caso o navegador não aceite nenhum dos dois, fallback para JPEG. Isso é feito com a tag <picture> e a ordem correta dos <source>.
2. O Markup Correto (Copiável)
<picture>
<source
type="image/avif"
srcset="
/img/hero-400.avif 400w,
/img/hero-800.avif 800w,
/img/hero-1200.avif 1200w,
/img/hero-1920.avif 1920w
"
sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
/>
<source
type="image/webp"
srcset="
/img/hero-400.webp 400w,
/img/hero-800.webp 800w,
/img/hero-1200.webp 1200w,
/img/hero-1920.webp 1920w
"
sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
/>
<img
src="/img/hero-800.jpg"
alt="Descrição semântica do conteúdo da imagem"
width="1920"
height="1080"
loading="eager"
fetchpriority="high"
decoding="async"
/>
</picture>
Detalhando cada atributo crítico:
srcset+sizes: o navegador escolhe a imagem certa para o viewport. Celular baixa 400px, desktop baixa 1920px. Economia típica: 70-85% de bytes.widtheheight: reservam espaço antes do download. Evita CLS (layout shift) e melhora perceived performance.loading="eager"+fetchpriority="high": diz ao navegador “essa é a LCP, baixe primeiro”. Para imagens below the fold, useloading="lazy".decoding="async": não bloqueia renderização enquanto decodifica.<picture>com<source>em ordem: o navegador pega o primeiro formato que aceita (AVIF > WebP > JPEG fallback).
3. Os 3 Tipos de Imagens e Como Tratar Cada Um
3.1. Imagem LCP (Hero/Banner Principal)
- Formato: AVIF + WebP + JPEG fallback
- Tamanho: 1920px (desktop) / 800px (tablet) / 400px (mobile)
- Loading:
eager(carrega imediatamente) - Fetchpriority:
high(prioridade máxima) - Lazy loading: NUNCA
- Preload no
<head>: SIM, com<link rel="preload" as="image" imagesrcset="..." imagesizes="...">
3.2. Imagens Below the Fold (Conteúdo, Galeria, Cards)
- Formato: AVIF + WebP + JPEG fallback
- Tamanho: conforme necessário (geralmente 400-800px)
- Loading:
lazy(carrega só quando aparece no viewport) - Fetchpriority:
auto(padrão) - Decoding:
async
3.3. Imagens Decorativas (Background, Padrões, Ornamentos)
- Formato: AVIF + WebP
- Loading:
lazy - Alt: vazio (
alt="") — é decorativa, não informativa - ARIA:
role="presentation" - CSS background-image com
image-set()para responsividade
4. O Erro Crítico: Imagens Sem width e height
A maioria dos sites não declara dimensões nas imagens. Resultado: quando a imagem baixa, ela “empurra” o conteúdo, causando CLS alto (Cumulative Layout Shift). O Google penaliza diretamente.
Sempre declare: <img src="..." width="1920" height="1080" ...>. Pode usar CSS para ajustar visualmente, mas os atributos HTML devem estar lá.
5. Como Gerar AVIF/WebP em Lote (Ferramentas)
Em Linha de Comando (Linux/Mac/WSL)
# Converter todas as imagens JPG de uma pasta para AVIF + WebP
for f in img/*.jpg; do
cwebp -q 80 "$f" -o "${f%.jpg}.webp"
avifenc --min 0 --max 63 -a end-usage=q -a cq-level=20 "$f" "${f%.jpg}.avif"
done
Ferramentas Online
- Squoosh.app (Google) — conversão visual, ideal para avulsos
- TinyPNG / TinyJPG — compressão adicional
- Cloudflare Images — serviço pago, gera AVIF/WebP automaticamente + CDN
Em Framework (Astro/Next)
Astro e Next.js têm componentes <Image> / <Picture> que fazem tudo automaticamente:
---
import { Image } from "astro:assets";
import hero from "../assets/hero.jpg";
---
<Image
src={hero}
alt="..."
widths={[400, 800, 1200, 1920]}
sizes="(max-width: 600px) 400px, 800px"
formats={["avif", "webp"]}
loading="eager"
fetchpriority="high"
/>
6. CDN de Imagens: Quando Vale a Pena
Para sites com muitas imagens (>500) ou tráfego alto, considere:
- Cloudflare Images (R$ 0,05/GB armazenado, transformações inclusas)
- Cloudinary (plano free até 25 créditos/mês)
- imgix (enterprise, mas com trial)
- Vercel Image Optimization (incluído no Vercel Pro)
Benefícios: transformação dinâmica, AVIF/WebP automático, compressão por dispositivo, lazy serving.
7. Os 5 Erros Mais Comuns (E Como Evitar)
Erro 1 — Imagem gigante servida para mobile
Cenário: foto de 4000x3000 (2MB) servida para um celular de 360px. Solução: srcset com breakpoints.
Erro 2 — Sem alt ou alt genérico
Cenário: <img src="foto.jpg"> ou <img alt="imagem">. Solução: alt descritivo, com palavras-chave naturais (sem spam).
Erro 3 — Carregamento eager de imagens below the fold
Cenário: 20 imagens carregando simultaneamente. Solução: loading="lazy" em todas, exceto a LCP.
Erro 4 — Não usar decoding="async"
Cenário: thread principal bloqueada decodificando imagem. Solução: decoding="async".
Erro 5 — Imagens de placeholder com peso real
Cenário: usar imagem estática como placeholder. Solução: usar blurhash ou LQIP (Low Quality Image Placeholder) real, com 1-2KB.
8. Ferramentas Para Auditar
- PageSpeed Insights → “Diagnosticar problemas de imagem”
- Squoosh → comparar tamanho/qualidade
- Chrome DevTools → Network → Img → ver tamanho transferido
- ImageMagick / libvips → automação local
9. O Impacto Real nos Números
Case real da Alpha Code:
- Site antes: 6 imagens não otimizadas, total de 3.8MB
- Site depois: 6 imagens em AVIF/WebP responsivas, total de 380KB (90% redução)
- LCP: passou de 4.2s para 0.9s
- Tráfego orgânico: subiu 32% em 60 dias
- Conversão: subiu 41% no formulário
Otimizar imagens é a maior alavanca de performance que existe. Não é “nice to have”. É tabela de entrada em 2026.
A Alpha Code Otimiza Imagens Por Padrão Em Todo Projeto
Não entregamos site com “imagem bonita” sem otimização. Entregamos:
- AVIF + WebP + fallback automático
- Responsividade real com
srcset+sizes fetchpriority="high"na LCP- Lazy loading em todas as below the fold
- Dimensões declaradas (zero CLS)
- Preload no
<head>quando necessário - Auditoria pós-deploy com PageSpeed
O resultado: sites com LCP consistentemente abaixo de 1.2s em 4G real.