AVIF tem suporte maduro nos navegadores: entenda quando migrar do WebP

Um post de opinião sobre escassez de hardware reacendeu o debate sobre adotar AVIF em vez de WebP. O suporte de navegador deixou de ser obstáculo há anos; a decisão real agora é de custo e de pipeline.

O gatilho: um post de blog reacende a discussão

Em 6 de novembro de 2026, o desenvolvedor Michael Mitchell publicou um texto de opinião perguntando por que provedores de hospedagem, redes sociais como Mastodon e Bluesky, e fabricantes de celular não adotam de forma mais ampla o AVIF para imagens. O argumento central: com o custo de armazenamento subindo ao longo de 2026, formatos mais eficientes deixaram de ser luxo e viraram necessidade.

Mitchell cita a Hetzner como exemplo concreto: a provedora de hospedagem aumentou preços várias vezes em 2026, atribuindo o movimento ao custo crescente de hardware, amplificado pela demanda por infraestrutura de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →. Nesse cenário, ele defende que, se o YouTube já estaria se preparando para adotar o AV2 (sucessor do AV1) possivelmente em 2027, segundo o próprio texto, o resto da internet também deveria olhar com mais atenção para os formatos de imagem já disponíveis.

Para quem decide o pipeline de imagens de um produto, a pergunta é prática, não filosófica: o suporte de navegador já é maduro o suficiente para abandonar de vez o JPEG e, mais importante, o WebP?

Suporte em navegador já não é mais o obstáculo

A resposta curta é sim, há alguns anos. O AVIF, formato baseado no codec de vídeo AV1, já é suportado nativamente pelos principais navegadores modernos, incluindo os baseados em Chromium, o Firefox e o Safari, historicamente o mais lento a adotar novos formatos de imagem, mas que também já acompanhou o movimento.

Em novembro de 2026, isso significa que praticamente toda a base instalada de navegadores modernos decodifica AVIF nativamente, sem polyfill nem flag experimental. É o cenário oposto ao que o WebP enfrentou em seus primeiros anos, quando o Safari era o gargalo que forçava a manter fallback em JPEG por muito mais tempo do que qualquer time de front-end↳Front-end60 conteúdosFront-end em larga escala: quando seu projeto vira um Frankenstein (e como evitar)Dev (Back & Front) · mar 2026Build e bundling no front-end: 7 decisões que impactam performance de verdadeDev (Back & Front) · abr 2026Como modelar APIs pensando no front-end: 8 práticas para evitar retrabalho entre timesDev (Back & Front) · abr 2026Ver tudo em Dev (Back & Front) → gostaria.

Em resumo: o risco técnico de adotar AVIF como formato primário já caiu a praticamente zero; o que resta decidir é se o ganho de compressão compensa o custo de encoding no seu pipeline.

AVIF vs. WebP: o que muda na prática

Mitchell argumenta que o AVIF costuma comprimir melhor que o WebP mantendo qualidade de imagem comparável, o que na prática significa arquivos menores sem alterar a aparência percebida. É uma leitura compartilhada por boa parte da comunidade de performance web, embora o ganho varie conforme o conteúdo da imagem: fotos com muito detalhe tendem a se beneficiar mais do que ilustrações com poucas cores, em que PNG e WebP sem perdas ainda competem bem.

A contrapartida, reconhecida pelo próprio autor do post, é o custo de CPU no encoding: converter uma imagem para AVIF é mais pesado do que gerar um WebP equivalente, o que pesa especialmente para serviços que fazem transcodificação sob demanda, em tempo real, para milhões de uploads diários.

Isso leva à sugestão central do texto: em vez de forçar hospedagens e redes sociais a reencodar tudo no upload, por que não incentivar quem sobe a imagem a já convertê-la antes, usando o próprio hardware, preservando o arquivo original em vez de reconvertê-lo depois para um formato menos eficiente? Essa divisão de trabalho já é prática comum em pipelines de build de front-end; só não chegou às redes sociais.

Como isso aparece no dia a dia de quem constrói

Para times de front-end e de produto, a decisão de adotar AVIF geralmente passa por três frentes:

• Build time, não runtime. Gerar as variantes AVIF durante o build, ou no momento do upload para um bucket de assets, evita pagar o custo de CPU a cada requisição. Já existem bibliotecas e ferramentas de conversão de imagem, tanto em Node.js quanto de linha de comando e web, que oferecem suporte a encoding de AVIF, o que permite gerar essas variantes sem depender de reencoding sob demanda.
• CDN com negociação de conteúdo. Serviços de otimização de imagem com CDN costumam oferecer entrega automática no formato mais adequado para quem envia o cabeçalho Accept: image/avif, caindo para WebP ou JPEG quando o cliente não suporta. Isso tira do time de front-end a obrigação de manter três cópias de cada imagem manualmente.
• Fallback explícito, quando não há CDN inteligente. Sem um serviço que negocie o formato automaticamente, o caminho é o elemento <picture>:

<picture>
  <source srcset="foto.avif" type="image/avif">
  <source srcset="foto.webp" type="image/webp">
  <img src="foto.jpg" alt="Descrição da imagem" loading="lazy">
</picture>

O navegador escolhe a primeira fonte que suporta, de cima para baixo, e cai para o <img> em último caso. É o jeito mais simples de servir AVIF hoje sem abrir mão de compatibilidade com navegadores antigos ou crawlers que ainda não decodificam o formato.

O efeito em Core Web Vitals

Imagem costuma ser, em sites de conteúdo e e-commerce↳E-commerce21 conteúdosECBR Club: novo espaço para devs se conectarem ao ecossistema de e-commerceDev (Back & Front) · mai 2025TOTVS anuncia joint venture com VTEXMarketing Tech · mai 2019Jovens da Brasilândia recebem formação gratuita em tecnologiaGestão Dev & TI · jul 2025Ver tudo em Marketing Tech →, o maior contribuinte para o peso da página e, com frequência, o elemento que define o Largest Contentful Paint (LCP). Trocar o hero de uma página ou o banner de produto por uma versão em AVIF, tipicamente menor que o equivalente em WebP dependendo do conteúdo da imagem, tende a reduzir o LCP sem mexer em uma linha de JavaScript.

Essa é a parte do argumento de Mitchell que menos exige polêmica: menos bytes trafegando chegam mais rápido, custam menos banda ao provedor e pontuam melhor nas métricas que o Google usa para avaliar experiência de página. O ponto em disputa é outro: vale forçar essa migração em escala, via plataforma, ou cada site decide isso sozinho, no seu próprio ritmo?

Nem todo mundo concorda que o problema é esse

A seção de comentários do post expõe o contraponto mais direto ao argumento de Mitchell. Um leitor anônimo rebateu que armazenamento continua barato, citando preços por volta de 25 dólares por terabyte em discos à vista, suficientes para guardar muito vídeo independentemente do formato, e que o AV1 e o futuro AV2 do YouTube existem para economizar banda, não espaço em disco.

Mitchell respondeu reconhecendo a diferença entre banda e armazenamento, mas insistindo que o problema não desaparece: SSDs NVMe, segundo ele, continuam caros e escassos em 2026.

Boa conversa, mas acho que você está perdendo o ponto mais amplo do meu post. O AVIF ajuda, mas não elimina a escassez de hardware nem o aumento de preços.

Michael Mitchell, autor do blog michaelponders.comGood conversation, but I think you're missing the broader point of my post. AVIF helps, but it doesn't eliminate these hardware shortages or rising prices.

Outro comentário propõe uma alternativa ao próprio AVIF: migrar para JPEG XL, que teria nível de compressão parecido, mas com mais recursos, como decodificação progressiva, compatibilidade retroativa com arquivos JPEG antigos e mais opções de metadados. É um lembrete de que a disputa de formatos de imagem não tem um único vencedor consolidado, mesmo com o AVIF em vantagem de suporte hoje.

O que fica para quem decide o pipeline agora

Suporte de navegador deixou de ser desculpa para não usar AVIF: essa parte da equação está resolvida há alguns anos. A decisão real, em 2026, é de custo e de processo: quem converte a imagem (o usuário, o build, a CDN), em que momento (upload ou build time), e se vale manter o WebP como meio-termo para os casos em que o custo de CPU do AVIF ainda pesa. JPEG XL segue como alternativa de nicho, sem o mesmo nível de suporte de navegador que o AVIF já conquistou, mas vale acompanhar enquanto a disputa não se encerra.

Fonte: Hacker News