PatuLos gráficos no son fotos: dónde gana lo sin pérdida
“Convierte todo a AVIF” es buen consejo para fotografías y mal consejo, en silencio, para todo lo demás. Una captura de pantalla, un logo, una gráfica, una maqueta de interfaz, un dibujo lineal: son gráficos, no fotos, y los códecs con pérdida que hacen tan buenos a AVIF y JPEG en fotos son la herramienta equivocada para ellos.
Por qué los códecs con pérdida fallan en gráficos
JPEG, WebP con pérdida y AVIF están construidos para fotografías: degradados suaves, textura natural, sin bordes duros. Funcionan descartando el detalle de alta frecuencia que el ojo no echará en falta en una foto. Apúntalos a un gráfico y esa misma maquinaria se vuelve en tu contra:
- Halos en bordes nítidos. El texto y los iconos no son más que bordes duros. Las transformaciones con pérdida difuminan un halo de “ruido mosquito” alrededor de cada letra: el artefacto por el que JPEG es conocido desde los años 90, y que sobrevive en los códecs modernos en los bordes duros.
- Bandas en color plano. Un relleno sólido o un degradado limpio es justo lo que la cuantización por bloques convierte en escalones visibles.
- Pagas por difuminar, y luego pagas otra vez. Para ocultar esos artefactos subes la calidad, y un códec con pérdida forzado casi a lo sin pérdida en un gráfico suele acabar siendo más grande que uno sin pérdida construido para ello, y encima sigue sin ser exacto.
Un gráfico tiene pocos colores y estructura dura. Lo correcto es mantenerlo exacto y comprimir la redundancia, no tirar detalle.
Las cifras, en gráficos reales
Pasamos el conjunto de gráficos de nuestro benchmark (213 gráficos reales: logos, gráficas, interfaces, arte de color plano) por las herramientas construidas para ellos, midiendo el ahorro frente al PNG original:
| Herramienta | Tipo | Ahorro mediano vs PNG original |
|---|---|---|
| oxipng | sin pérdida (exacto byte a byte) | −29% |
| cwebp -lossless | sin pérdida (exacto byte a byte) | −49% |
| pngquant | paleta con pérdida (casi exacto) | −71% |
El WebP sin pérdida reduce estos gráficos aproximadamente a la mitad y cada píxel queda idéntico. oxipng reoptimiza el propio PNG sin cambiar de formato: seguro en cualquier caso. pngquant llega más lejos reduciendo la paleta; en arte de color plano el resultado es visualmente indistinguible, en una foto sería un desastre. Que es precisamente el punto: la herramienta tiene que encajar con el contenido.
La regla: clasificar primero, comprimir después
El error no es elegir WebP o elegir PNG. Es elegir un solo códec para todo. Un pipeline que sirve imágenes web bien tiene que mirar cada activo y decidir qué es antes de decidir cómo comprimirlo:
- Fotografía → AVIF/WebP con pérdida, calidad ajustada a una puntuación perceptual (ver nuestras cifras de AVIF frente a WebP frente a JPEG).
- Gráfico con una región fotográfica (una captura de una foto) → el camino con pérdida aún puede ganar.
- Gráfico de color plano, logo, gráfica, arte lineal → sin pérdida, y en un formato que el gráfico realmente necesita.
Esto es lo que hace Patu: clasifica cada imagen y la enruta. Un gráfico se mantiene sin pérdida, recodificado de forma exacta, no difuminado en un formato con pérdida que resulta a la vez más grande y peor. Una foto recibe la búsqueda con pérdida ajustada a calidad. Mismo endpoint, tratamiento opuesto, porque son problemas opuestos.
El consejo inicial se mantiene con una palabra añadida: convierte tus fotos a AVIF. Convierte tus gráficos a la forma sin pérdida más pequeña. Enviar ambos por el mismo pipeline es cómo acabas con logos borrosos y archivos más pesados a la vez.
Método y datos: el harness de benchmark de Patu sobre la categoría de gráficos (213 gráficos reales); los ahorros son la reducción mediana frente al PNG original, por herramienta. oxipng y WebP sin pérdida son exactos byte a byte; pngquant es reducción de paleta con pérdida, casi exacta en contenido de color plano.