Chrome 155 ya decodifica JPEG XL: lo medimos sobre nuestra propia biblioteca de 162 MB

Chrome 155 pasó a estable el 6 y 7 de octubre de 2026 con la decodificación de JPEG XL activada por defecto en Windows, Linux, macOS y Android, y Firefox corrigió su fecha: ya no es la 157, sino la 158, el 13 de octubre. Safari lleva admitiéndolo desde 2023. Es decir, en cuatro días el formato dejó de ser una apuesta y pasó a estar en el navegador de casi todo el mundo. En vez de escribir otra opinión sobre el tema, nosotros hicimos lo único que no se puede conseguir con un modelo generativo: transcodificamos nuestros propios archivos. Sobre 40 JPEGs reales de nuestro sitio, la conversión lossless a JPEG XL quitó un 22,9% de los bytes sin tocar un solo píxel, con la copia bit a bit verificada en 15 de 15 pruebas. Y en el camino apareció un problema bastante peor que cualquier batalla de formatos: 34 de nuestros 598 archivos .jpg ni siquiera son JPEG.

Lo que cambió esta semana — y dónde nos equivocamos en septiembre

El 2 de septiembre publicamos nuestra predicción sobre JPEG XL: Firefox 157 activaría el formato a final de mes, Chrome había formalizado su intención y "antes de fin de 2026" estaría en los tres motores. Casi todo lo importante salió al revés:

• Chrome se adelantó. Google anunció el 6 de octubre Shipping JPEG XL in Chrome y el despliegue empezó el 7: Chrome 155 decodifica .jxl por defecto, sin bandera. El decoder ya no es el C++ de libjxl, sino jxl-rs, una reimplementación en Rust que pasa por SIMD vía target_feature_11 y que, según el propio equipo, no ha tenido un solo bug de memoria en toda su historia.
• Firefox se retrasó. La activación por defecto saltó de la 157 a la 158, el 13 de octubre, y esa versión añade image/jxl a la cabecera Accept de imágenes (MDN lo fusionó el 8 de octubre). Ese detalle importa: sin esa cabecera, la negociación por Accept no puede funcionar en Firefox.
• La cadencia es quincenal ahora. Chrome y Firefox pasaron a releases cada dos semanas en septiembre; los plazos que todo el mundo proyecta a trimestres se mueven en días.

Lección nuestra, no del ecosistema: predecir el orden de los lanzamientos es fácil y predecir el calendario, no. Lo que sí acertamos fue la parte medible.

Qué medimos, exactamente

Auditamos la carpeta de imágenes del sitio: 598 archivos con extensión .jpg o .jpeg, 162,6 MB en total. De ellos, 564 son JPEG reales (117,1 MB). Sobre esos tomamos una muestra aleatoria fija de 40 (semilla 20261009, 8,1 MB) y corre cjxl de libjxl 0.7.0 más ffmpeg para los comparadores:

• JPEG XL lossless: cjxl in.jpg out.jxl — sin banderas, porque como nos avisó el propio encoder ("Implicit-default for JPEG is lossless-transcoding"), con JPEG de entrada el modo por defecto ya es la transcodificación sin pérdida.
• JPEG XL lossy: --lossless_jpeg=0 con distancia 1 y 4.
• WebP q80 y AVIF crf 30 como referencia.
• Verificación: djxl restauró el JPEG y comparamos MD5 contra el archivo original.

Resultados: lossless gana en riesgo, AVIF gana en bytes

Tres conclusiones que nos interesan más que el porcentaje:

1. Nuestra estimación de septiembre (~20% con pérdida cero) se sostuvo: -22,9% de media, -23,1% de mediana, y en 15 de 15 archivos la restauración fue bit a bit idéntica al original. Es la única jugada de toda la tabla que no exige negociar calidad con nadie.
2. La codificación lossless es casi gratis: 0,09 s por imagen frente a ~0,72 s de AVIF en nuestras pruebas. Generar una capa JPEG XL en el build no mueve la aguja del tiempo de despliegue — algo que ya habíamos argumentado en la guía AVIF vs WebP para Astro.
3. En bytes puros, AVIF sigue mandando: -82,2% frente a -51,3% de JPEG XL lossy a distancia 1 (y no es una comparación de igual calidad: los ajustes están fijados, no igualados perceptualmente). Decir que JPEG XL "le gana a AVIF" con estos números sería mentir con la tabla delante.

El hallazgo que le gana a cualquier formato

Auditando los archivos apareció algo que ningún artículo de formatos va a decirte: 34 de nuestros 598 .jpg (5,7%) contienen PNG, y esos 34 archivos pesan 45,5 MB — el 28% de todos los bytes de imagen del sitio. El mayor JPEG real de la biblioteca pesa 715 KB; los ficheros más pesados que tenemos son, justamente, PNGs con extensión de JPEG.

Comprobado en vivo contra el CDN: content-type: image/jpeg, content-length: 1.921.827 y, encima, x-content-type-options: nosniff, para un archivo que por dentro es un PNG de 1536×864. El navegador lo pinta igual, pero todo lo que confíe en la cabecera — negociación Accept, transformadores de CDN, herramientas que re-codifican asumiendo JPEG — recibe mentira.

La causa está en casa y es instructiva: nuestro publish-draft.py ya tiene un guard que detecta bytes PNG y los convierte con ffmpeg -q:v 2 antes de guardarlos como .jpg. Pues bien: 28 de los 34 archivos se committearon DESPUÉS de que ese guard existiera (3 de junio de 2026) y 9 solo en septiembre. Algo en ese camino falla en silencio — una conversión que devuelve error y igualmente escribe los bytes originales, o un download que se salta el guard — y nadie lo estaba mirando.

Y aquí están los números que cierran el argumento:

Escalarlo a la biblioteca completa: la capa JPEG XL lossless sobre los 564 JPEG reales nos ahorraría unos 27 MB (117,1 → ~90,3 MB). Arreglar los 34 archivos mal etiquetados ahorra unos 43 MB (45,5 → ~2,5 MB). El arreglo del formato de archivo da 1,6× más que toda la capa JPEG XL, y se resuelve con un script, sin tocar una URL ni esperar a que ningún navegador se actualice. (Antes de convertirlos en masa haríamos una revisión visual de las capturas con texto: el -94,6% es una cifra de bytes, no un veredicto de calidad.)

Qué hacemos esta semana y qué dejamos para después

Nuestra opinión, sin rodeos

JPEG XL no va a ganar la batalla de los bytes en un catálogo fotográfico; AVIF sigue siendo más agresivo y ya está en todos lados. JPEG XL gana otra cosa: es el único formato con el que puedes comprimir lo que ya tienes publicado sin perder un píxel y sin renegociar el diseño. Eso, más la decodificación progresiva — que en conexiones lentas, como las de buena parte de Latinoamérica, se nota más que los bytes — es un argumento de experiencia, no de benchmark.

Pero el orden de ejecución importa más que el formato: primero el archivo, después el código, y solo al final el formato. Nosotros teníamos 45,5 MB de PNG haciendo pasar por JPEG mientras discutíamos si la capa JXL debía ir antes o después de AVIF en el <picture>. Si tu sitio tiene un presupuesto de rendimiento que defender — el nuestro está documentado aquí —, empieza por auditar qué hay dentro de tus .jpg. Las sorpresas de ese listado suelen costar más que cualquier discusión de formatos.

Preguntas frecuentes

¿Chrome ya admite JPEG XL? Sí: Chrome 155 (estable desde el 6-7 de octubre de 2026) lo decodifica por defecto en Windows, Linux, macOS y Android. Safari desde la 17.0 (2023). Firefox lo activa en la 158, el 13 de octubre, junto con image/jxl en la cabecera Accept.

¿Cuánto ahorra convertir un JPEG a JPEG XL? En nuestra muestra real: -22,9% de media con pérdida cero y salida bit a bit idéntica al original. Es una cifra de nuestro propio archivo, no una promesa del fabricante.

¿Debería reemplazar AVIF con JPEG XL? No. AVIF fue el que más bytes recortó en nuestras pruebas. JPEG XL sirve para otra cosa: recomprimir sin riesgo lo que ya existe, con codificación rápida y decodificación progresiva.