WebP vs AVIF em 2026: Qual Usar no Seu Site
Comparativo honesto de 2026: WebP vs AVIF para performance web, suporte de navegador, tamanho de arquivo, velocidade de codificação e a cadeia prática de fallback, com benchmarks reais.
WebP saiu em 2010. AVIF saiu em 2019. Em 2026, os dois estão maduros, os dois têm ~94%+ de suporte global de navegador, e os dois esmagam JPG/PNG em tamanho de arquivo. Mas escolher entre eles, ou como usar os dois, ainda confunde desenvolvedores e gestores de conteúdo. Este guia te dá benchmarks reais e uma regra de decisão limpa.
TL;DR, a resposta de 2026
Para sites estáticos e ativos pré-construídos: AVIF primeiro, WebP como fallback, JPG/PNG por último. A tag <picture> cuida da cadeia automaticamente.
<picture>
<source srcset="/img/foto.avif" type="image/avif" />
<source srcset="/img/foto.webp" type="image/webp" />
<img src="/img/foto.jpg" alt="…" />
</picture>Para redimensionamento dinâmico, geração em tempo real ou orçamentos restritos de CPU: só WebP. A codificação AVIF é pesada demais em tempo de requisição.
A decisão em uma frase
Se a imagem é gerada uma vez e servida para sempre, use AVIF + fallback WebP. Se é gerada por requisição, use só WebP.
Benchmarks reais: mesma fonte, ambos os formatos
10 fotos representativas comprimidas em qualidade “visualmente sem perdas” (SSIM ≥ 0,99 vs original):
| Fonte (4000x3000 JPG) | JPG q90 | WebP q80 | AVIF q60 | AVIF vs JPG |
|---|---|---|---|---|
| Foto de praia (céu com gradiente) | 2,4 MB | 1,3 MB | 0,7 MB | −71% |
| Retrato (tons de pele) | 1,8 MB | 0,9 MB | 0,55 MB | −69% |
| Produto em fundo branco | 1,1 MB | 0,45 MB | 0,28 MB | −75% |
| Paisagem urbana (alto detalhe) | 3,2 MB | 1,8 MB | 1,1 MB | −66% |
| Fotografia de comida | 2,1 MB | 1,0 MB | 0,62 MB | −70% |
| Paisagem com textura | 2,7 MB | 1,6 MB | 1,0 MB | −63% |
| Logo / ilustração | 380 KB | 120 KB | 95 KB | −75% |
| Captura de tela (UI) | 540 KB | 210 KB | 165 KB | −69% |
| Moda (alto contraste) | 1,9 MB | 0,95 MB | 0,58 MB | −69% |
| Macro / detalhe da natureza | 2,5 MB | 1,4 MB | 0,85 MB | −66% |
| Média | 1,86 MB | 0,97 MB | 0,61 MB | −70% |
Para uma imagem típica, AVIF economiza ~70% sobre JPG, ~37% sobre WebP. As economias são massivas em escala: 100 fotos = 130 MB JPG, 60 MB WebP, 36 MB AVIF.
Verificação de realidade do suporte de navegador
| Navegador | WebP | AVIF | Participação de mercado (2026) |
|---|---|---|---|
| Chrome (desktop + Android) | 2014+ | Ago 2020+ | 65% |
| Edge | 2018+ | 2021+ | 5% |
| Firefox | 2019+ | Out 2021+ | 3% |
| Safari (iOS + macOS) | 2020 (14+) | Mar 2022 (16+) | 19% |
| Samsung Internet | 2019+ | 2021+ | 3% |
| Opera | 2014+ | 2020+ | 2% |
| IE antigo / IE Mode | Nunca | Nunca | <1% |
| Suporte combinado | ~99% | ~94% | n/d |
A lacuna de 6% do AVIF
Os 6% sem AVIF são majoritariamente: (a) Android < 7 ainda em uso em algumas regiões, (b) remanescentes corporativos antigos do Edge/IE, (c) WebViews embutidos em apps antigos. Sempre envie um fallback WebP, ele cobre todos eles.
Velocidade de codificação: a vantagem do WebP
A compressão AVIF é mais pesada porque o codec é mais complexo (derivado do HEVC). Em uma carga típica:
| Operação | WebP (libwebp) | AVIF (libaom) | Diferença |
|---|---|---|---|
| Foto 4 MP, q80 | 0,8s | 4,2s | 5x mais lento |
| Foto 4 MP, q60 | 0,6s | 3,5s | 5,8x mais lento |
| Foto 12 MP, q80 | 2,1s | 12s | 5,7x mais lento |
| 100 miniaturas (300x300) | 8s | 38s | 4,7x mais lento |
| Build de biblioteca de imagens (1000 imgs) | 14 min | 1h 12min | 5,1x mais lento |
Para builds de site estático isso está ok, codifica uma vez, serve para sempre. Para redimensionamento dinâmico (ex: usuários enviam avatares em tempo de requisição), o custo de 5 vezes é proibitivo.
Quando escolher WebP
Escolha só WebP quando
- Você gera imagens em tempo de requisição (redimensionamento dinâmico)
- CPU/tempo de build é restrito
- Você quer ferramentas mais simples (suporte mais amplo de bibliotecas)
- Seu CDN ainda não suporta AVIF
- Sua audiência tende a Android muito antigo (regiões com aparelhos antigos)
Escolha AVIF + fallback WebP quando
- Site estático com ativos pré-construídos
- Site rico em fotos (e-commerce, portfólio, notícias)
- Custos de banda importam (contas de CDN, usuários mobile)
- Core Web Vitals são críticos (peso de imagem é seu gargalo)
- Você pode gastar CPU em tempo de build
A cadeia de fallback na prática
O elemento HTML <picture> é a forma padrão de servir múltiplos formatos. O navegador escolhe o primeiro formato que entende.
<picture>
<source type="image/avif" srcset="/img/hero.avif" />
<source type="image/webp" srcset="/img/hero.webp" />
<img src="/img/hero.jpg" alt="Imagem hero" loading="lazy" />
</picture>Frameworks modernos geram isso automaticamente:
| Framework | Como |
|---|---|
| Astro | <Image src=... formats={['avif', 'webp']} /> |
| Next.js | next/image + config images.formats |
| Gatsby | gatsby-plugin-image com formats |
| Vite | Plugin vite-imagetools |
| Nuxt | @nuxt/image com array format |
| Hugo | Page resources + Resize + Convert |
Não envie AVIF sem WebP
Os 6% de usuários sem suporte a AVIF não veem uma "imagem quebrada", veem nada. A tag <picture> cai no <img> se todas as entradas <source> falharem. Sempre inclua WebP (ou JPG) como rede de segurança.
Mapeamento do controle de qualidade
O número que você coloca em q= para AVIF não mapeia para JPG/WebP. Equivalentes aproximados:
| Qualidade visual | JPG q | WebP q | AVIF q |
|---|---|---|---|
| Quase sem perdas | 95 | 95 | 80 |
| Visualmente sem perdas | 90 | 85 | 65 |
| Nítido em visualização normal | 85 | 80 | 60 |
| Aceitável | 75 | 70 | 50 |
| Compressão visível | 60 | 55 | 35 |
| Artefatos pesados | 40 | 35 | 20 |
Padrão para web: JPG 85, WebP 80, AVIF 60, todos produzem saída visualmente idêntica.
Dicas de codificação para melhores resultados
- Sempre codifique a partir do original (não de um JPG recodificado para WebP), ou você acumula perdas.
- Para fotos, use AVIF q60 / WebP q80, o sweet spot.
- Para gráficos com bordas nítidas, mude para WebP sem perdas ou fallback PNG. AVIF com perdas pode borrar linhas finas.
- Não se preocupe com AVIF para miniaturas abaixo de 100x100, a diferença de tamanho é mínima vs o custo de codificação.
- Remova metadados (EXIF, ICC) quando possível, economiza outros 10 a 30 KB por imagem.
E quanto ao JPEG XL?
JPEG XL (JXL) é um formato mais novo que alguns chamaram de “matador do AVIF” em 2022. Em 2026:
- Chrome removeu o suporte em 2023 (decisão controversa).
- Safari suporta (desde iOS 17).
- Firefox: atrás de uma flag.
Não vale a pena implantar em produção ainda. A história de suporte de navegador é incerta demais. Revisite em 2027.
Resumo
Para 90% dos sites em 2026:
- Pipeline de build codifica cada imagem em AVIF + WebP + JPG/PNG.
- Tag
<picture>no HTML serve a certa baseada no navegador. - JPG qualidade 85, WebP 80, AVIF 60 como padrões, visualmente idênticos.
- Pule AVIF apenas para imagens minúsculas ou caminhos de geração dinâmica.
- Meça com Core Web Vitals antes e depois, o peso da imagem deve cair ~70%.
Você pode converter seus ativos existentes agora mesmo com JPG para WebP, PNG para WebP, ou processar em lote via Converter Imagem. Tudo roda localmente, sem upload, sem servidor.