Serve images in modern formats no Lighthouse: corte abandono
Resumo
Se o Lighthouse está gritando “Serve images in modern formats”, eu trato como alerta de receita, não de código. Pra e-commerce e criadores, é uma das formas mais rápidas de baixar tempo de carregamento percebido e reduzir abandono sem mexer no produto.
Imagem pesa. Pesa no 4G do cliente, pesa no LCP da sua página e pesa no humor de quem está tentando comparar variações, cores e detalhes. E o pior: dá pra melhorar performance e ainda assim deixar foto de produto com cara de borrada — e isso mata conversão.
O caminho que funciona na prática é simples: priorize as imagens que mandam no LCP (hero e primeira dobra), exporte em AVIF/WebP, e sirva fallback decente. O resto vem depois, com método.
O que o Lighthouse mede (e por que isso não é “coisa de dev”)
Quando o Lighthouse aponta “Serve images in modern formats”, ele está te mostrando oportunidade de economia de bytes em imagens antigas (BMP, JPEG, PNG). Ele pega as imagens da página, converte para WebP e estima o tamanho em AVIF para calcular uma “economia potencial” por arquivo. Isso aparece como oportunidade porque, na maioria dos sites, trocar formato é mais fácil do que reescrever layout.
Importante: essa “economia potencial” não é um veredito. Ela não sabe se a sua foto tem textura fina (tecido, cabelo, metal escovado), nem se você usa zoom, nem se um PNG é transparente por necessidade. É um radar: “aqui tem bytes fáceis”. Fonte: Chrome for Developers (Lighthouse).
Como isso conversa com Core Web Vitals:
- LCP: diminuir o peso do maior elemento visível (muitas vezes uma imagem hero) costuma ser o ganho mais direto.
- CLS: formato moderno não resolve CLS sozinho. Se o seu layout ainda “pula”, é quase sempre falta de dimensões/reserva de espaço (atributos de width/height ou CSS) ou troca de fonte/elemento acima da dobra.
- INP: imagens menores reduzem trabalho de rede/decodificação e deixam o main thread menos pressionado, mas INP costuma piorar por JS e terceiros. Pense nisso como “tirar um peso das costas” do restante.
Ponto que a concorrência quase sempre ignora: dá pra piorar o CLS mesmo “otimizando”, quando você troca uma imagem por outra com proporção ligeiramente diferente (ex.: recorte diferente no mobile) e não trava aspect-ratio. Formato não é layout.
AVIF vs WebP vs JPEG/PNG: trade-offs reais para foto de produto
Semana passada, um lojista me chamou com um problema clássico: “converti pra WebP e o tecido ficou meio ‘lavado’”. Quase nunca é culpa do formato. Normalmente é pipeline sem critério: qualidade baixa demais, resize mal feito e zero ajuste de nitidez.
Use este quadro como regra prática (sem religião):
| Formato | Quando eu uso | Risco/contra |
|---|---|---|
| AVIF | Fotos grandes de PDP/hero quando quero o menor arquivo sem perder tanta qualidade | Suporte mais limitado; encoding pode ser mais pesado no servidor/pipeline |
| WebP | Padrão seguro pra quase tudo (foto + alguns gráficos), inclusive thumbnails | Se exagerar na compressão, textura fina vira “aquarela” |
| JPEG | Fallback universal pra foto, principalmente em navegadores antigos | Arquivo maior no mesmo “olho”; artefato em bordas/gradientes |
| PNG | Fallback quando preciso de transparência real ou gráfico com borda muito nítida | Pesa muito; “economia potencial” do Lighthouse costuma ser enorme |
Como evitar perder nitidez em produto (o detalhe que quase ninguém coloca no SERP):
- Redimensione antes de comprimir. Comprimir primeiro e depois reduzir costuma acentuar artefato.
- Se a imagem tem textura (tecido, couro, cabelo, grão), teste uma qualidade um pouco acima no AVIF/WebP para a hero/PDP e compense com corte melhor e dimensões corretas.
- Evite “upscale” por CSS. Se você exporta 800 px e exibe em 1200 px, qualquer formato vai parecer pior.
Se você quer um fluxo “formato primeiro” pensando em e-commerce (crop + fundo + export), eu deixo um guia que a gente usa como base: Image Optimization for Ecommerce: Crop, Background, Format First.
Fallback sem drama: como servir AVIF/WebP sem quebrar nada
Você precisa mesmo de fallback? Sim — especialmente com AVIF. O próprio Lighthouse trata AVIF como “suporte mais limitado” e, na prática, você não quer descobrir compatibilidade no carrinho: sirva uma versão moderna e uma versão universal.
Checklist direto (o “feito é melhor que perfeito”):
- Escolha 3 alvos pra começar: hero da home, imagem principal da PDP, e thumbnails acima da dobra.
- Exporte 2 versões por alvo: AVIF (ou WebP) + JPEG (fallback). Se você precisa transparência real, use WebP/PNG conforme o caso.
- Sirva com
<picture>(ordem importa): AVIF, depois WebP, e o<img>como fallback. - Trave layout: defina
widtheheight(ouaspect-ratio) pra evitar CLS. - Não dê lazy no LCP: a imagem que “manda” no LCP deve carregar cedo. Lazy é pra abaixo da dobra.
Heurística prática pra cortar abandono rápido: comece pela imagem de LCP e trate como “orçamento de bytes”. Em e-commerce, eu miro algo como ~80–200 KB para a hero/PDP principal (varia por fotografia e dimensões), e ajusto qualidade/resize até bater isso sem matar textura. Se a sua LCP image está com 400–900 KB, você quase sempre tem ganho fácil.
Exemplo pronto pra colar (hero/LCP):
<picture>
<source type="image/avif" srcset="/img/produto-1200.avif" />
<source type="image/webp" srcset="/img/produto-1200.webp" />
<img
src="/img/produto-1200.jpg"
width="1200"
height="1200"
alt="Tênis preto em couro, vista lateral"
decoding="async"
fetchpriority="high"
/>
</picture>O custo escondido de converter “tudo”: você gasta tempo/CPU/processo em imagens que não movem métrica nenhuma, e ainda corre risco de degradar qualidade em lote. Priorize o que o usuário vê primeiro e o que é repetido (thumbs de categoria). Depois você expande.
EN quick take: Start with 3 targets (homepage hero, PDP main image, above-the-fold thumbnails). Serve AVIF/WebP via <picture> with a JPEG fallback, avoid lazy-loading the LCP image, and treat the LCP image as a byte budget (roughly ~80–200 KB for many ecommerce hero/PDP images) without destroying texture.
Pipeline simples que dá resultado (sem matar qualidade): do recorte ao export
Vou ser contraintuitivo aqui: trocar formato antes de arrumar recorte e dimensões costuma dar pouco retorno. O ganho grande aparece quando você para de enviar pixels que ninguém vê.
Cenário típico de e-commerce: a imagem do produto chega com 3000 px, fundo irregular, muito “respiro” em volta, e vai virar um thumbnail de 300 px. Você paga para baixar e decodificar uma foto gigante só para mostrar um objeto pequeno. O formato moderno ajuda, mas o recorte certo resolve metade do problema.
Atalho de priorização que eu uso: abra o Chrome DevTools, simule Fast 4G, recarregue e veja qual imagem aparece como LCP (no painel Performance/Lighthouse/Insights). Essa é a primeira que você ajusta (dimensões, crop, AVIF/WebP e fallback). Só depois vale entrar em galeria e long tail.
Checklist de export (o que eu confiro antes do formato):
- Dimensões: exporte baseado no maior tamanho real de exibição (ex.: 1200 px para hero, 800 px para PDP, 400 px para thumbs — ajuste ao seu layout, não ao “achismo”).
- Qualidade: para produto, prefiro subir qualidade e cortar peso com recorte/redimensionamento; compressão agressiva é o atalho que deixa “plástico”.
- Naming: inclua variação e tamanho no nome (ex.:
tenis-preto-1200.avif) para cache e organização; evita “sobrescrever” sem perceber. - Fundo: se removeu fundo, valide borda/cabelo/recortes finos; artefato em halo aparece mais em fundo branco.
- Prioridade: hero e imagem principal da PDP primeiro; depois categoria; só então galeria completa e imagens long tail.
Quer um plano de ataque focado em Core Web Vitals para produto? Este post conecta recortes, formatos e métricas com exemplos práticos: Smaller Product Images Win: WebP/AVIF, Crops, Core Web Vitals.
Erros comuns que mantêm CLS mesmo com AVIF/WebP: (1) não reservar espaço para carrossel/galeria; (2) carregar badge/selo acima da imagem depois do primeiro paint; (3) trocar imagem por outra com proporção diferente no breakpoint sem travar aspect-ratio; (4) usar skeleton com altura diferente do conteúdo final.
FAQ
Como o Lighthouse calcula a economia do alerta “Serve images in modern formats”?
Ele coleta imagens em formatos antigos (BMP, JPEG, PNG), converte para WebP e estima o tamanho em AVIF para sugerir a economia potencial por arquivo. Isso é um cálculo aproximado: serve para priorizar onde vale mexer primeiro, não como prova de “qualidade visual”.
Preciso usar AVIF e WebP ao mesmo tempo?
Não é obrigatório. Se você quer simplicidade, WebP + JPEG fallback já resolve boa parte dos ganhos. AVIF costuma valer mais para imagens grandes (hero/PDP) quando você quer espremer bytes sem piorar tanto a qualidade, mantendo fallback para compatibilidade.
Por que meu CLS continua alto mesmo depois de trocar as imagens?
Porque CLS é layout, não formato. Normalmente o problema é falta de reserva de espaço (dimensões/aspect-ratio), elementos injetados acima da dobra (badges, banners, fontes) ou imagens com proporção diferente entre breakpoints. Trave o espaço e só depois refine o formato.
Quando faz sentido não converter uma imagem para AVIF/WebP?
Quando a imagem já é pequena e não é crítica (ganho marginal), quando você depende de transparência/arestas ultra-nítidas que ficam melhores em PNG em alguns casos, ou quando a conversão em massa está degradando fotos de produto. Priorize as imagens que mandam no LCP e as que aparecem centenas de vezes (thumbnails).
