AVIF frente a WebP frente a JPEG: cifras reales a igualdad de calidad

La mayoría de afirmaciones del tipo “AVIF pesa un 50% menos que JPEG” comparan un JPEG a calidad 75 con un AVIF en algún otro ajuste. Eso no es una comparación: un -q 75 en un codificador no es la misma imagen que un -q 75 en otro. La única pregunta honesta es: a calidad perceptual fija, cuántos bytes necesita cada formato?

Lo medimos. No en un puñado de imágenes destacadas, sino en más de 1.900 fotografías reales, con los codificadores reales, puntuadas por una métrica perceptual en lugar de un número de calidad estimado.

Cómo lo medimos

• Imágenes: el conjunto de fotos de nuestro benchmark público — 1.998 fotografías reales, en su mayoría originales de Wikimedia Commons, que abarcan retratos, paisajes, texturas, poca luz y detalle fino. No es un caso seleccionado a medida.
• Codificadores, cada uno la herramienta estándar: JPEG vía libjpeg-turbo, WebP vía cwebp (libwebp), AVIF vía avifenc (libaom), y JPEG XL vía cjxl (libjxl) como extra.
• La métrica: ssimulacra2, una puntuación de calidad perceptual donde un valor más alto significa más cercano al original. Correlaciona con lo que ve el ojo mucho mejor que PSNR o un número de calidad a secas. 90 o más es indistinguible del original; ~85 es alta calidad; ~80 es buena.
• El método: para cada imagen, codificamos cada formato en toda una rejilla de calidades, puntuamos cada salida con ssimulacra2 y luego interpolamos el número de bytes que ese formato necesita para alcanzar una puntuación objetivo. Esta es la comparación justa: cada formato se mide con la misma calidad percibida, y leemos el precio en bytes. Reportamos la mediana entre las imágenes donde los cuatro formatos alcanzan realmente el objetivo.

Ese último punto importa: comparar cwebp -q 80 con avifenc -q 80 no significa nada. Comparar “el WebP que se ve tan bien como el AVIF” es todo el juego.

Las cifras

En ssimulacra2 85 (alta calidad, difícil de distinguir del original) — las 548 fotos donde los cuatro formatos lo alcanzan:

A igual calidad, AVIF pesa un 16% menos que WebP, y ambos superan a JPEG con holgura.

En ssimulacra2 80 (buena calidad, un objetivo web habitual) — en 1.884 fotos:

La ventaja de AVIF se amplía en 80 (−29% vs JPEG, −21% vs WebP): conserva el detalle a tasas de bits más bajas, donde JPEG y WebP empiezan a desmoronarse.

Estas cifras coinciden con la literatura independiente: que AVIF quede aproximadamente un 25-30% por debajo de JPEG a calidad equivalente es un resultado bien replicado. Lo que aporta esta prueba es que está medido de forma perceptual, a igual calidad, en un conjunto de fotos grande y sin selección previa.

Las salvedades, dichas sin rodeos

• La base de JPEG es libjpeg-turbo, el JPEG que usa casi todo hoy. Los codificadores JPEG modernos (mozjpeg, jpegli) cierran parte de la brecha manteniendo compatibilidad total con JPEG: si solo puedes servir JPEG, cambia a uno de esos antes que a cualquier otra cosa.
• WebP tiene un techo de calidad en la práctica. Su codificador con pérdida tiene un límite: en fotos de mucho detalle le cuesta llegar siquiera a ssimulacra2 90. Es un límite real, no una decisión de ajuste.
• JPEG XL es el más pequeño aquí, pero no puedes servirlo a los navegadores. Ningún navegador importante lo activa por defecto en 2026. Se incluye como techo técnico, no como recomendación de despliegue.
• AVIF cuesta tiempo de codificación. avifenc es mucho más lento que cwebp o cjpeg. Eso está bien para activos almacenados o servidos por CDN, menos para codificación al vuelo por petición única: exactamente por eso un servicio con calidad como objetivo usa caché.

Qué significa esto en la práctica

Sirve AVIF con reserva en WebP y JPEG, y apunta a una puntuación perceptual, no a un número de calidad. Un -q fijo entrega calidad inconsistente entre imágenes: unas sobrecomprimidas y visiblemente mal, otras innecesariamente grandes. Buscar la calidad del codificador imagen por imagen para alcanzar una puntuación ssimulacra2 objetivo es lo que te da a la vez los bytes más pequeños y una calidad que puedes prometer de verdad.

Eso es lo que hace Patu: busca la calidad del codificador por imagen para alcanzar un objetivo perceptual, y devuelve AVIF y WebP con reserva en JPEG, detrás de una CDN. Las cifras de arriba son la razón de que el valor por defecto sea AVIF primero.

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

Le das una calidad objetivo; te devuelve el archivo más pequeño a esa calidad, en los formatos que un navegador puede usar de verdad.

Método y datos: el harness de benchmark de Patu sobre la categoría de fotos; ssimulacra2 vía la implementación de rust-av; codificadores libjpeg-turbo, libwebp, libaom, libjxl en sus versiones publicadas. Las cifras son la mediana entre fotos donde cada formato alcanza la puntuación objetivo.