时隔近四年,Google 终于在浏览器图像格式的漫长拉锯中画下转折句号。2026 年 10 月 6 日,Chrome 团队宣布自 Chrome 155 起正式支持 JPEG XL(.jxl)图像解码。对于苦等生态统一的前端工程师和摄影平台来说,这看似是一场社区反馈推动下的态度妥协,但决定这起回归的真正变量不是舆论,而是底层代码安全架构的重塑。

Chrome 曾在 2022 年 12 月发布的 Chrome 110 中彻底移除了实验性 JPEG XL 支持,当时官方给出的理由是维护负担过重、软硬件生态支撑不足,并建议有需求的开发者使用 WebAssembly 替代。这项决定一度引发 Shopify 等电商平台与开发者社区的强烈抗议。此次 Chrome 能够正式接纳 JPEG XL,关键在于 Google Research 联手开源社区,用纯 Rust 语言打造了全新的解码器 jxl-rs,解决了困扰浏览器数十年的内存攻击隐患。

JPEG XL 在 Chrome 浏览器中的四年技术演进轨迹 2022年12月 (Chrome 110) 移除实验性 C++ 解码支持 认为生态不足、维护负担大 Safari 17 原生支持 苹果先行入局 (C++ 核心) 生态割裂倒逼 Rust 重构 2026年 (Chrome 155) 集成纯 Rust 解码器 jxl-rs 跨引擎共识达成正式推送

从一刀切移除到用 Rust 破局

图像解码器历来是现代浏览器中最脆弱、最容易遭到定向渗透的攻击面。它们必须直接处理来自不可信网络环境的复杂二进制数据,并运行在渲染管线之中。过去基于 C++ 编写的解码实现,常年受到越界读写、堆溢出以及释放后使用等内存安全漏洞的侵扰。即使浏览器采用沙盒机制做纵深防御,直接由底层引入一个庞大且未经验证的 C++ 解析库依然代价高昂。

当年 Chrome 舍弃 JPEG XL,本质上是拒绝继续为一个边界复杂的 C++ 解码组件承担安全连带责任。破局的钥匙是 Google 与社区重写的 jxl-rs。为了在 Rust 中压榨出不输给 C++ 的解压速率,工程团队推动了 Rust 语言内部 target_feature_11 特性的稳定化,使代码在无需大量 unsafe 逃逸的情况下调用现代处理器的 SIMD 指令集。在此基础上,团队参考原 C++ 参考实现中的 Highway 库,搭建起抽象加速层 jxl_simd。

在贯穿开发全流程的模糊测试与自动化审查中,jxl-rs 实现了零内存安全缺陷的记录。根据开发者 Luca Versari 维护的性能看板,jxl-rs 的解码速度已经高度逼近、甚至在部分硬件平台上超过了传统 C++ 参考实现 libjxl。安全与性能的双重闭环,扫清了工程落地的最大阻碍。

浏览器并非抵触一种更紧凑的图像格式,而是抵触用脆弱的内存安全成本换取压缩率。
安全与性能解耦:jxl-rs 解码管线架构 不可信网络输入 任意 .jxl 外部资源 高危二进制解析流 Rust 内存安全底座 target_feature_11 稳定化 jxl_simd 硬件加速层 零内存越界风险验证 渲染管线与画质 跨区域无锁处理流 全色深 HDR 输出

跨浏览器阵营的妥协与测试盲区

JPEG XL 的回归不是 Chrome 的独角戏。2026 年 8 月 24 日,Chromium 社区正式发布针对原生 image/jxl 解码的 Intent to Ship,计划面向全量用户推送。几乎在同一时刻,Mozilla 也在 Firefox 中发起了同样基于 Rust 解码器的 Intent to Ship。加上自 Safari 17 就已原生支持该格式的苹果 WebKit 阵营,现代三大排版引擎在图像协议层终于重新达成共识。

但阵营齐聚并不代表标准完全成熟。一个常被忽略的细节是,在跨浏览器标准协同项目 Interop 2026 中,JPEG XL 并没有被直接列为正式的核心聚焦点(Focus Area),而是作为一个调研项目(Investigation)推进。浏览器厂商真正争论的分歧,集中在跨引擎测试的覆盖深度以及精细渐进式解码(progressive rendering)带来的渲染侧开销。

苹果 Safari 采用的是原生的 C++ 解码管线,而 Google 与 Mozilla 则押注 Rust。尽管渐进式渲染能够让高分辨率图片在网络传输过程中由模糊快速转为细腻,但在不同引擎里,多次重绘可能造成不可忽视的主线程锁死或闪烁问题。标准制定团队仍在密集排查边界工况,确保统一的标准不会在低配终端上引发卡顿。

算力转移陷阱与真实落地代价

面对主流浏览器的接纳,图像管线从传统的 WebP 或 AVIF 转向 JPEG XL 是否是一笔稳赚不赔的买卖,取决于开发者所处的业务场景。

JPEG XL 面对 WebP 和传统 JPEG 的优势无可争议:它能带来 30% 至 50% 的体积缩减,原生支持 HDR 与广色域,并允许对老旧 JPEG 资产进行无损重新转码而完全不丢失历史元数据。格式倡导者 Cloudinary 的主观画质对照研究显示,在同等主观画质下,JPEG XL 的文件体积普遍比 AVIF 小约 10% 到 15%。

但带宽节约的代价往往被悄悄转嫁给了客户端硬件。AVIF 脱胎于 AV1 视频编码生态,已逐步吃到了跨平台移动 SoC 提供的硬件辅助解码红利。相比之下,JPEG XL 目前几乎完全依赖 CPU 软件解码。

  • 风险.根据 Blink 开发讨论记录,JPEG XL 的软件解码耗时可能显著慢于成熟的 WebP。如果内容平台为了极度压榨服务器流出带宽,全站大面积推送无损或高保真 JXL 文件,不仅可能加剧入门级手机的排版卡顿,还会把流量成本转化为用户的电池功耗代价。
  • 建议.对于 Shopify 这样对色彩保真度、摄影细节和渐进显示有极高要求的电商展示平台,引入 JPEG XL 是显著的技术收益;但对追求超低延迟信息流和超快首屏的移动端应用,在全景基准测试出炉前,盲目替换掉拥有成熟硬件解码支撑的生态格式依然是一场冒险。

随着 Chrome 155 落地,JPEG XL 的技术抗辩已经胜出,接下来留给工业界的考题,是端侧算力账本的真实平衡。