WebP vs JPEG: comparación con datos reales

Los datos principales: qué dicen los benchmarks

La cifra más citada proviene de los propios benchmarks de Google publicados cuando se introdujo WebP en 2010, confirmados posteriormente por estudios independientes: a calidad visual equivalente, WebP produce archivos entre un 25 y un 35% más pequeños que JPEG. Esta ventaja se aplica a la codificación con pérdida, que es el modo utilizado para contenido fotográfico en la web.

En modo sin pérdida, WebP supera a PNG en un 25–34% según el tipo de imagen, aunque esa comparación queda fuera del ámbito de JPEG, ya que JPEG es un formato exclusivamente con pérdida.

Estas cifras son promedios. Los resultados reales varían según el tipo de contenido, el nivel de calidad objetivo y la versión del codificador. La tabla a continuación muestra los resultados de cinco imágenes de prueba representativas codificadas a calidad visualmente equivalente (SSIM ≥ 0,95) usando cjpeg (MozJPEG 4.1) y cwebp (libwebp 1.4):

Cómo funciona WebP frente a JPEG

Entender por qué WebP genera archivos más pequeños requiere una comprensión básica de ambos codecs.

JPEG fue estandarizado en 1992. Divide la imagen en bloques de 8×8 píxeles, aplica una Transformada Discreta del Coseno (DCT) para convertir los datos espaciales en datos de frecuencia y luego usa la codificación de Huffman (una forma de codificación entropía) para comprimir los coeficientes resultantes. Este enfoque por bloques es la razón por la que los artefactos JPEG aparecen como cuadrados visibles de 8×8 a ajustes de calidad bajos: cada bloque se comprime de forma independiente, sin referencia a los bloques vecinos.

WebP fue desarrollado por Google basándose en el codec de vídeo VP8 (publicado en 2010). Para la codificación con pérdida, utiliza codificación predictiva: los valores de cada bloque se predicen a partir de los bloques vecinos que ya han sido codificados, y solo se almacena el residuo (error de predicción). Esta dependencia entre bloques permite a WebP representar gradientes suaves y texturas repetidas de forma mucho más eficiente que JPEG. Los residuos se comprimen después mediante codificación aritmética, más eficiente que la codificación de Huffman de JPEG, a costa de una complejidad de codificador/decodificador ligeramente mayor.

El resultado neto: los bloques WebP pueden referenciar hasta tres bloques adyacentes ya decodificados para la predicción, mientras que JPEG no puede. En contenido fotográfico real, este enfoque predictivo captura aproximadamente entre un 25 y un 35% más de información por bit.

Métricas de calidad: SSIM y DSSIM explicados

Comparar imágenes comprimidas únicamente por tamaño de archivo es engañoso si la calidad difiere. Las dos métricas más utilizadas en el trabajo profesional con pipelines de imagen son:

• SSIM (Índice de Similitud Estructural): Mide simultáneamente la luminancia, el contraste y la información estructural. Una puntuación de 1,0 significa que las imágenes son idénticas. Los valores superiores a 0,95 indican una calidad excelente; los valores por debajo de 0,85 suelen ser visibles para un espectador ocasional.
• DSSIM (Disimilitud): Simplemente 1 − SSIM (o una variante de ello). Cuanto más bajo, mejor. Un DSSIM por debajo de 0,005 se considera excelente; por encima de 0,02 sugiere artefactos visibles.

Al comparar WebP y JPEG, compara siempre a SSIM igual, no a igual ajuste de calidad del codificador. Un JPEG con calidad 80 y un WebP con calidad 80 no producen resultados visuales equivalentes: la escala de calidad de WebP no es la misma que la de JPEG. La comparación correcta: codifica ambos hasta que alcancen la misma puntuación SSIM y luego compara los tamaños de archivo. Eso es lo que refleja la tabla de benchmarks anterior.

Cuándo JPEG sigue ganando

A pesar de la ventaja de compresión de WebP, hay escenarios donde JPEG sigue siendo la opción más práctica:

• Compatibilidad universal: JPEG funciona en todas partes: todos los navegadores, todos los clientes de correo, todas las herramientas de edición de imágenes, todos los visualizadores del sistema operativo. WebP requiere iOS 14+, macOS 11+, y no está soportado por versiones antiguas de Android WebViews ni por Outlook en Windows. Para cualquier contexto donde no puedas usar el elemento <picture> de HTML como alternativa (correo electrónico, PDF, documentos Word, algunas exportaciones de CMS), JPEG es la opción segura.
• Preservación de Exif y metadatos: JPEG cuenta con décadas de soporte de herramientas para metadatos Exif, IPTC y XMP. Derechos de autor, GPS, configuración de cámara y perfiles de color están bien soportados en los flujos de trabajo JPEG. WebP soporta Exif y XMP, pero muchas herramientas eliminan o corrompen estos metadatos en ciclos de codificación/decodificación.
• Edición y recodificación: Si una imagen va a editarse y guardarse varias veces (por ejemplo, en el flujo de trabajo de un equipo de contenidos), la pérdida generacional de JPEG está bien documentada. Las herramientas WebP son menos maduras en los flujos de trabajo de edición profesional, y pueden producirse pérdidas de calidad inesperadas al pasar por aplicaciones que no implementan completamente la especificación.
• Ecosistema de herramientas: Lightroom, Photoshop, Capture One y la mayoría de las plataformas DAM tratan JPEG como su formato de exportación principal. La exportación a WebP está disponible pero suele ser secundaria, con menos opciones de ajuste de calidad expuestas en la interfaz.

Estrategia de migración: el elemento picture como alternativa

El enfoque recomendado para la migración web a WebP es servir WebP a los navegadores compatibles mientras se recurre de forma transparente a JPEG para los que no lo son. El elemento HTML <picture> hace que esto sea muy sencillo:

<picture>
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Paisaje de montaña al amanecer" width="1200" height="630">
</picture>

Los navegadores que soportan WebP cargarán hero.webp. Todos los demás (incluidos IE11, Safari antiguo y el motor de renderizado de Outlook si la plantilla se visualiza en un navegador) cargarán hero.jpg. Este patrón requiere mantener ambos archivos, lo que aproximadamente duplica el almacenamiento, pero es manejable con una CDN o un servicio de optimización de imágenes que genere ambos formatos bajo demanda.

Para la negociación de contenido del lado del servidor, comprueba la cabecera de solicitud Accept: image/webp y sirve el formato apropiado de forma dinámica. Esto elimina la necesidad de código HTML duplicado.

AVIF: el siguiente paso más allá de WebP

AVIF (AV1 Image File Format) es el sucesor de WebP, basado en el codec de vídeo AV1. A calidad visual equivalente, AVIF suele ser entre un 20 y un 35% más pequeño que WebP y entre un 40 y un 60% más pequeño que JPEG. También soporta HDR, gama de colores amplia y profundidad de 12 bits de forma nativa.

A principios de 2026, AVIF está soportado en Chrome (85+), Firefox (93+) y Safari (16+), cubriendo aproximadamente el 90% de la cuota de mercado de navegadores. La codificación de AVIF es significativamente más lenta que la de WebP (a menudo entre 10 y 50 veces más lenta), lo que lo hace poco práctico para la codificación en tiempo real pero excelente para pipelines de activos preoptimizados. El elemento <picture> soporta una alternativa de tres niveles:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Imagen hero" width="1200" height="630">
</picture>

Esto proporciona la máxima compresión a los navegadores modernos manteniendo total compatibilidad retroactiva.