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

JPEG XL finalmente regresa a Chrome

Después de tres años de controversia, JPEG XL ha vuelto a Chromium. Chrome 145, lanzado a principios de febrero de 2026, incorpora un decodificador JPEG XL. Todavía se encuentra detrás de un flag (opción experimental), pero está 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 cualquier formato de imagen web actual en la mayoría de las dimensiones técnicas: es un 50 a 60% más pequeño que JPEG, tiene una compresión un 10 a 15% mejor que AVIF a velocidades de codificación equivalentes, y es el único formato moderno con una decodificación progresiva real. Para los profesionales del rendimiento web, la trayectoria del formato, desde estándar ISO hasta su exilio de Chrome y su posterior resurrección, representa tanto una oportunidad técnica como una advertencia sobre el poder de los proveedores de navegadores sobre la plataforma web.

Última revisión por Arjen Karel en Febrero de 2026

El soporte de los navegadores en febrero de 2026 es de solo el 12%

El soporte global efectivo de JPEG XL en los navegadores se sitúa en aproximadamente un 12%, proveniente casi en su totalidad de los usuarios de Safari. Ese número está a punto de cambiar. Pero el calendario sigue siendo incierto.

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 marco de trabajo de imágenes a nivel del sistema operativo, lo que significa que funciona en todos los lugares donde se ejecuta Safari. Sin embargo, el soporte de Safari es explícitamente parcial: no hay soporte para animaciones ni para 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 los dispositivos Apple.

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

Para probar JPEG XL en Chrome hoy mismo, navega a chrome://flags/#enable-jxl-image-format y ponlo en "Enabled" (Habilitado). Reinicia Chrome. Cualquier sitio que ya esté sirviendo imágenes JXL (los clientes de Cloudinary, por ejemplo) empezará a entregarlas a tu navegador.

Firefox sigue siendo el más rezagado. El formato solo está disponible en Firefox Nightly tras el flag image.jxl.enabled. Críticamente, el código del decodificador no está compilado en absoluto en las compilaciones estables, por lo que el flag no hace nada en la versión de lanzamiento de Firefox. La posición de Mozilla ha pasado de "negativa" a "neutral". El decodificador Rust jxl-rs ha aterrizado en Firefox Nightly (apuntando a Firefox 149), pero quedan seis bloqueadores antes de que pueda enviarse a la versión estable: soporte de perfiles de color, decodificación progresiva, HDR, integración con el perfilador, compilación en las compilaciones de lanzamiento y superación de los Web Platform Tests. No hay un plazo establecido para un 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 la versión de Edge 145 no lo mencionan.

Interop 2026 ha incluido a JPEG XL como un área de investigación (no como un área de enfoque completo), con la participación de Apple, Google, Microsoft y Mozilla. Esto señala una intención entre proveedores de construir conjuntos de pruebas exhaustivos, lo que normalmente precede a un lanzamiento más amplio.

Cómo JPEG XL supera a todas las alternativas. Y dónde no lo hace

La historia de la eficiencia de compresión tiene matices y depende en gran medida del tipo de contenido y de la tasa de bits (bitrate). En el nivel más alto, JPEG XL gana las comparaciones más importantes en el mundo real.

Frente a JPEG

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

Frente a AVIF

La comparación depende de la tasa de bits. A tasas de bits bajas por debajo de 0,4 bpp (compresión fuerte), AVIF supera a JPEG XL. Produce imágenes más suaves con menos artefactos. En tasas de bits medias y altas (0,4 bpp y superiores), donde vive la mayor parte de la fotografía web, JPEG XL gana constantemente en preservación de detalles y fidelidad. El propio estudio comparativo de AVIF de Google mostró que 9 de 13 métricas de calidad favorecían a JPEG XL con ajustes de velocidad del codificador prácticos. La brecha en la velocidad de codificación es enorme: AVIF (a través de libaom) es un orden de magnitud más lento que JPEG XL en la codificación de un solo hilo. En los ajustes más lentos de AVIF (~0,5 Mpx/s), iguala la densidad de compresión del segundo ajuste más rápido de JPEG XL a 52 Mpx/s. Una diferencia de velocidad de 100 veces.

Frente a WebP

JPEG XL gana de forma decisiva. WebP está limitado a una profundidad de color de 8 bits, submuestreo de crominancia 4:2:0 en modo con pérdida (lossy) 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 restricciones en el submuestreo de crominancia.

El tipo de contenido importa

Para tipos de contenido específicos, los puntos de referencia de DebugBear revelaron un panorama más mixto. AVIF ganó en los logotipos (2 KB frente a los 6 KB de JXL) y en las imágenes con transparencia (18 KB frente a 63 KB), mientras que JPEG XL ganó en las fotografías (472 KB frente a 507 KB) y en el contenido animado donde logró una compresión del 99% (14 KB a partir d'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 radicalmente la forma en que se cargan las imágenes. Los archivos JPEG XL son siempre al menos 8x8 progresivos; el marco DC (baja frecuencia) se codifica siempre primero. Con solo ~1% de los datos del archivo descargados, aparece una vista previa utilizable de la imagen completa. Compara eso con el JPEG progresivo, que requiere entre un 10 y un 15% para su primer escaneo. Aún más importante, JPEG XL soporta progresión ordenada por prominencia (saliency): los modelos de aprendizaje automático pueden identificar las regiones más importantes visualmente (rostros en retratos, detalles de productos en e-commerce) y codificar esas regiones para que lleguen primero. El decodificador suaviza los bordes entre las regiones completadas y las que aún se están cargando.

Esto crea una línea de tiempo 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, de forma secuencial. JPEG XL superpone la transferencia y la 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 tener archivos de marcador de posición de imagen de baja calidad (LQIP) por separado, eliminando por completo los bytes redundantes. Sin embargo, vale la pena señalar que la implementación actual de Safari no admite la 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 función estrella oculta de JPEG XL. El formato puede copiar directamente los coeficientes de los bloques DCT de JPEG en sus propios bloques VarDCT, mejorando únicamente la codificación de la entropía. El resultado: una reducción media del tamaño del archivo de ~20% (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 en píxeles y volver a codificar, lo que provoca una pérdida generacional. La API DICOM de Google Cloud Platform ya utiliza esta capacidad para reducir el tamaño de los archivos de imágenes médicas en un 20%.

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

Qué significa esto para los Core Web Vitals

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

LCP (Largest Contentful Paint)

El LCP se beneficia de dos efectos combinados. En primer lugar, los archivos de menor tamaño reducen la Resource Load Duration. La fase de descarga. Una reducción del 52% con respecto al JPEG significa que la imagen principal (hero image) llega aproximadamente al doble de velocidad en conexiones con ancho de banda restringido. En segundo lugar, JPEG XL se decodifica más rápido que AVIF, lo que reduce el Element Render Delay. La compleja decodificación derivada del códec de video de AVIF puede crear una sobrecarga de CPU significativa en los dispositivos móviles, donde un AVIF más pequeño que se descarga más rápido puede verse parcialmente anulado por un mayor tiempo de decodificación. 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, el LCP se mide cuando la imagen se ha renderizado por completo, por lo que la decodificación progresiva no mejora directamente la marca de tiempo del LCP. Mejora el rendimiento percibido, lo cual es importante para la user experience aunque no mueva la métrica. Si JPEG XL es el formato de tu imagen LCP, haz un preload para que el navegador lo descubra lo antes posible.

CLS (Cumulative Layout Shift)

Al CLS no le importa el formato. Todos los formatos se benefician por igual de los atributos explícitos de anchura y altura (width y height). JPEG XL de hecho codifica la información de las dimensiones en las primeras cabeceras (headers), lo que teóricamente podría ayudar a los navegadores a asignar espacio más rápidamente, pero el impacto práctico es insignificante en comparación con simplemente establecer las dimensiones en el HTML.

INP (Interaction to Next Paint)

El INP puede verse afectado por una decodificación de imágenes pesada en el hilo principal (main thread). La decodificación más rápida y la optimización SIMD de JPEG XL significan un menor bloqueo del hilo principal que AVIF, aunque normalmente ambos formatos se decodifican fuera del hilo principal en los navegadores modernos.

Impacto en el mundo real

Según el Web Almanac 2025, JPEG todavía representa el 57% de las imágenes LCP tanto en móviles como en ordenadores de escritorio. WebP ha crecido al 11%, lo que supone un aumento de 4 puntos porcentuales con respecto a 2024. AVIF se sitúa en apenas un 0,7%. JPEG XL ni siquiera se mide todavía. La página web media carga 19 imágenes en móvil con un peso total de 911 KB. Convertirlas de JPEG a JPEG XL ahorraría aproximadamente de 450 a 550 KB por página. Con un peso medio de imagen en escritorio de 1.058 KB, el ahorro se acerca a los 500-630 KB.

En los sitios supervisados por CoreDash, las páginas que ofrecen imágenes en formatos modernos (AVIF o WebP) muestran tasas de buen LCP del 81%, en comparación con el 64% de las páginas que todavía dependen exclusivamente del JPEG. A medida que JPEG XL logre un mayor soporte en los navegadores, la brecha debería ampliarse aún más. Monitorear tus datos de Real User Monitoring después de habilitar la entrega de JXL te dirá exactamente cuánto se benefician los usuarios reales.

Sirviendo JPEG XL hoy en día con las alternativas (fallbacks) adecuadas

La implementación requiere una estrategia por capas: el elemento <picture> para las imágenes HTML, la negociación de contenido del lado del servidor para CSS y las imágenes con referencias dinámicas, y la automatización mediante CDN cuando 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 utilizan el primer formato que soportan:

<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="Descripción" width="1200" height="800"
       loading="lazy" decoding="async">
</picture>

Si esta imagen es tu hero y el elemento LCP más probable, elimina loading="lazy" y establece su fetchpriority en high. Nunca cargues de forma diferida (lazy load) tu imagen LCP.

Para imágenes responsivas, cada origen necesita su propio srcset con descriptores de ancho. Esto crea 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 mediante CDN se vuelve fundamental.

Negociación de contenido del lado del servidor

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

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

El detalle crítico: incluye siempre Vary: Accept en la cabecera de respuesta para que los CDNs y las cachés proxy almacenen diferentes variantes por formato. Sin esto, una respuesta JXL guardada en caché se servirá a navegadores que no pueden decodificarla.

Soporte CDN

El soporte de los CDNs es desigual. Cloudinary ofrece un soporte completo para JPEG XL a través de su parámetro f_auto. No es de sorprender, dado que Cloudinary cocreó el formato y ya entrega aproximadamente 1.000 millones de imágenes JPEG XL al día. Image Optimizer de Fastly añadió soporte total para JPEG XL en julio de 2024, utilizando el esfuerzo de codificación 3 con 4 hilos de ejecución y afirmando un ahorro de ~60% con respecto a JPEG. Cloudflare, a pesar de la fuerte demanda de la comunidad, no admite la conversión a JPEG XL en su producto de cambio de tamaño de imágenes (Image Resizing). Puede almacenar en caché las variantes JXL desde tu origen mediante Vary: Accept, pero no puede generarlas. Si utilizas Cloudflare, consulta nuestra guía sobre cómo configurar Cloudflare para los Core Web Vitals para conocer los ajustes que sí ayudan. AWS CloudFront, Akamai y Azure no tienen soporte nativo para JPEG XL.

Herramientas

Las herramientas para generar archivos JPEG XL se centran en cjxl a partir de la implementación de referencia libjxl. Parámetros clave: -d para la distancia (0 = sin pérdidas, de 1.0 a 2.0 para calidad web con pérdidas), -e para el esfuerzo (de 1 a 9, valor por defecto 7), y -p para codificación progresiva. Para los archivos JPEG de entrada, cjxl input.jpg output.jxl realiza una transcodificación sin pérdidas de forma predeterminada. La ruta de migración más sencilla posible. ImageMagick, libvips (desde la versión 8.11) y Photoshop v25 también soportan JXL. Sin embargo, sharp (la biblioteca de imágenes de Node.js que alimenta Next.js) tiene soporte experimental para JXL desde la v0.31.3, pero los binarios precompilados distribuidos a través de npm no incluyen el códec JXL. Tendrías que compilar libvips tú mismo con soporte para libjxl, y el responsable del mantenimiento ha cerrado la solicitud para binarios precompilados JXL. Esto significa que Next.js no tiene soporte práctico para JPEG XL listo para usar. El soporte en el núcleo de WordPress se rastrea como el ticket #52788, pero el verdadero obstáculo es que la extensión GD de PHP no es compatible con JPEG XL. PHP 8.5 (noviembre 2025) sigue careciendo de soporte GD para JXL.

La decisión de Halloween y su anulación tres años después

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. Es importante entenderla porque revela las fuerzas que configuran qué tecnologías llegan a los usuarios.

El 31 de octubre de 2022, en lo que rápidamente se apodó la "decisión de Halloween", Jim Bankoski, del equipo Chrome de Google, anunció la eliminación del soporte experimental para JPEG XL. Expuso cuatro motivos: los flags experimentales no deben permanecer indefinidamente; falta de interés por parte del ecosistema; falta de beneficios adicionales suficientes frente a los formatos existentes; y la carga que supone el mantenimiento. Bankoski sugirió WebAssembly como "un gran camino a seguir" para aquellos que quisieran usar JPEG XL en Chrome.

La reacción fue inmediata y constante. La incidencia (issue) de Chromium se convirtió en la segunda 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, el co-creador de JPEG XL en Cloudinary, publicó una detallada refutación técnica ("El caso a favor de JPEG XL") demostrando que las pruebas comparativas publicadas por Google empleaban implementaciones de JPEG XL defectuosas y métricas sesgadas a favor de AVIF. La Free Software Foundation calificó la decisión de Google como una prueba de que Google Chrome se había convertido en el árbitro de los estándares web y acusó a la empresa de actuar por sus propios intereses. Dado que AVIF se deriva de AV1, desarrollado por la Alliance for Open Media que Google cofundó.

A los observadores no se les escapó la ironía: Google había cocreado JPEG XL a través de su proyecto PIK, lo que hizo aún más confusa la decisión de matarlo en Chrome. Cuando JPEG XL fue propuesto para Interop 2024, recibió 646 reacciones de la comunidad. 4,5 veces más que la propuesta que quedó en segundo lugar. Y fue rechazado alegando únicamente "falta de consenso".

Lo que finalmente revirtió la decisión fue el impulso del ecosistema, que hizo insostenible la ausencia de Chrome. Que Apple lanzara Safari 17 con soporte para JPEG XL en septiembre 2023 fue la primera gran ruptura. El hecho de que Mozilla pasara de una postura "negativa" a "neutral" y luego a estar activamente dispuesta a implementarlo (con un decodificador en Rust) aumentó la presión. La declaración de la PDF Association sobre JPEG XL como el formato HDR preferido para los PDF en octubre de 2025 puede que fuera el punto de inflexión. El visor de PDF integrado de Chrome necesitaría el soporte de JXL para seguir cumpliendo la normativa. El 21 de noviembre de 2025, Rick Byers (Director Técnico de Arquitectura de Chrome) publicó la anulación de la decisión, dando la bienvenida a las contribuciones para integrar en Chromium un decodificador JPEG XL con buen rendimiento y seguro para la memoria. En enero de 2026 se fusionó el decodificador jxl-rs basado en Rust, y Chrome 145 lo incorporó tras un flag en febrero de 2026.

Conclusión: almacena fuentes de calidad, convierte bajo demanda

Desde el punto de vista técnico, JPEG XL es el mejor formato de imagen de propósito general disponible. Supera en compresión a AVIF a velocidades de codificación prácticas, ofrece decodificación progresiva algo que ningún competidor iguala y permite transcodificación JPEG sin pérdidas, proporcionando 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 el código integrado, Firefox está integrando activamente el mismo decodificador en Rust y Safari cuenta con soporte desde 2023.

El camino a seguir en la práctica consiste en almacenar el material de origen con la mayor calidad posible y dejar que tu canal de distribución (delivery pipeline) se encargue de la conversión de formato. Conserva archivos PNG sin pérdidas o JPEG maestros de alta calidad como tus originales. Usa un CDN con negociación de formato automática: Cloudinary con f_auto, Fastly Image Optimizer, o Cloudflare Polish inspeccionarán la cabecera Accept del navegador y servirán JXL, AVIF, WebP, o JPEG sin que tengas que generar de antemano ni una sola variante. Si alojas por tu cuenta, configura una conversión bajo demanda con libvips o ImageMagick detrás de una caché del lado del servidor, convirtiendo una vez por formato ante la primera solicitud, en lugar de generar en bloque cuatro variantes por imagen de entrada. La transcodificación sin pérdidas de JPEG XL encaja a la perfección con este modelo: tus JPEG existentes son el origen, y convertirlos a JXL es, a todos los efectos, una conversión bajo demanda con cero pérdida de calidad. La pregunta no es si JPEG XL obtendrá una amplia compatibilidad con los navegadores, sino cuándo cambiará Chrome el flag para que esté activado de manera predeterminada. Y la única respuesta honesta es que no se ha anunciado ninguna fecha oficial. El exilio de tres años de este formato en Chrome debería atemperar el entusiasmo con pragmatismo: sírvelo allí donde sea compatible, prevé una alternativa elegante (fallback) para los demás casos y deja que el CDN o el canal de conversión se ocupen del resto.