AVIF vs WebP vs JPEG: números reais em qualidade equivalente
A maioria das afirmações do tipo “AVIF é 50% menor que JPEG” compara um JPEG em qualidade 75 com um AVIF em outro ajuste qualquer. Isso não é uma comparação: um -q 75 em um codificador não é a mesma imagem que um -q 75 em outro. A única pergunta honesta é: em uma qualidade perceptual fixa, quantos bytes cada formato precisa?
Nós medimos isso. Não em um punhado de imagens de destaque, mas em mais de 1.900 fotografias reais, com os codificadores de verdade, avaliadas por uma métrica perceptual em vez de um número de qualidade chutado.
Como medimos
- Imagens: o conjunto de fotos do nosso benchmark público, 1.998 fotografias reais, em sua maioria originais do Wikimedia Commons, cobrindo retratos, paisagens, texturas, pouca luz e detalhe fino. Não é um recorte favorável.
- Codificadores, cada um a ferramenta padrão: JPEG via libjpeg-turbo, WebP via cwebp (libwebp), AVIF via avifenc (libaom) e JPEG XL via cjxl (libjxl) como bônus.
- A métrica: ssimulacra2, uma pontuação de qualidade perceptual em que quanto maior, mais próximo do original. Ela se correlaciona com o que o olho percebe muito melhor que PSNR ou um número de qualidade bruto. 90+ é indistinguível da fonte; ~85 é alta qualidade; ~80 é bom.
- O método: para cada imagem, codificamos em cada formato ao longo de uma grade completa de qualidade, avaliamos cada saída com ssimulacra2 e então interpolamos o número de bytes que o formato precisa para atingir uma pontuação alvo. Essa é a comparação justa: cada formato é medido pela mesma qualidade percebida, e lemos o preço em bytes. Reportamos a mediana entre as imagens em que todos os formatos de fato atingem o alvo.
Esse último ponto importa: comparar cwebp -q 80 com avifenc -q 80 não significa nada. Comparar “o WebP que parece tão bom quanto o AVIF” é o jogo todo.
Os números
Em ssimulacra2 85 (alta qualidade, difícil de diferenciar do original), nas 548 fotos em que os quatro formatos atingem esse nível:
| Formato | Mediana por foto | vs JPEG |
|---|---|---|
| JPEG (libjpeg-turbo) | 833 KB | — |
| WebP | 708 KB | −16% |
| AVIF | 605 KB | −28% |
| JPEG XL | 553 KB | −33% |
Na mesma qualidade, o AVIF é 16% menor que o WebP, e ambos superam o JPEG com folga.
Em ssimulacra2 80 (boa qualidade, um alvo comum na web), em 1.884 fotos:
| Formato | Mediana por foto | vs JPEG |
|---|---|---|
| JPEG | 510 KB | — |
| WebP | 471 KB | −11% |
| AVIF | 368 KB | −29% |
| JPEG XL | 351 KB | −32% |
A vantagem do AVIF se amplia em 80 (−29% vs JPEG, −21% vs WebP): ele mantém o detalhe em taxas de bits mais baixas, ponto em que JPEG e WebP começam a se desfazer.
Esses números batem com a literatura independente: o AVIF ficar cerca de 25 a 30% abaixo do JPEG em qualidade equivalente é um resultado bem replicado. O que esta medição acrescenta é que ela foi feita de forma perceptual, em qualidade equivalente, em um conjunto de fotos grande e sem seleção prévia.
As ressalvas, ditas sem rodeios
- A referência de JPEG é o libjpeg-turbo, o JPEG que praticamente tudo usa hoje. Codificadores JPEG modernos (mozjpeg, jpegli) fecham parte da diferença mantendo compatibilidade total com JPEG; se você só pode servir JPEG, troque para um desses antes de qualquer outra coisa.
- O WebP tem um teto de qualidade na prática. Seu codificador com perdas encontra um limite: em fotos de alto detalhe, ele tem dificuldade até para alcançar ssimulacra2 90. Isso é um limite real, não uma escolha de ajuste.
- O JPEG XL é o menor aqui, mas você não pode entregá-lo aos navegadores. Nenhum navegador importante o habilita por padrão em 2026. Ele está incluído como o teto técnico, não como uma recomendação de uso em produção.
- O AVIF custa tempo de codificação. O avifenc é bem mais lento que o cwebp ou o cjpeg. Isso é aceitável para ativos armazenados/servidos por CDN, menos para codificação sob demanda em uma única requisição, e é exatamente por isso que um serviço com qualidade alvo faz cache.
O que isso significa na prática
Sirva AVIF com fallback para WebP e JPEG, e mire em uma pontuação perceptual, não em um número de qualidade. Um -q fixo entrega qualidade inconsistente entre imagens: algumas comprimidas demais e visivelmente ruins, outras desperdiçando bytes. Buscar a qualidade de codificação de cada imagem para atingir uma pontuação ssimulacra2 alvo é o que dá tanto o menor tamanho quanto uma qualidade que você de fato pode prometer.
É isso que o Patu faz: busca a qualidade de codificação por imagem para atingir um alvo perceptual, e retorna AVIF e WebP com fallback para JPEG, atrás de uma CDN. Os números acima são o motivo de o padrão ser AVIF em primeiro lugar.
curl -X POST "https://patu.dev/v1/compress?formats=avif,webp,fallback&target=85" \
-H "X-Api-Key: $PATU_KEY" \
--data-binary @photo.jpg -o photo.avif
Você informa uma qualidade alvo; ele devolve o menor arquivo naquela qualidade, nos formatos que um navegador de fato consegue usar.
Método e dados: o harness de benchmark do Patu sobre a categoria de fotos; ssimulacra2 via a implementação rust-av; codificadores libjpeg-turbo, libwebp, libaom, libjxl em suas versões lançadas. Os tamanhos são a mediana entre as fotos em que todo formato atinge a pontuação alvo.