Gráficos não são fotos: onde o lossless vence
“Converta tudo para AVIF” é um bom conselho para fotografias e um conselho silenciosamente ruim para tudo o mais. Um screenshot, um logo, um gráfico, um mockup de interface, um desenho de linha: isso são gráficos, não fotos, e os codecs com perdas que tornam AVIF e JPEG tão bons em fotos são a ferramenta errada para eles.
Por que codecs com perdas falham em gráficos
JPEG, WebP com perdas e AVIF são construídos para fotografias: gradientes suaves, textura natural, sem bordas duras. Eles funcionam descartando detalhe de alta frequência que o olho não vai notar em uma foto. Aponte-os para um gráfico e essa mesma engrenagem se volta contra você:
- Anelamento em bordas nítidas. Texto e ícones são só bordas duras. Transformações com perdas espalham um halo de “ruído de mosquito” ao redor de cada letra, o artefato pelo qual o JPEG é conhecido desde os anos 1990, e que sobrevive em codecs modernos nas bordas duras.
- Faixas em cor sólida. Um preenchimento sólido ou um gradiente limpo é exatamente o que a quantização em blocos transforma em degraus visíveis.
- Você paga para borrar, e paga de novo. Para esconder esses artefatos, você sobe a qualidade, e um codec com perdas forçado a algo quase sem perdas em um gráfico costuma ficar maior que um codec sem perdas feito para isso, e ainda assim sem ser exato.
Um gráfico tem poucas cores e estrutura rígida. A jogada certa é mantê-lo exato e comprimir a redundância, não descartar detalhe.
Os números, em gráficos reais
Rodamos o conjunto de gráficos do nosso benchmark, 213 gráficos reais (logos, gráficos, UI, arte em cor sólida), pelas ferramentas feitas para eles, medindo a economia contra o PNG original:
| Ferramenta | Tipo | Economia mediana vs PNG original |
|---|---|---|
| oxipng | sem perdas (byte-exato) | −29% |
| cwebp -lossless | sem perdas (byte-exato) | −49% |
| pngquant | paleta com perdas (quase exato) | −71% |
O WebP sem perdas corta esses gráficos praticamente pela metade e todo pixel fica idêntico. O oxipng reotimiza o próprio PNG sem trocar de formato: seguro em qualquer lugar. O pngquant vai mais longe reduzindo a paleta; em arte de cor sólida o resultado é visualmente indistinguível, em uma foto seria um desastre. E esse é o ponto: a ferramenta tem que combinar com o conteúdo.
A regra: classifique primeiro, comprima depois
O erro não é escolher WebP ou escolher PNG. É escolher um único codec para tudo. Um pipeline que entrega bem imagens para a web precisa olhar cada ativo e decidir o que ele é antes de decidir como comprimi-lo:
- Fotografia → AVIF/WebP com perdas, com qualidade mirada em uma pontuação perceptual (veja nossos números de AVIF vs WebP vs JPEG).
- Gráfico com uma região fotográfica (um screenshot de uma foto) → o caminho com perdas ainda pode vencer.
- Gráfico de cor sólida, logo, gráfico, arte em linha → sem perdas, permanecendo em um formato que o gráfico realmente precisa.
É isso que o Patu faz: classifica cada imagem e a encaminha. Um gráfico é mantido sem perdas, recodificado com exatidão, não borrado em um formato com perdas que fica maior e pior ao mesmo tempo. Uma foto recebe a busca com perdas mirada em qualidade. Mesmo endpoint, tratamento oposto, porque são problemas opostos.
O conselho de sempre sobrevive com uma palavra a mais: converta suas fotos para AVIF. Converta seus gráficos para a menor forma sem perdas. Mandar os dois pelo mesmo cano é como você acaba com logos borrados e arquivos mais pesados ao mesmo tempo.
Método e dados: o harness de benchmark do Patu sobre a categoria de gráficos (213 gráficos reais); as economias são a redução mediana contra o PNG original, por ferramenta. oxipng e WebP sem perdas são byte-exatos; pngquant é redução de paleta com perdas, quase exata em conteúdo de cor sólida.