WebP vs AVIF em 2026: suporte, tamanho e código de fallback

WebP vs AVIF em 2026: sirva AVIF primeiro com um fallback em WebP ou JPEG quando puder codificar antecipadamente, e use só WebP quando precisar de codificação rápida ou de um formato único e simples. Os dois são Baseline amplamente disponíveis em outubro de 2026, então o suporte dos navegadores já não decide a escolha. As imagens WebP têm limite de 16383 × 16383 px (FAQ do WebP), o que só importa para panorâmicas muito grandes. O AVIF gerou arquivos menores com a mesma qualidade visual nos testes publicados pelo web.dev e suporta HDR; o WebP codifica muito mais rápido (web.dev, atualização de 2023). A diferença em bytes depende da imagem, então meça com as suas próprias fotos antes de decidir.

WebP vs AVIF em resumo

Os dois formatos se diferenciam mais em custo e recursos do que em suporte. Os dados de suporte vêm do web-features 3.44.0 (22 de outubro de 2026); as demais linhas vêm dos documentos do WebP do Google e do web.dev:

O AVIF passou para «recentemente disponível» no Baseline em 25 de janeiro de 2024, quando o Edge 121 o adicionou, e para «amplamente disponível» 30 meses depois, em 25 de julho de 2026. Se as suas estatísticas ainda mostrarem uma parcela relevante de navegadores anteriores ao Safari 16 ou ao Edge 121, mantenha um fallback.

Tamanho do arquivo: qual pesa menos?

O AVIF saiu menor nas comparações publicadas pelo web.dev, mas a diferença varia tanto que qualquer porcentagem isolada engana. O número do Google para o WebP é de 25 a 34% menor que o JPEG. O artigo do web.dev sobre AVIF relata «economia superior a 50% em relação ao JPEG», ressalvando que a economia exata depende do conteúdo, das configurações de codificação e da meta de qualidade; e a atualização de 2023 do web.dev citava que a Imgix via 60% de economia em relação ao JPEG e 35% em relação ao WebP. Esses números vêm de conjuntos de imagens diferentes, então meça as suas.

Como os resultados dependem do conteúdo, teste pelo menos três tipos de imagem do seu próprio site: uma foto grande, uma captura de tela ou gráfico com texto e uma miniatura pequena. Codifique cada origem em alguns níveis de qualidade e compare o tamanho do arquivo no nível de qualidade que você aceita, usando cwebp e avifenc da libavif:

# WebP, qualidade 75
cwebp -q 75 hero.jpg -o hero.webp

# AVIF, qualidade 60 como valor inicial para ajustar, usando 8 threads
avifenc -q 60 --jobs 8 hero.jpg hero.avif

ls -l hero.*

O Squoosh faz o mesmo no navegador, com um controle deslizante de comparação lado a lado, mais rápido para algumas poucas imagens.

Velocidade de codificação e ferramentas

O WebP codifica mais rápido, e isso importa quando as imagens são geradas sob demanda. A atualização de 2023 do web.dev diz que o AVIF é o codificador mais lento entre os comuns para uso em tempo real, mas é competitivo com o esforço padrão quando a codificação é feita antecipadamente. O avifenc tem uma configuração --speed de 0 (o mais lento) a 10 (o mais rápido), com padrão 6; velocidades maiores custam eficiência de compressão. O web.dev relata codificação cerca de 5 vezes mais rápida com 8 threads, sem descrever o teste.

Na prática:

• Pipelines de build (sites estáticos, next/image com cache, um CDN de imagens com cache) lidam bem com AVIF, porque cada imagem é codificada uma única vez.
• O redimensionamento sob demanda sem cache é onde a velocidade do WebP compensa.
• Uploads no CMS: confirme que o seu CMS aceita AVIF antes de mudar o pipeline. O WordPress aceita uploads de AVIF desde a versão 6.5 (2024), mas só se a biblioteca Imagick ou GD do servidor suportar; em Ferramentas > Saúde do site > Informações > Manipulação de mídia você vê se isso acontece (blog central do WordPress).

Sirva os dois com um fallback em picture

Use o elemento <picture> para que cada navegador escolha o primeiro formato que suporta, de cima para baixo, e recorra ao <img>:

<picture>
  <source type="image/avif" srcset="hero-800.avif 800w, hero-1600.avif 1600w" sizes="100vw">
  <source type="image/webp" srcset="hero-800.webp 800w, hero-1600.webp 1600w" sizes="100vw">
  <img src="hero-800.jpg"
       srcset="hero-800.jpg 800w, hero-1600.jpg 1600w" sizes="100vw"
       width="1600" height="900" alt="Product on a desk">
</picture>

Três detalhes importam no celular:

• width e height no <img> permitem que o navegador reserve espaço antes de o arquivo chegar, o que evita um deslocamento de layout quando a imagem carrega.
• srcset com sizes faz um celular de 390 px de largura com densidade de pixels 2 escolher o arquivo de 800w em vez do de 1600w (390 × 2 = 780 pixels físicos). Um celular com densidade 3 precisa de 1170 pixels físicos e pega o arquivo de 1600w. O dimensionamento de imagens para celular é tratado em como tornar um site compatível com celulares.
• alt, loading e fetchpriority vão no <img>, nunca no <source>.

Para fundos em CSS, image-set() com type() faz o mesmo trabalho e é Baseline amplamente disponível desde março de 2026:

.hero {
  background-image: image-set(
    url("hero.avif") type("image/avif"),
    url("hero.webp") type("image/webp"),
    url("hero.jpg") type("image/jpeg")
  );
}

Negociação de conteúdo em um CDN

Alguns CDNs de imagem escolhem o formato pelo cabeçalho Accept da requisição, em vez de usar <picture> (confira a documentação do seu CDN). Isso tem uma armadilha no iPhone. Segundo a lista de valores Accept padrão do MDN (atualizada em outubro de 2026), o Chrome e o Edge 121+ enviam image/avif,image/webp,... e o Firefox também envia image/avif, enquanto o valor do Safari começa com image/webp e não menciona AVIF. Um CDN que só lê Accept vai, portanto, enviar WebP para o Safari, mesmo o Safari decodificando AVIF desde a 16.4. Se você quer AVIF no iPhone, use <picture> ou verifique como o seu CDN detecta o Safari.

E o JPEG XL?

O JPEG XL ainda não é Baseline, então precisa de fallback. Em outubro de 2026 ele é suportado pelo Safari 17+ (apenas imagens estáticas), Chrome 155, Firefox 158 (lançado em 13 de outubro de 2026, segundo as suas notas de versão) e Edge 155 (lançado em 8 de outubro de 2026, segundo as suas notas de versão). O Samsung Internet não o suporta, e o MDN browser-compat-data 8.1.7 ainda marca o Edge como não suportado, então o web-features não o lista como Baseline (MDN browser-compat-data). Ele pode ser adicionado como um terceiro <source> acima do AVIF para os navegadores que o suportam, ao custo de mais uma codificação por imagem.

Quando o JPEG ainda serve

Um JPEG bem comprimido é uma escolha razoável quando:

• você não pode mudar o marcado nem o build, e o CMS ou o CDN não converte formatos para você;
• a imagem é uma miniatura pequena, em que os bytes economizados são de poucos quilobytes;
• o arquivo deve ser baixado, enviado por e-mail ou editado pelos usuários, onde o JPEG funciona em todas as ferramentas;
• você já serve o tamanho certo para cada dispositivo e a página passa na auditoria de imagens.

No Lighthouse 13 (outubro de 2025), a antiga auditoria «Servir imagens em formatos modernos» foi incorporada ao insight de Entrega de imagens (Chrome for Developers). Trate-a como um indicativo dos maiores ganhos da página; verifique as dimensões das imagens antes do formato. Como executar e ler a auditoria está no guia de auditoria mobile com Lighthouse.

Confira o resultado em uma página de tamanho de celular

Depois de trocar os formatos, verifique duas coisas: se os arquivos certos carregam e se o layout não se moveu. O painel Rede do DevTools mostra o formato e o tamanho que cada imagem realmente usou; filtre por Img e veja a coluna Type. Para velocidade em dados de campo, use os métodos do guia de teste de velocidade em celulares.

Para o layout, abra a página em larguras de celular. O Mobile View Extension recarrega a aba com o user agent, o tamanho de tela e a densidade de pixels de um celular, então você vê o layout mobile com a versão real da página. Ele mostra apenas o layout: não mede o peso das imagens nem o tempo de carregamento, e é renderizado com o motor do Chrome de desktop, então a escolha de formato do Safari precisa ser conferida no Safari.

Perguntas frequentes

O AVIF é melhor que o WebP?

Em tamanho de arquivo, sim nos testes publicados: o AVIF gerou arquivos menores que o JPEG e o WebP com qualidade visual semelhante nas comparações do web.dev, e suporta HDR. Confira com as suas imagens, porque a diferença depende do conteúdo. O WebP é melhor quando a velocidade de codificação importa ou quando as suas ferramentas não lidam com AVIF.

Todos os navegadores suportam AVIF em 2026?

Todos os navegadores principais atuais suportam. O AVIF é Baseline amplamente disponível desde 25 de julho de 2026, com suporte desde o Chrome 85, Firefox 113, Safari 16.4 (Safari iOS 16.1) e Edge 121.

Ainda devo usar WebP?

Sim, como fallback depois do AVIF, ou como único formato moderno se o seu pipeline codifica imagens sob demanda. O WebP é suportado em todos os navegadores principais desde o Safari 14, em 2020.

O AVIF prejudica o SEO?

Não. A Pesquisa do Google inclui o AVIF entre seus formatos de imagem suportados, ao lado de WebP, JPEG, PNG, GIF, BMP e SVG (Google Search Central, atualizado em março de 2026). A página não descreve o formato como um sinal de ranqueamento.