JPEG XL y Core Web Vitals: lo que necesitas saber ahora que Chrome lo incluye

JPEG XL finalmente vuelve a Chrome

Después de tres años de controversia, JPEG XL ha regresado a Chromium. Chrome 145, lanzado a principios de febrero de 2026, incluye un decodificador JPEG XL. Todavía detrás de un flag, pero funcionalmente presente en el código base por primera vez desde su polémica eliminación a finales de 2022. Esto importa porque JPEG XL es demostrablemente superior a todos los formatos de imagen web existentes en la mayoría de las dimensiones técnicas: 50 a 60% más pequeño que JPEG, 10 a 15% mejor compresión que AVIF a velocidades de codificación equivalentes, y el único formato moderno con verdadera decodificación progresiva. Para los profesionales del rendimiento web, la trayectoria del formato desde estándar ISO hasta el exilio en Chrome y su resurrección representa tanto una oportunidad técnica como una advertencia sobre el poder de los proveedores de navegadores sobre la plataforma web.

El soporte en navegadores en febrero de 2026 es solo del 12%

El soporte global efectivo de JPEG XL en navegadores se sitúa en aproximadamente el 12%, casi en su totalidad proveniente de usuarios de Safari. Ese número está a punto de cambiar. Pero la línea temporal sigue siendo incierta.

Safari 17+ (lanzado en septiembre de 2023) proporciona decodificación nativa de JPEG XL en macOS Sonoma, iOS 17, iPadOS 17, watchOS y visionOS. La implementación de Apple delega la decodificación al framework de imágenes a nivel del sistema operativo, lo que significa que funciona en todas partes donde se ejecuta Safari. Sin embargo, el soporte de Safari es explícitamente parcial: sin soporte para animación y sin decodificación progresiva. Dos de las características más distintivas de JPEG XL. Esta es una limitación significativa que socava la propuesta de valor completa del formato en dispositivos Apple.

Chrome 145 (febrero de 2026) reintroduce JPEG XL a través de un decodificador en Rust puro llamado jxl-rs, reemplazando la implementación anterior en C++ libjxl. El decodificador está controlado por chrome://flags/#enable-jxl-image-format y no está habilitado por defecto. Google ha establecido condiciones claras para activarlo por defecto: un compromiso con el mantenimiento a largo plazo y cumplir con los criterios de lanzamiento estándar. El decodificador en Rust actualmente rinde dentro del 15 al 25% de la velocidad de la implementación de referencia en C++, con 26 PRs de optimización fusionados solo en diciembre de 2025. Las capacidades confirmadas incluyen perfiles de color ICC, animaciones, alfa/transparencia, gama amplia (Display P3) y HDR (PQ/HLG).

Firefox se queda más atrás. El formato solo está disponible en Firefox Nightly detrás del flag image.jxl.enabled. Es importante destacar que el código del decodificador no se compila en las compilaciones estables, por lo que el flag no hace nada en el Firefox de lanzamiento. La posición de Mozilla ha cambiado de "negativa" a "neutral", con trabajo activo (Bug 1986393) para integrar el mismo decodificador en Rust jxl-rs. No existe una línea temporal para el soporte estable.

Edge, como derivado de Chromium, probablemente contiene el código jxl-rs de Chrome 145 pero no ha anunciado ni documentado oficialmente el soporte de JPEG XL. Las notas de lanzamiento de Edge 145 no lo mencionan.

Interop 2026 ha incluido JPEG XL como área de investigación (no como área de enfoque completo), con Apple, Google, Microsoft y Mozilla participando. Esto señala la intención de múltiples proveedores de crear conjuntos de pruebas exhaustivos, lo que típicamente precede a un despliegue más amplio.

Cómo JPEG XL supera a cada alternativa. Y dónde no lo hace

La historia de la eficiencia de compresión es matizada y depende en gran medida del tipo de contenido y la tasa de bits. Al nivel más alto, JPEG XL gana en las comparaciones más importantes del mundo real.

Contra JPEG

Las ganancias son dramáticas. JPEG XL logra calidad visualmente sin pérdidas a aproximadamente 1,2 bits por píxel donde JPEG requiere 2,4 bpp. Una mejora de 2:1. El benchmark de DebugBear de una fotografía de 990 KB mostró JPEG XL a 472 KB (52% de ahorro), comparado con WebP a 700 KB y AVIF a 507 KB. Las pruebas de Cloudinary de más de 40.000 imágenes encontraron que JPEG XL a esfuerzo 6 producía archivos 20% más pequeños que AVIF mientras codificaba 2,5 veces más rápido.

Contra AVIF

La comparación depende de la tasa de bits. A tasas de bits bajas por debajo de 0,4 bpp (compresión intensa), AVIF supera a JPEG XL. Produce imágenes más suaves con menos artefactos. A tasas de bits medias a altas (0,4 bpp en adelante), donde vive la mayoría de la fotografía web, JPEG XL gana consistentemente en preservación de detalles y fidelidad. El propio estudio de comparación de AVIF de Google mostró que 9 de 13 métricas de calidad favorecían a JPEG XL en configuraciones prácticas de velocidad de codificación. La brecha de velocidad de codificación es enorme: AVIF (vía libaom) es un orden de magnitud más lento que JPEG XL en codificación de un solo hilo. En las configuraciones más lentas de AVIF (~0,5 Mpx/s), iguala la densidad de compresión de la segunda configuración más rápida de JPEG XL a 52 Mpx/s. Una diferencia de velocidad de 100x.

Contra WebP

JPEG XL gana de forma decisiva. WebP está limitado a profundidad de color de 8 bits, submuestreo de croma 4:2:0 en modo con pérdida y una resolución máxima de 16.383 x 16.383 píxeles. JPEG XL soporta hasta 32 bits por canal (entero o punto flotante), resoluciones que superan los 1.000 millones de píxeles por lado, y no tiene restricción de submuestreo de croma.

El tipo de contenido importa

Para tipos de contenido específicos, los benchmarks de DebugBear revelaron un panorama más variado. AVIF ganó en logos (2 KB frente a 6 KB de JXL) e imágenes con transparencia (18 KB frente a 63 KB), mientras que JPEG XL ganó en fotografías (472 KB frente a 507 KB) y contenido animado donde logró una compresión del 99% (14 KB de un GIF de 1,3 MB, frente a los 56 KB de AVIF). Estos resultados utilizaron la configuración predeterminada de Cloudinary, por lo que representan resultados típicos en lugar de optimizados.

Comparación de características

Dos características que ningún otro formato puede igualar

Las características estratégicamente más importantes de JPEG XL son la decodificación progresiva y la transcodificación JPEG sin pérdidas. Ningún competidor ofrece ninguna de las dos.

Decodificación progresiva

La decodificación progresiva cambia fundamentalmente cómo se cargan las imágenes. Los archivos JPEG XL son siempre al menos progresivos 8x8; el frame DC (baja frecuencia) siempre se codifica primero. Con solo ~1% de los datos del archivo descargados, aparece una vista previa de imagen completa utilizable. Compara eso con JPEG progresivo, que requiere del 10 al 15% para su primer escaneo. Más importante aún, JPEG XL soporta progresión ordenada por saliencia: los modelos de aprendizaje automático pueden identificar las regiones visualmente más importantes (rostros en retratos, detalles de productos en comercio electrónico) y codificar esas regiones para que lleguen primero. El decodificador suaviza los límites entre las regiones completadas y las que aún se están cargando.

Esto crea una línea temporal de renderizado diferente. AVIF requiere la imagen comprimida completa antes de que pueda comenzar la decodificación: el tiempo total equivale al tiempo de descarga más el tiempo de decodificación, secuencialmente. JPEG XL superpone transferencia y decodificación, por lo que el usuario ve contenido significativo mucho antes. Cloudinary ha señalado que el renderizado progresivo de JPEG XL elimina la necesidad de archivos separados de Low Quality Image Placeholder (LQIP), eliminando bytes redundantes por completo. Sin embargo, vale la pena señalar que la implementación actual de Safari no soporta decodificación progresiva, lo que limita esta ventaja a las futuras implementaciones de Chrome y Firefox.

Transcodificación JPEG sin pérdidas

La transcodificación JPEG sin pérdidas es la característica oculta de JPEG XL. El formato puede copiar directamente los coeficientes de bloques DCT de JPEG en sus propios bloques VarDCT, mejorando solo la codificación de entropía. El resultado: ~20% de reducción promedio en tamaño de archivo (rango: 13 a 22%) con el archivo JPEG original reconstruible bit a bit desde el archivo JXL. Ningún otro formato puede hacer esto. Transcodificar a WebP o AVIF requiere decodificar a píxeles y recodificar, causando pérdida generacional. La API DICOM de Google Cloud Platform ya utiliza esta capacidad para reducir el tamaño de archivos de imágenes médicas en un 20%.

A escala web, si todos los JPEG actuales se transcodificaran sin pérdidas a JXL, el ahorro de ancho de banda sería enorme. La comunidad de JPEG XL estima que el ahorro de energía equivaldría a alimentar ~487.000 hogares estadounidenses durante una hora al día.

Qué significa esto para Core Web Vitals

JPEG XL afecta a cada métrica de Core Web Vitals a través de diferentes mecanismos, y la relación es más matizada que "archivos más pequeños = mejores puntuaciones".

LCP (Largest Contentful Paint)

LCP se beneficia de dos efectos compuestos. Primero, los tamaños de archivo más pequeños reducen la Resource Load Duration. La fase de descarga. Una reducción del 52% respecto a JPEG significa que la imagen hero llega aproximadamente el doble de rápido en conexiones con ancho de banda limitado. Segundo, JPEG XL decodifica más rápido que AVIF, reduciendo el Element Render Delay. La compleja decodificación derivada de codec de vídeo de AVIF puede crear una sobrecarga de CPU significativa en dispositivos móviles, donde un AVIF más pequeño que se descarga más rápido puede verse parcialmente anulado por un tiempo de decodificación más largo. La velocidad de decodificación de JPEG XL de hasta 132 Mpx/s y la optimización SIMD minimizan este cuello de botella. Sin embargo, LCP se mide cuando la imagen está completamente renderizada, por lo que la decodificación progresiva no mejora directamente la marca de tiempo de LCP. Mejora el rendimiento percibido, lo que importa para la experiencia de usuario incluso si no mueve la métrica.

CLS (Cumulative Layout Shift)

A CLS no le importa el formato. Todos los formatos se benefician por igual de los atributos explícitos de width y height. JPEG XL codifica información de dimensiones en los encabezados iniciales, lo que teóricamente podría ayudar a los navegadores a asignar espacio más rápido, pero el impacto práctico es insignificante comparado con simplemente establecer las dimensiones en HTML.

INP (Interaction to Next Paint)

INP puede verse afectado por la decodificación pesada de imágenes en el hilo principal. La decodificación más rápida de JPEG XL y la optimización SIMD significan menos bloqueo del hilo principal que AVIF, aunque ambos formatos típicamente se decodifican fuera del hilo principal en los navegadores modernos.

Impacto en el mundo real

La página web mediana en 2025 carga 19 imágenes en móvil con un peso total de 911 KB (HTTP Archive Web Almanac 2025). Convertir estas de JPEG a JPEG XL ahorraría aproximadamente 450 a 550 KB por página. Una mejora sustancial para usuarios en redes limitadas. Con un peso mediano de imágenes en escritorio de 1.058 KB, los ahorros se acercan a 500 a 630 KB.

Servir JPEG XL hoy con fallbacks adecuados

La implementación requiere una estrategia por capas: el elemento <picture> para imágenes HTML, negociación de contenido del lado del servidor para CSS e imágenes referenciadas dinámicamente, y automatización CDN donde esté disponible.

El elemento picture

El elemento <picture> proporciona el enfoque más limpio del lado del cliente. Los navegadores evalúan los elementos <source> de arriba a abajo y usan el primer formato soportado:

<picture>
  <source srcset="hero.jxl" type="image/jxl">
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Description" width="1200" height="800"
       loading="lazy" decoding="async">
</picture>

Para imágenes responsivas, cada source necesita su propio srcset con descriptores de ancho. Creando una explosión combinatoria de más de 12 variantes por imagen (3 o 4 formatos x 3 o 4 tamaños). Aquí es donde la automatización CDN se vuelve esencial.

Negociación de contenido del lado del servidor

La negociación de contenido del lado del servidor inspecciona el encabezado Accept. Safari 17+ envía image/jxl en su encabezado Accept. La configuración de Nginx mapea esto a extensiones de archivo:

map $http_accept $img_ext {
    ~image/jxl   '.jxl';
    ~image/avif  '.avif';
    ~image/webp  '.webp';
    default      '';
}

El detalle crítico: siempre incluye Vary: Accept en el encabezado de respuesta para que los CDN y las cachés proxy almacenen variantes separadas por formato. Sin esto, una respuesta JXL en caché se servirá a navegadores que no pueden decodificarlo.

Soporte CDN

El soporte CDN es desigual. Cloudinary ofrece soporte completo de JPEG XL a través de su parámetro f_auto. No es sorprendente dado que Cloudinary co-creó el formato y ya entrega aproximadamente 1.000 millones de imágenes JPEG XL por día. El Image Optimizer de Fastly añadió soporte completo de JPEG XL en julio de 2024, usando esfuerzo de codificación 3 con 4 hilos y afirmando ~60% de ahorro sobre JPEG. Cloudflare, a pesar de la fuerte demanda de la comunidad, no soporta conversión a JPEG XL en su producto Image Resizing. Puede almacenar en caché variantes JXL desde tu origen vía Vary: Accept, pero no puede generarlas. AWS CloudFront, Akamai y Azure no tienen soporte nativo de JPEG XL.

Herramientas

Las herramientas para generar archivos JPEG XL se centran en cjxl de la implementación de referencia libjxl. Parámetros clave: -d para distancia (0 = sin pérdidas, 1,0 a 2,0 para calidad web con pérdidas), -e para esfuerzo (1 a 9, predeterminado 7), y -p para codificación progresiva. Para entradas JPEG, cjxl input.jpg output.jxl realiza transcodificación sin pérdidas por defecto. La ruta de migración más simple posible. ImageMagick, libvips (desde 8.11) y Photoshop v25 también soportan JXL. Sin embargo, sharp (la biblioteca de imágenes de Node.js que alimenta Next.js) aún no expone la salida JXL, lo que significa que Next.js no tiene soporte nativo de JPEG XL. El soporte en el core de WordPress se rastrea como ticket #52788, marcado como "maybelater".

La decisión de Halloween y su reversión de tres años

La historia política de JPEG XL en Chrome es un caso de estudio sobre el poder de los proveedores de navegadores sobre los estándares web. Entenderla importa porque revela las fuerzas que determinan qué tecnologías llegan a los usuarios.

El 31 de octubre de 2022. Apodada la "decisión de Halloween". Jim Bankoski del equipo de Chrome de Google anunció la eliminación del soporte experimental de JPEG XL. Las razones declaradas fueron cuatro: los flags experimentales no deberían permanecer indefinidamente; interés insuficiente del ecosistema; beneficios incrementales insuficientes sobre los formatos existentes; y carga de mantenimiento. Bankoski sugirió WebAssembly como "un gran camino a seguir" para quienes quisieran JPEG XL en Chrome.

La reacción fue inmediata y sostenida. El issue de Chromium se convirtió en el segundo con más estrellas en toda la historia del proyecto, con más de 1.000 votos a favor y comentarios de representantes de Intel, Adobe, Meta, Shopify, The Guardian, Flickr y la Fundación Krita. Jon Sneyers, co-creador de JPEG XL en Cloudinary, publicó una refutación técnica detallada ("The Case for JPEG XL") mostrando que las pruebas de comparación publicadas por Google usaban implementaciones de JPEG XL con errores y métricas sesgadas hacia AVIF. La Free Software Foundation calificó la decisión de Google como evidencia de que Google Chrome se había convertido en el árbitro de los estándares web y acusó a la empresa de actuar en su propio interés. Dado que AVIF se deriva de AV1, desarrollado por la Alliance for Open Media que Google cofundó.

La ironía no pasó desapercibida para los observadores: el propio Google co-creó JPEG XL a través de su proyecto PIK, haciendo que la decisión de eliminarlo de Chrome fuera aún más confusa. Cuando JPEG XL fue propuesto para Interop 2024, recibió 646 reacciones de la comunidad. 4,5 veces más que la segunda propuesta. Y fue rechazado con solo "falta de consenso" como explicación.

Lo que finalmente revirtió la decisión fue el impulso del ecosistema que hizo insostenible la ausencia de Chrome. Apple lanzando Safari 17 con soporte de JPEG XL en septiembre de 2023 fue la primera ruptura importante. Mozilla cambiando de "negativo" a "neutral" y luego a activamente dispuesto a implementar (con un decodificador en Rust) añadió presión. El anuncio de la PDF Association de JPEG XL como formato HDR preferido para PDF en octubre de 2025 puede haber sido el punto de inflexión. El visor de PDF integrado de Chrome necesitaría soporte JXL para seguir siendo compatible. El 21 de noviembre de 2025, Rick Byers (Tech Lead de Arquitectura de Chrome) publicó la reversión, dando la bienvenida a contribuciones para integrar un decodificador JPEG XL eficiente y seguro en memoria en Chromium. Para enero de 2026, el decodificador jxl-rs basado en Rust fue fusionado, y Chrome 145 lo incluyó detrás de un flag en febrero de 2026.

Conclusión: prepárate ahora, despliega de forma incremental

JPEG XL es técnicamente el mejor formato de imagen de propósito general disponible. Mejor compresión que AVIF a velocidades de codificación prácticas, decodificación progresiva que ningún competidor ofrece, y transcodificación JPEG sin pérdidas que proporciona un ahorro instantáneo del 20% sin pérdida de calidad. Los obstáculos políticos que bloquearon su adopción durante tres años se están disolviendo: Chrome tiene código en el repositorio, Firefox está integrando activamente el mismo decodificador en Rust, y Safari ha enviado soporte desde 2023.

El camino práctico a seguir para los equipos de rendimiento web es claro. Empieza a generar variantes JXL ahora. La transcodificación JPEG sin pérdidas vía cjxl es trivialmente automatizable y proporciona un ahorro inmediato del 20% para el ~12% de usuarios en Safari. Usa elementos <picture> o negociación de contenido con encabezados Vary: Accept para servir JXL junto con fallbacks de AVIF, WebP y JPEG. Si tu CDN es Cloudinary o Fastly, habilita la entrega automática de JXL hoy. La pregunta abierta no es si JPEG XL logrará amplio soporte en navegadores, sino cuándo Chrome activará el flag de desactivado a activado por defecto. Y la única respuesta honesta es que no se ha anunciado ninguna línea temporal. El exilio de tres años del formato de Chrome debería templar el entusiasmo con pragmatismo: sírvelo donde esté soportado, haz fallback de forma elegante en otros lugares, y mantén la pipeline lista para el momento en que llegue el soporte universal.