Google trae de vuelta JPEG XL a Chrome

Lo que cubre este video

• El anuncio de Chrome se publicó el 6 de octubre de 2026 y nombra a Chrome 155. No establece que cada visitante del sitio web ya ejecute una versión compatible.
• Google atribuye los persistentes comentarios de los desarrolladores y el proceso de Interop. El decodificador jxl-rs utiliza Rust y operaciones vectoriales optimizadas, mientras que permanecen pequeñas áreas no seguras examinadas y la zona de pruebas del navegador.
• La mejora de compresión anunciada por Google del 30 al 50% utiliza JPEG como línea de 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érdida probado. Él desarrolla herramientas AVIF en competencia; su resultado y la afirmación de Google basada en JPEG miden diferentes comparaciones.
• 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 sigue sin ser lanzado, y las cifras de computación equivalentes a Pro no son un precio minorista ni una garantía de tiempo transcurrido.
• El creador del ESP32-C3 informa aproximadamente 50 KB de uso de RAM al almacenar hashes de dominio ordenados en la memoria flash. El bloqueo a nivel de DNS tiene limitaciones de mismo dominio y resolución alternativa; las colisiones de hash pueden bloquear en exceso. Los resultados de hardware no se midieron independientemente para este episodio.

Transcripción traducida

Traducido de la narración original en inglés. El audio y los subtítulos disponibles son 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 le ayudó a entrar. En este video, ¿por qué Google revirtió su curso? ¿Y deberías cambiar tu pipeline de imágenes? Es miércoles, siete de octubre, y este es The Daily Diff. Ten en cuenta un detalle. 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ó una insuficiente interés 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 Interop. La gente que pedía esto siguió pidiendo, y Google ahora señala las pruebas de 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 mayor cambio de implementación es un decodificador llamado jay ex ell R S, escrito en Rust. Los decodificadores de imágenes ingieren archivos complicados suministrados 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 la zona de pruebas, y la implementación todavía contiene pequeñas áreas no seguras 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 con 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 tu 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 en septiembre donde los codificadores modernos de avif superaron a JPEG XL en su rango de fidelidad probado. Él trabaja en herramientas avif de la competencia, así que ten en cuenta ese incentivo junto a los gráficos. Estas comparaciones usan diferentes bases.

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 pipeline, y preserva 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 de prueba de apoyo

¿Qué publicó realmente OpenAI?

3:00 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 las deducciones matemáticas. Otros aún esperan la 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 sigue sin ser lanzado. OpenAI dice que cada resultado utilizó aproximadamente tres horas de computación equivalente a ChatGPT Pro en promedio. Eso describe el esfuerzo computacional. No te da una garantía de tiempo real ni un precio minorista por producir un

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

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

4:03 Finalmente, un bloqueador de anuncios DNS de código abierto se ejecuta en una pequeña placa de microcontrolador de dos dólares. El truco del creador es almacenar hashes de dominio ordenados en la memoria flash, para que la lista de bloqueo no tenga que residir en la escasa memoria de trabajo. El proyecto reporta aproximadamente cincuenta kilobytes de uso de RAM. Busca un dominio solicitado en la tabla flash, bloquea una coincidencia y reenvía otras consultas río 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 utilizan otro resolvedor 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 admite la transcodificación JPEG sin pérdidas, con una ruta para reconstruir el JPEG original. Eso le da a un archivo de imágenes antiguo una opción de migración sin otra generación de pérdida de calidad. Prueba las ventajas y desventajas de almacenamiento y entrega. Si prefieres leer esto que oírme decirlo, el "diff" llega a tu bandeja de entrada cada mañana, gratis en the daily diff dot dev, enlace abajo.

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

4:58 Así que el veredicto de hoy, ENVÍALO. Yo enviaría el decodificador adicional porque el soporte del navegador les da a los desarrolladores una opción real, y probaría la migración en nuestras propias imágenes. Suscríbete, dale a la campana y dime en los comentarios si lo habrías sellado de manera diferente. Y esa es la diferencia 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