JPEG XL: por qué AVIF ya ganó la guerra del códec web

Por qué JPEG XL fue rechazado de Chrome en 2023

En el cambio de 2022 a 2023, Google eliminó el soporte experimental de JPEG XL de Chromium argumentando "falta de interés en todo el ecosistema, falta de beneficios incrementales suficientes sobre los formatos existentes, y reducción de la carga de mantenimiento", según recogió HotHardware. Chromium concentra entre el 70% y el 80% del mercado global de navegadores según PCWorld, así que cualquier formato que no entra a Chromium difícilmente escala a la web abierta.

La decisión enfureció a parte de la comunidad: JPEG XL es royalty-free, viene del comité JPEG — la referencia institucional del formato original — y contaba con el respaldo de Cloudinary, donde trabaja el Dr. Jon Sneyers como senior image researcher y co-chair del JPEG XL adhoc group, según un artículo de Computer Weekly firmado por el propio Sneyers.

Más recientemente, un decodificador de JPEG XL escrito en Rust empezó a integrarse en Firefox y Chrome, en parte porque mitiga la vulnerabilidad de WebP de 2023. Gianni Rosato, ingeniero de compresión con experiencia en AV1 y AVIF, sostiene en su blog que eso no alcanza para justificar un nuevo intento.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

La ventaja que JPEG XL ya perdió frente a AVIF

La propuesta original de JXL era un códec diseñado específicamente para imágenes, en contraste con WebP (basado en VP8), HEIF (HEVC) y AVIF (AV1), que vienen del mundo del video. Esa es la tesis que Cloudinary defiende: JXL ofrece progressive decoding real, donde se ve una versión útil de la imagen mientras se carga el resto.

El contraargumento de Rosato: en la práctica, AVIF ya implementa progressive decoding y muestra una imagen utilizable mucho antes que JXL, a apenas el 2-3% del tamaño total del archivo, al apoyarse en el decodificador nativo del navegador en lugar del polyfill habitual.

En el frente de la compresión con pérdida, los benchmarks que cita Rosato muestran que el encoder de referencia de JXL queda detrás de alternativas como Aperture, el encoder en desarrollo de Halide Compression, y que libaom AVIF en modo perceptual queda solo un par de puntos por debajo de su propio modo optimizado para métrica perceptual. El códec conjunto de JPEG, WebP y AVIF ya cubre el rango de fidelidad en el que JXL era competitivo.

La única ventaja que sobrevive, según Rosato, es la lossless: JXL logra alrededor de un 11,9% menos bytes que WebP lossless en su banco de pruebas — fotos de 157 MP, ilustraciones de 10 MP y libros de 27 MP, un dataset que no es representativo del tráfico web promedio.

Herramientas de codificación que JXL no tiene

Rosato enumera cuatro carencias técnicas del formato:

Sin predicción direccional. Codecs block-based como WebP predicen los píxeles de un bloque a partir de los datos vecinos antes del transform de frecuencia; JXL no, según Rosato. La solución propuesta (splines) sigue sin PoC público.
Sin deblocking loop filter (DLF). Las dos herramientas in-loop de JXL — gaborish y EPF — no son equivalentes al DLF de AV1, y JXL sigue sufriendo de mosquito noise.
Colorspace XYB con problemas. El canal B se cuantiza agresivamente, lo que degrada la preservación de color y obliga a los nuevos desarrolladores de encoders a deshacer ese efecto a mano.
Pocas opciones para imágenes no fotográficas. El mecanismo de patches es más costoso que Intra Block Copy de AV1 y está deshabilitado por debajo de effort 7 por temas de rendimiento.

Tiempos de decodificación y el riesgo jxl-bomb

El argumento más sensible para founders es el de rendimiento. Rosato probó su set de imágenes con decodificadores reales: WebP terminó más de 90 KB más grande y aun así decodifica más de 10 veces más rápido que jxl-rs con wpd. La recompresión lossless de JPEG a JXL recupera alrededor del 20% de bytes, pero paga cerca de un 33% más de tiempo de decode.

Hay además un vector de ataque bautizado como jxl-bomb: una imagen de 1.918 bytes que tarda 17,43 segundos de CPU en decodificar en una MacBook Pro M5 Pro con el decoder en Rust. Combinado con que Safari ya soporta JPEG XL nativamente, eso significa que se pueden colar unas decenas de imágenes en una página y ralentizar dispositivos Apple de baja gama sin gran esfuerzo.

Qué significa esto para tu startup

Más allá del debate técnico, el aprendizaje operativo es directo:

No esperes a JPEG XL para tu pipeline de imágenes en 2026. AVIF ofrece la mejor relación tamaño/calidad en la mayor parte del rango perceptual y es el formato soportado de forma estable por Chrome, Firefox y Safari desde hace años (Safari lo incorporó en 2022 según PCWorld). Prioriza AVIF como formato principal y deja JPEG como fallback de compatibilidad.
Mide progressive rendering antes de elegir códec. Si tu producto depende de Largest Contentful Paint — landings de e-commerce, blogs con hero images, SaaS con onboarding visual — la diferencia entre ver algo útil al 2-3% del archivo o esperar a una carga completa impacta conversión.
No confíes en cobertura estándar sin verificar. Que un formato venga del comité JPEG, sea royalty-free y tenga el respaldo de Cloudinary no garantiza que un navegador importante lo adopte. Si construyes sobre un formato no soportado por Chromium, estás construyendo sobre una base que puede cambiar en cualquier release.