Google trae JPEG XL de vuelta a Chrome

Qué cubre este vídeo

• El anuncio de Chrome se publicó el 6 de octubre de 2026 y nombra a Chrome 155. No establece que todos los visitantes del sitio web ya ejecuten una versión compatible.
• Google agradece los persistentes comentarios de los desarrolladores y el proceso de Interoperabilidad. El decodificador jxl-rs utiliza Rust y operaciones vectoriales optimizadas, mientras que pequeñas áreas inseguras revisadas y el sandbox del navegador permanecen.
• La mejora de compresión del 30-50% anunciada por Google utiliza JPEG como línea base. Los ahorros reales dependen de las imágenes, la configuración del codificador y la calidad visual.
• La comparación de codificadores de septiembre de Gianni Rosato favorece a AVIF en todo su rango de fidelidad con pérdidas probado. Él desarrolla herramientas AVIF de la competencia; su resultado y la afirmación de Google de la línea base JPEG miden comparaciones diferentes.
• Compare formatos en imágenes representativas y mantenga alternativas compatibles. JPEG XL también admite la transcodificación reversible y sin pérdidas de archivos JPEG existentes.
• OpenAI lanzó 722 manuscritos agrupados en 372 familias, con verificación variada y muchas formalizaciones Lean. El modelo permanece sin lanzar, y las cifras de cómputo equivalentes a Pro no son ni un precio minorista ni una garantía de tiempo transcurrido.
• El creador del ESP32-C3 informa un uso aproximado de 50 KB de RAM al almacenar hashes de dominio ordenados en flash. El bloqueo a nivel de DNS tiene limitaciones de mismo dominio y de resolutores alternativos; las colisiones de hash pueden bloquear en exceso. Los resultados del hardware no fueron medidos independientemente para este episodio.

Transcripción traducida

Traducido de la narración original en inglés. El audio y los subtítulos disponibles están controlados por YouTube.

¿Por qué Chrome trae de vuelta JPEG XL?

0:00 Probablemente piensas que Google enterró JPEG XL. Chrome lo trae de vuelta, después de eliminar el soporte experimental, y Rust lo ayudó a entrar. En este video, ¿por qué Google revirtió su curso? ¿Y deberías cambiar tu flujo de imágenes? Es miércoles, siete de octubre, y esto es The Daily Diff. Ten un detalle en mente. Tus JPEGs existentes tienen una forma de unirse a este regreso.

0:20 El martes, Google anunció la decodificación de JPEG XL a partir de Chrome ciento cincuenta y cinco. Hoy el anuncio escaló Hacker News, junto con el volcado de pruebas matemáticas de OpenAI y una placa de dos dólares que bloquea dominios publicitarios. El experimento anterior de Chrome terminó en dos mil veintitrés.

¿Por qué el formato rechazado tuvo otra oportunidad?

0:35 La explicación de Google incluyó un interés insuficiente del ecosistema, lo cual es incómodo cuando el navegador más grande controla si el ecosistema puede realmente usar tu cosa. La nueva publicación atribuye los persistentes comentarios de los desarrolladores, incluido el proceso de Interoperabilidad. Las personas que pedían esto siguieron pidiendo, y Google ahora señala las pruebas del navegador destinadas a hacer que el formato se comporte de manera consistente. El anuncio agradece a los colaboradores, incluido Helmut Januschka.

0:57 A veces, la hoja de ruta más efectiva es negarse a cerrar el problema.

¿Qué cambió dentro del decodificador?

1:01 El cambio de implementación más grande es un decodificador llamado jay ex ell R S, escrito en Rust. Los decodificadores de imágenes ingieren archivos complicados proporcionados por extraños, lo que los convierte en un lugar espectacular para confiar accidentalmente en Internet. Rust ayuda a prevenir clases de errores de memoria antes de que se conviertan en vulnerabilidades del navegador. Google todavía mantiene el sandbox, y la implementación todavía contiene áreas inseguras pequeñas y cuidadosamente revisadas. La seguridad tiene capas, porque la realidad sigue encontrando las costuras.

1:27 Google dice que el fuzzing y la revisión de código por IA no encontraron errores de seguridad de memoria en la historia de este decodificador. Ese es un informe útil del equipo que lo envía. Es poco probable que los futuros atacantes acepten la publicación del blog como un contrato vinculante. Primera pregunta respondida. La presión de los desarrolladores y un decodificador Rust optimizado reabrieron la puerta. Google revirtió una decisión con ingeniería detrás, lo cual está permitido incluso en Internet. Ahora los puntos de referencia de la presentación.

¿Los archivos más pequeños superan a AVIF?

1:48 Google anuncia una compresión entre un treinta y un cincuenta por ciento mejor que JPEG. Descargas más pequeñas pueden ayudar a tus usuarios y a la factura de ancho de banda, pero ese rango depende de lo que codifiques y cómo compares la calidad. El ingeniero de compresión Gianni Rosato publicó una comparación de septiembre donde los modernos codificadores avif superaron a JPEG XL en todo su rango de fidelidad probado. Él trabaja en herramientas avif de la competencia, así que ten ese incentivo junto a los gráficos. Estas comparaciones usan diferentes líneas base.

2:12 Superar al viejo JPEG deja espacio para que avif gane una carga de trabajo. La propia Google recomienda probar ambos formatos, lo cual es un consejo inusualmente práctico para un anuncio de lanzamiento. Otras atracciones de JPEG XL incluyen alto rango dinámico, imágenes sin pérdidas y decodificación progresiva de grano fino. La comunidad publica demostraciones interactivas para explorar el formato. Tu audiencia puede ver una imagen útil mientras llega el resto. Para la implementación, mantén una imagen de respaldo y verifica el soporte en los navegadores que tus

2:37 clientes realmente usan. El anuncio nombra a Chrome ciento cincuenta y cinco. Eso te da una versión objetivo, y tus análisis te dicen cuándo tu audiencia llega allí. Segunda pregunta respondida. Prueba tus imágenes reales antes de cambiar el flujo, y conserva la ruta de compatibilidad. Un formato de imagen que ahorra bytes es útil. Una migración que oculta tu botón de pago es una interpretación costosa del minimalismo. Mientras tanto, OpenAI publicó manuscritos matemáticos y artefactos

¿Qué publicó realmente OpenAI?

3:00 de prueba de apoyo el martes. El repositorio contiene setecientos veintidós manuscritos, agrupados en familias relacionadas. El recuento principal incluye argumentos complementarios y pruebas alternativas, así que lee lo que cada artículo realmente afirma. Muchos tienen pruebas formales en Lean, lo que permite a una computadora verificar deducciones matemáticas. Otros todavía esperan formalización, y OpenAI advierte explícitamente que

3:21 algunos resultados no formalizados podrían tener problemas. El repositorio entrega a los investigadores material que pueden inspeccionar y desafiar. El modelo permanece sin lanzar. OpenAI dice que cada resultado usó aproximadamente tres horas de cómputo de pensamiento equivalente a ChatGPT Pro en promedio. Eso describe el esfuerzo computacional. No te da ni una garantía de tiempo real ni un precio minorista por producir un

3:40 teorema. El lanzamiento se realizó tras consultar con un grupo asesor independiente de matemáticas, e incluye un proceso de revisión y citación. La academia recibe una nueva pila de tareas, además de la capacidad mucho más útil de señalar la página exacta que necesita ser arreglada. Los mantenedores de Lean recomiendan compilar pequeñas porciones a la vez. Incluso un avance matemático eventualmente encuentra al antiguo enemigo del software, lograr que la compilación termine.

¿Cómo bloquea dominios una placa de dos dólares?

4:03 Finalmente, un bloqueador de anuncios DNS de código abierto funciona con una pequeña placa de microcontrolador de dos dólares. El truco del creador es almacenar hashes de dominio ordenados en flash, para que la lista de bloqueo no tenga que vivir en la escasa memoria de trabajo. El proyecto informa aproximadamente cincuenta kilobytes de uso de RAM. Busca un dominio solicitado en la tabla flash, bloquea una coincidencia y reenvía otras consultas aguas arriba. Tu router puede adquirir un pequeño portero con una lista de invitados muy específica. El filtrado DNS funciona a nivel de dominio.

4:28 Los anuncios servidos desde el mismo dominio que el contenido útil pueden pasar desapercibidos, y los clientes que usan otro resolutor pueden eludirlo. Mantén tus expectativas más pequeñas que la placa, que es un objetivo de tamaño exigente. ¿Y el detalle sobre tus JPEGs existentes?

¿Pueden tus JPEGs existentes unirse al regreso?

4:40 JPEG XL soporta la transcodificación JPEG sin pérdidas, con una ruta para reconstruir el JPEG original. Eso le da a un antiguo archivo de imágenes una opción de migración sin otra generación de pérdida de calidad. Prueba las compensaciones de almacenamiento y entrega. Si prefieres leer esto antes que oírme decirlo, el diff llega a tu bandeja de entrada cada mañana, gratis en the daily diff punto dev, enlace abajo.

¿Por qué debería enviar el decodificador y probar la migración?

4:58 Así que el veredicto de hoy, SHIP IT. Yo enviaría el decodificador adicional porque el soporte del navegador da a los desarrolladores una opción real, y probaría la migración en nuestras propias imágenes. Suscríbete, pulsa la campana y dime en los comentarios si lo habrías sellado de forma diferente. Y eso es el diff de hoy. Soy Niko de Axrisi. Fusiona con responsabilidad.

Fuentes

1. Shipping JPEG XL in ChromeChrome for Developers
2. JPEG XL prototype and November 2022 removal discussionChromium Blink developers
3. Contemporaneous JPEG XL deprecation commentaryFree Software Foundation
4. The case against JPEG XL — competing-encoder benchmarkGianni Rosato
5. JPEG XL FAQ and reversible JPEG transcodingJPEG XL community
6. HTML picture element and fallback selectionMDN Web Docs
7. Progressive loading demoJPEG XL community
8. Distance versus effort visualizerJPEG XL community
9. Sharing AI progress in mathematicsOpenAI
10. Mathematical manuscripts and proof artifactsOpenAI on GitHub
11. Lean formalization library build notesOpenAI on GitHub
12. ESP32-C3 hash-in-flash DNS ad blockerM-Abozaid on GitHub