AVIF vs WebP no e-commerce: WebP + para LCP mais previsível

AVIF vs WebP: escolha pelo tipo de imagem (não pelo hype)

Minha posição é simples: para e-commerce e criadores, AVIF não é “sempre melhor”. WebP bem servido com <picture> costuma entregar Core Web Vitals mais previsíveis, com menos atrito no time e na operação. AVIF entra como opção forte quando você sabe exatamente o que está otimizando: foto grande, muita repetição de padrões (tecido, pele, sombras suaves) e prioridade máxima em bytes.

O problema é que muita gente compara formatos como se fosse só “qual comprime mais”. No dia a dia, o que decide é o pacote completo: compressão e qualidade percebida e tempo de encode e custo de pipeline e compatibilidade/bugs e facilidade de fallback. Para Core Web Vitals, previsibilidade conta quase tanto quanto tamanho do arquivo.

Eu gosto de começar pela pergunta que ninguém quer responder: qual é o seu tipo de imagem dominante? Produto (foto real), banner com texto, ícone, logo com transparência, thumbnail com recorte, arte com degradê, ou mistura de tudo?

• Foto de produto (catálogo): WebP é o “default seguro”. AVIF pode virar “tier 2” para páginas críticas (PDP/landing) quando o ganho é real e o decode/encode não vira gargalo.
• Banner com texto/arte com tipografia: eu evito AVIF por padrão. Arte com texto é onde aparecem halos, banding e perda de nitidez mais fácil. Se a peça precisar de transparência perfeita, PNG ou WebP lossless costumam ser mais previsíveis.
• Ícones/logos (bordas duras, 1–3 cores): quase sempre PNG (bem otimizado) ou SVG (quando fizer sentido). AVIF aqui é uma armadilha comum: você troca “poucos KB” por risco de artefato em borda e dor de cabeça de revisão.

Se você quer um norte rápido: use WebP como base, e trate AVIF como uma otimização adicional onde você mediu ganho (bytes/LCP) e não criou regressão visual. Se você já usa WebP e está pensando em “AVIF em tudo”, eu recomendo ler nosso guia de troca com qualidade controlada em fotos de produto: Switching WebP to AVIF for product photos (without halos).

Core Web Vitals e LCP: bytes importam, mas decode também

Um número que vale fixar: imagens respondem por uma fatia enorme do que vira LCP em sites reais. A Smashing Magazine cita que imagens representam cerca de 42% do elemento de Largest Contentful Paint (LCP) em websites — por isso “formato de imagem” vira conversa de performance tão cedo no diagnóstico. Fonte: Smashing Magazine.

Só que reduzir bytes não é o único caminho para melhorar o LCP percebido. Em aparelhos intermediários (celular de 2–3 anos, CPU limitada), o custo de decode pode virar parte do tempo total até a imagem “pintar” com qualidade. E aqui aparece um trade-off que o SERP raramente coloca na mesa de forma prática: AVIF pode reduzir muito o download, mas nem sempre reduz o tempo total na vida real se a imagem for grande e o device sofrer para decodificar.

Como isso aparece no seu dia? Você troca JPEG/WebP por AVIF, vê “transfer size” cair, mas o LCP não melhora na mesma proporção (ou piora em alguns aparelhos). Isso pode acontecer por:

• Decode mais caro: mais tempo de CPU para transformar bytes em pixels.
• Prioridade e layout: imagem sem width/height ou com CSS que muda o tamanho gera recalculo e atrasa pintura.
• Erros de pré-carregamento: preload do formato errado ou sem imagesrcset faz o navegador baixar “a versão errada” primeiro.

O ponto prático: para e-commerce, a meta não é “menor arquivo”, é LCP mais baixo com menos variância em devices e redes diferentes. Por isso WebP + <picture> costuma ser mais previsível como primeira etapa.

Se você está estruturando um plano de redução de bytes + recortes + formatos, eu juntaria isso num único fluxo (corte + fundo + formato) em vez de “format-first sem olhar imagem”. A gente detalha essa sequência aqui: Image Optimization for Ecommerce: Crop, Background, Format First.

Quando evitar AVIF: logos, texto, transparência e bordas duras

Você já viu isso: um banner com texto fino, exportado em AVIF “porque é moderno”, e de repente as letras ficam com um contorno estranho. Ou um logo com fundo transparente que parece “sujo” em cima de um fundo colorido. A culpa não é do seu olho — é o tipo de conteúdo.

AVIF brilha em foto. Mas em arte não fotográfica (logos, UI, ilustração flat, texto nítido, bordas duras), os artefatos ficam mais óbvios e mais caros de revisar. Em e-commerce, isso vira custo operacional: designer reexporta, alguém compara, QA abre ticket, o time tenta “um quality maior” e o arquivo volta a crescer. Você não quer isso na esteira diária.

Checklist rápido para decidir “evitar AVIF” sem drama:

1. Tem texto pequeno? (CTA, preço, selo, tagline) Prefira PNG bem otimizado, SVG (se for vetor), ou WebP lossless quando fizer sentido.
2. Tem transparência crítica? (logo sobre fundos variados) PNG ainda é o baseline previsível; WebP lossless costuma funcionar bem quando você quer reduzir tamanho sem mudar a aparência.
3. Tem borda dura/flat? (ícones, ilustração flat) Priorize consistência visual; o ganho de bytes raramente paga o risco de halo.
4. Tem gradiente suave em UI? Teste com cuidado. Banding em gradiente é o tipo de bug que passa na pressa e dói depois.

Isso não significa “AVIF nunca”. Significa “AVIF com regra”: foto de produto, hero fotográfico, galeria — e sempre com comparação visual. Quando o ativo tem texto ou precisa de transparência perfeita, eu começo com PNG/WebP (lossless se necessário) e só mudo se o ganho for claro e sem regressão.

Quer ver como essa conversa vira resultado em página real (bytes, crops, e impacto em CWV)? Este texto conecta recorte + tamanho + formato em e-commerce: Smaller Product Images Win: WebP/AVIF, Crops, Core Web Vitals.

Progressive enhancement com <picture>: o caminho “sem atrito”

Quer uma afirmação que vai contra a ansiedade do “novo formato”? Você não precisa escolher um único formato para sempre. O jeito mais limpo de servir AVIF e WebP sem quebrar nada é progressive enhancement com <picture>: você entrega o melhor formato que o navegador aceita, e mantém fallback para JPEG/PNG quando precisar.

O básico que funciona em produção é: AVIF primeiro (se você realmente quer oferecer), WebP depois, e então JPEG/PNG. E você mantém srcset/sizes bem configurados para não baixar uma imagem grande à toa.

<picture>
  <source type="image/avif" srcset="/img/produto-400.avif 400w, /img/produto-800.avif 800w" sizes="(max-width: 600px) 400px, 800px">
  <source type="image/webp" srcset="/img/produto-400.webp 400w, /img/produto-800.webp 800w" sizes="(max-width: 600px) 400px, 800px">
  <img src="/img/produto-800.jpg" width="800" height="800" loading="lazy" decoding="async" alt="">
</picture>

Quatro detalhes que evitam dor (e explicam muita “otimização que não mexe no LCP”):

• Não esqueça width/height no <img>: isso segura layout e reduz surpresa no carregamento.
• Use sizes de verdade: se você chuta errado, o browser escolhe um arquivo maior “por segurança” e seu ganho some.
• Se for a imagem de LCP (hero): não trate como “lazy”. Em muitas páginas, você quer loading="eager" e fetchpriority="high" para reduzir variância (principalmente em mobile).
• Cuidado com preload mal feito: se você fizer <link rel="preload" as="image"> sem imagesrcset/imagesizes, é comum pré-carregar “a versão errada” e pagar download duplicado.

Do ponto de vista de operação, <picture> também evita uma armadilha comum: tentar “adivinhar formato” no servidor com content-negotiation e acabar fragmentando cache no CDN. Você publica as variantes e deixa o navegador escolher — simples, estável e fácil de auditar.

Esse padrão resolve o tópico que sempre aparece na reunião: AVIF browser support. Você não precisa apostar em compatibilidade perfeita — você oferece e deixa o navegador escolher. Para o usuário, a página só abre. Para você, o rollout é gradual e controlável.

E se o seu time pede “AVIF to WEBP” ou “AVIF to JPG” no dia a dia, trate isso como parte do pipeline, não como tarefa manual. Manual vira dívida: alguém esquece, alguém exporta errado, e você descobre só depois.

Fluxo de otimização para fotos de produto: do estúdio ao CDN

Se você vende produto, sua dor não é “qual formato é melhor”. Sua dor é: como escalar consistência visual + performance com uma equipe pequena. Aqui vai um fluxo que eu já vi funcionar bem em lojas com catálogo grande, sem virar projeto interminável.

Etapa	Decisão prática	Por que isso vem agora
1) Master	Guarde uma master (TIFF/PNG) fora do site	Evita “recompressão sobre recompressão” quando você muda pipeline
2) Recorte e fundo	Normalize proporção (ex: 1:1) e fundo (branco/transparente)	Reduz variância, melhora cache, facilita srcset
3) Tamanhos	Gere 2–4 larguras úteis (ex: 400/800/1200px)	Ataca bytes mais do que “trocar formato” sozinho
4) Formatos	WebP como base + JPEG fallback; AVIF opcional por rota	Menos risco, rollout gradual, CWV mais previsível
5) Entrega	<picture>, cache longo, CDN	Evita download duplicado e dá estabilidade

O “pulo do gato” aqui é operacional: AVIF costuma exigir mais disciplina no encode. Se você tem 10 mil imagens e decide subir o quality “porque apareceu halo em 20”, seu custo de reprocessamento explode e seu tempo de build sobe. WebP tende a ser mais tranquilo como formato base justamente por isso: a operação é menos sensível.

Se a sua equipe é pequena, eu recomendo uma regra de ouro: otimize a maior parte do catálogo com WebP previsível, e trate AVIF como “classe premium” só para rotas que pagam (home, landing, coleção campeã). Isso evita refazer tudo quando o time descobre um problema de qualidade em um tipo específico de foto.

Quer um gancho de ROI rápido que aparece fora do catálogo também? Em páginas de captura e formulários, imagens leves reduzem fricção e ajudam CWV. A gente já escreveu sobre esse ângulo aqui: Signup form que converte: imagens leves (WebP/AVIF) + Core Web Vitals (ROI rápido).

Como medir ganhos (de verdade) e evitar regressões silenciosas

A parte que separa “otimizei imagens” de “melhorei o site” é medir antes/depois sem autoengano. Não precisa virar laboratório. Precisa de consistência: mesma página, mesmo template, mesma rota, e um conjunto pequeno de imagens representativas.

Eu uso um roteiro simples em 2 camadas: bytes (o que você paga na rede) e tempo (o que o usuário sente). Para e-commerce, eu priorizo páginas onde o LCP é foto de produto ou banner principal.

Regra prática: se você reduziu 30–40% do “transfer size” da imagem principal, mas o LCP não mexeu, desconfie de decode/priority/layout. A solução pode estar no sizes, no preload ou no CSS — não no formato.

Checklist de medição que cabe no sprint:

1. Escolha 3 páginas: home, uma PDP (produto), uma coleção.
2. Separe 10 imagens: 6 fotos reais, 2 banners com texto, 2 logos/ícones.
3. Meça bytes: compare peso por formato e por tamanho (400/800/1200px). Se você não corta tamanhos, você vai “ganhar” pouco no mundo real.
4. Meça LCP e TBT/INP em devices reais: nem tudo aparece no seu MacBook. Um Android intermediário é onde regressão de decode aparece.
5. Valide visual: zoom em 200% nos cantos, bordas e texto. Halo e banding são “pequenos” até virarem reclamação de marca.

Erros comuns que eu continuo vendo (e que dão trabalho depois):

• AVIF em arte com texto e transparência para “economizar KB” e, semanas depois, alguém nota o texto borrado no criativo de campanha.
• Sem fallback decente: o time sobe AVIF e esquece JPEG/PNG, e a compatibilidade vira bug intermitente.
• Pipeline manual (“AVIF to JPG” na pressa): um arquivo entra fora do padrão, e sua biblioteca vira um mosaico inconsistente.

Se você quer aplicar a tese deste artigo sem se perder: WebP como base, <picture> com fallback, e AVIF só onde você mediu ganho e validou qualidade. É menos glamouroso do que “AVIF em tudo”, mas para Core Web Vitals e operação, é o que se sustenta mês após mês.

FAQ

Quando vale a pena usar AVIF em e-commerce?

Quando a imagem é fotográfica (produto/hero), grande e realmente pesa no carregamento, AVIF pode reduzir bytes de forma relevante. Eu uso como camada extra via <picture>, mantendo WebP e JPEG/PNG como fallback, e só amplio o uso depois de validar qualidade e LCP em device real.

Como fazer fallback de AVIF sem quebrar compatibilidade?

Use <picture> com <source type="image/avif">, depois image/webp, e finalize com <img> em JPEG/PNG. Assim, o navegador escolhe o melhor formato suportado e você não precisa “adivinhar” AVIF browser support.

AVIF é ruim para logos e imagens com texto?

Não é “ruim”, mas é mais arriscado: artefatos em bordas duras, halos em letras e problemas em transparência aparecem com mais facilidade e custam caro para revisar. Para logos/ícones e banners com texto, PNG bem otimizado, SVG (quando aplicável) ou WebP lossless tendem a ser mais previsíveis.

Como converter AVIF to WEBP ou AVIF to JPG sem dor?

Trate conversão como parte do pipeline (build/CDN), não como tarefa manual. Gere WebP e JPEG/PNG a partir da master original e publique via <picture>; converter de AVIF para outro formato como “origem” aumenta o risco de perda acumulada e inconsistência visual.