谷歌 Chrome 155 正式启用 JPEG XL，新网页图像格式加速普及

根据简鹿办公了解，目前谷歌 Chrome 155 已发布，标志着 JPEG XL（.jxl）这一新一代图像格式正式进入主流浏览器生态。与以往只停留在实验阶段不同，Chrome 155 不仅引入了 JPEG XL 解码能力，还将其与 Rust 编写的 jxl-rs 解码器深度集成，从而在压缩效率、图像质量和内存安全性之间取得了更平衡的方案。

JPEG XL 为何值得关注？

JPEG XL 被设计为传统 JPEG 的现代化替代方案。它保留了 JPEG 的广泛兼容性优势，同时在多个维度上进行了升级。相比传统 JPEG，JPEG XL 能够提供约 30%—50% 的额外压缩效率，并且支持无损压缩、高动态范围、广色域、高位深、动画以及渐进式解码。

其中，渐进式解码是 JPEG XL 的一个亮点。用户不必等待完整图片下载完成，只需获取少量数据即可辨识图像主体，这对弱网环境、移动端浏览以及高分辨率图片展示都有明显帮助。

另一个独特能力是“无损 JPEG 转码”。已有 JPEG 文件可以直接转换为 JPEG XL，而不会损失原始质量；在需要时，它们还能被无损还原为原始 JPEG。这意味着网站可以在不重新拍摄或重新导出的情况下，直接降低图片体积和存储成本。

AVIF 和 JPEG XL 如何取舍？

谷歌并未将 JPEG XL 视为 AVIF 的完全替代品，而是建议两者根据场景互补使用。

AVIF 更适合带宽敏感场景：当页面包含大量图片、需要更快加载速度，或希望获得更高压缩比时，AVIF 仍然是一个高效选择。

JPEG XL 更适合高保真场景：对于摄影作品、HDR 图片、需要无损压缩或渐进式加载体验的页面，JPEG XL 往往更具优势。

简单来说，AVIF 更像“轻量高效型”格式，JPEG XL 则更接近“高画质友好型”格式。

为什么改用 Rust 解码器？

图像解码器一直是浏览器中最容易受到攻击的组件之一。传统 C++ 解码器虽然性能成熟，但也更容易出现越界读取、堆溢出、释放后使用等内存安全问题。

Chrome 155 采用的 jxl-rs 是一个纯 Rust 实现的 JPEG XL 解码器。Rust 的内存安全特性可以在编译阶段减少许多传统语言中的安全隐患。与此同时，谷歌通过 SIMD 指令优化、SIMD 抽象层构建以及性能调优，使 Rust 解码器在保持安全性的同时仍具备较高解码效率。

谷歌还提到，团队在开发过程中使用了 AI 代码审查和模糊测试，目前未发现与内存安全相关的问题。这也说明，现代浏览器在引入新格式时，已经不再只关注压缩率，而是把安全性、性能和跨浏览器兼容性放在同等重要的位置。

JPEG XL 的生态正在加速成熟

JPEG XL 的浏览器支持之路并不平坦。Chrome 曾在 2022 年前后移除过实验性 JPEG XL 支持，一度让该格式的前景蒙上阴影。但近年来，Safari、Firefox 和 Chrome 相继加入支持阵营，尤其是 Chrome 155 和 Firefox 157 都默认启用 JPEG XL 解码后，开发者在网页中使用 .jxl 图片的兼容性顾虑明显降低。

除了浏览器，JPEG XL 也在更多专业场景中获得应用。例如，Adobe DNG 格式已支持将 JPEG XL 作为 RAW 数据的编码载体；医疗影像标准 DICOM 也引入了 JPEG XL 传输语法；iPhone 16 Pro 系列的 ProRAW 同样支持以 JPEG XL 保存照片。这些变化意味着 JPEG XL 不再只是网页图像格式，而正在向摄影、医疗、出版和云存储等领域扩展。

对开发者和普通用户的意义

对普通用户来说，JPEG XL 的普及可能不会带来直观的界面变化，但网页图片加载速度、数据流量消耗和高画质图片体验会逐步改善。对开发者而言，Chrome 155 之后，JPEG XL 已经可以作为高保真图片场景的正式选项之一。

如果网站主要面向现代浏览器，并且重视摄影图片质量、HDR 显示或渐进式加载体验，可以开始评估 JPEG XL；如果更关注极致压缩率、移动端首屏加载速度和更广泛的兼容性，AVIF 仍然是稳妥选择。随着 Chrome、Firefox 和 Safari 共同支持 JPEG XL，网页图像格式的选择正在从“单一替代”走向“多格式协同”。