Otimização de imagens pra web: AVIF, WebP e lazy loading
Descobri por acaso que 70% do tempo de carregamento de um site vinha de imagens. Imagens mal otimizadas. Basicamente o cliente estava pagando por banda de internet que não precisava.
Otimizar imagens parece básico. Mas a maioria dos devs não faz direito. Usam PNG pra tudo, deixa com resolução altíssima. Ou comprime demais e fica pixelado.
Existem padrões modernos agora. AVIF, WebP. Lazy loading. Srcset. Não é complicado de implementar. Impacto é absurdo.
JPEG é obsoleto
Vou ser direto: não use JPEG em site novo. Morreu. Especialmente pra clínicas que fazem uso pesado de imagem.
JPEG tem 20+ anos de idade. Compressão é ok mas pra fotos modernas, outros formatos são sempre melhores.
WebP é o segundo lugar. Compatibilidade é praticamente universal agora (todos os browsers modernos suportam desde 2020). Tamanho é 25-35% menor que JPEG com qualidade similar.
AVIF é o novo rei. Compatibilidade é mais recente (últimos 2 anos) mas já tá bom. Tamanho é 40-50% menor que JPEG. A qualidade mesmo comprimindo é impressionante.
Exemplo real: foto de sorriso de paciente em clínica. 2.5MB em JPEG. Converti pro AVIF. 600KB. Mesma resolução, mesma qualidade visual, para o olho humano é idêntico.
Como implementar: picture element
Não é complicado. Use a tag <picture>:
<picture>
<source srcset="smile.avif" type="image/avif">
<source srcset="smile.webp" type="image/webp">
<img src="smile.jpg" alt="antes-depois">
</picture>Browser primeiro tenta carregar AVIF. Se não suportar, tenta WebP. Se não suportar, usa JPEG como fallback.
Você assim oferece o formato melhor pra cada navegador. Usuário com browser novo? Recebe AVIF comprimido. Usuário com browser velho? Recebe JPEG que suporta.
Srcset e sizes: responsive images
Aqui é onde a maioria erra. Servem a mesma imagem grande pra dispositivo mobile que pra desktop. Desperdício monumental.
Seu site com imagem de 1920x1080 num celular? Bateu na tela, ficou meio pixelada (porque redimensionou via CSS) e usou banda desnecessária.
Use srcset:
<picture>
<source
srcset="foto-small.avif 640w, foto-med.avif 1024w, foto-large.avif 1920w"
type="image/avif">
<img src="foto.jpg" alt="antes" />
</picture>Você fornece 3 versões da mesma imagem em tamanho diferentes. Browser escolhe qual baixar baseado no tamanho da tela. Mobile pega small (100KB). Desktop pega large (800KB).
Pra clínica com galeria de antes-depois? Economia é colossal.
Lazy loading: carregar só o que vê
Página de clínica tem 20 fotos de casos. Você realmente quer carregar todas 20 logo quando abre a página? Não.
Adicione loading="lazy" na imagem:
<img src="foto.jpg" alt="caso" loading="lazy">Imagens carregam só quando usuário faz scroll e chega perto delas. Seu LCP (Largest Contentful Paint) cai drasticamente.
Real: página de clínica com 20 imagens acima da fold, sem lazy loading, levava 4.5s pra LCP. Com lazy loading: 0.9s. Nem é comparável.
Lazy loading é suportado por todos browsers modernos. Fallback automático em browsers velhos (carrega tudo assim mesmo, mas pelo menos tentou).
Ferramentas: converta suas imagens
Precisa converter suas imagens? Tem várias opções:
ImageMagick: linha de comando, poderoso, tem curva de aprendizado.
convert original.jpg -quality 80 output.avif
Squoosh (Google): website, visual, rápido. squoosh.app
TinyJPG: paga um pouco mas otimiza automaticamente.
Eu uso um script Node que roda localmente. Busca todos JPGs de uma pasta, converte pra AVIF e WebP, salva em subpasta. Roda num minuto.
Se preferir, tem ferramentas de build como sharp (Node) ou imagemin que automatizam tudo.
Um caso real
Cliente de clínica tinha site com 300+ imagens de casos. Tudo em JPEG, 2-3MB cada. Site carregava em 8 segundos.
Converti tudo pra AVIF com srcset (3 tamanhos cada). Implementei lazy loading. Adicionei picture element com WebP fallback.
Novo site? 2.5 segundos de LCP. Banda de dados por página caiu de 8MB pra 1.2MB.
Google Search Console começou a mostrar “Melhoria de Performance Detectada” uns dias depois. Ranking subiu porque Core Web Vitals melhorou.
Cliente pediu mais buscas de serviços (“por que melhorou?”). Resultado real.
Dicas extras
Sempre use alt text (importa pra SEO e acessibilidade).
Comprima seu AVIF um pouco menos agressivamente que WebP (AVIF fica feio com compressão muito alta).
Teste no seu celular. Às vezes imagem fica pixelada em qualidade muito baixa. Ajuste o trade-off.
Coloque images em CDN (Cloudflare, Vercel, qualquer coisa). Delivery é 10x mais rápido.
Monitorar Core Web Vitals depois. Google PageSpeed Insights te mostra exatamente quanto melhorou.
Vale a pena?
100% vale. Implementar leva umas 2-3 horas. Impacto é permanente. Cliente economiza em banda mensal, site fica mais rápido, SEO melhora.
Se você está otimizando um site e não está olhando pras imagens, tá deixando dinheiro na mesa.
- Converter imagens maiores pra AVIF e WebP
- Implementar picture element com fallbacks
- Adicionar lazy loading em todas imagens abaixo da fold
- Criar srcset com 2-3 tamanhos
- Testar no mobile e desktop
Quando NÃO usar lazy loading
Tem um detalhe: não use lazy loading em imagens acima da fold.
Imagem hero que aparece na home quando carrega? Carregue direto. Lazy loading tira o benefício porque a imagem fica lenta. Seu LCP fica ruim.
Use lazy loading só em imagens abaixo da fold. Aquelas que o usuário precisa fazer scroll pra ver.
Importante: a imagem hero ainda pode ser otimizada. Use picture element com AVIF/WebP. Só não coloque loading=“lazy”.
Otimizar pra mobile é prioritário
Sabe por quê 70% do tráfego é mobile? Porque celular tem telas menores e conexão mais fraca.
Seus responsive images precisam de tamanho bem menor pra mobile. A tag srcset que mostrei:
<source srcset="foto-small.avif 640w, ..." type="image/avif">Móvel pega a de 640w. 100KB no máximo.
Sem isso? Desktop de 1920w mandando 800KB pra uma tela de 375px. Desperdício criminoso.
Compressão inteligente
A qualidade que você escolhe comprimindo importa.
Para fotos (JPEG, AVIF, WebP): qualidade 75-85 é invisível pro olho humano mas economiza 30% em tamanho.
Para imagens com texto (PNG, que não comprime): você precisa de 90+ qualidade.
Eu teste. Salva a mesma imagem em qualidade 70, 75, 80, 85. Abre no celular. Vê qual qualidade fica invisível. Usa essa.
Cache e CDN
Uma coisa que ninguém menciona: de nada otimizar imagem se não usar CDN.
Imagem servida de seu servidor no Brasil chega em 400ms pra user em São Paulo.
Mesma imagem em Cloudflare CDN? 50ms.
Sempre coloque imagens em CDN. Cloudflare, Vercel, qualquer coisa. Faz mais diferença que qualquer otimização de formato.
Minha ordem de prioridade:
- CDN (impacto gigante)
- Lazy loading abaixo da fold (impacto grande)
- AVIF + WebP (impacto médio)
- Srcset responsive (impacto médio)
- Ajuste de qualidade (impacto pequeno)
Faça nessa ordem e você vai ter site muito mais rápido.
Monitorar resultado
Depois de otimizar, use Google PageSpeed Insights.
Tira screenshot do relatório. Mostra pra cliente. “Sua página melhorou de 45 pra 87 em mobile”. Cliente fica feliz.
Core Web Vitals tá melhorando? Lighthouse tá verde? Pronto, você otimizou direito.
- Converter imagens maiores pra AVIF e WebP
- Implementar picture element com fallbacks
- Adicionar lazy loading em todas imagens abaixo da fold
- Criar srcset com 2-3 tamanhos
- Testar em mobile e desktop
- Colocar imagens em CDN (Cloudflare ou similar)
- Monitorar Core Web Vitals depois de implementar
Leia também: Por que seu site carrega lento | Core Web Vitals em 2026 | Lighthouse 100 não significa site bom
Imagem otimizada é dinheiro que você tira da internet e coloca no bolso do cliente.