「照片小一半:Google 把弃用三年的图片格式装回了 Chrome」

「照片小一半:Google 把弃用三年的图片格式装回了 Chrome」

ChromeJPEG XLRustWeb生态

数据源:官方博客与社区讨论

2026 年 10 月 6 日,谷歌通过开发者博客发出了一条引发大量讨论的更新通告:从 Chrome 155 版本开始,浏览器将正式原生支持解码 JPEG XL 图片格式。三年前,在 Chrome 110 的发布节点上,这个被内部判定为缺乏生态号召力的格式被弃用,随后 Chromium 也移除了对它解码支持。如今,这项技术以纯 Rust 重写解码器的形态重返核心产品线。随着火狐(Firefox)计划在十月份的稳定版中同步跟进,加上早早入局的 Safari,JPEG XL 即将摆脱小众标签,完成对多数主流浏览器的广泛覆盖。

压缩率打不开的门,内存安全能开

JPEG XL 在账面数据上从来都不处于下风。对比早已普及的传统 JPEG 格式,它能将压缩率直接拔高 30% 到 50%,同时还具备 HDR 支持与无损转码两项核心能力。网站上堆积如山的旧版 JPEG 图片,可以做到无损转换成新格式,并在需要时一字不差地还原回去。这种级别的传输效率提升,能显著减少手机终端用户的加载白屏时间,同时也直接帮助海量分发图片的云端服务商削减掉昂贵的带宽成本。

JPEG XL 官方主视觉图 图:JPEG XL 官方主视觉图。来源:JPEG XL 官方站

当年挡住它进入 Chrome 渲染引擎的真正防御机制,其实是潜藏在底层代码里的内存漏洞风险。浏览器图像解码器需要直接吞下并处理来自网络的不受信任二进制流,这里向来是黑客寻找高危漏洞的高发地段。用传统 C++ 写的解码器历史上容易出越界读、堆溢出、释放后使用这几类漏洞。这一次,Chrome 开发团队从根源上转换了思路,直接集成了名为 jxl-rs 的纯 Rust 实现版本。用内存安全语言重写这块处理脏数据的核心组件,把防线直接向前推到了编译阶段,远比依靠沙箱隔离做二级防御要有效得多。

速度和安全不必二选一

消除内存隐患是有代价的。在图像解码这种锱铢必较的计算密集型任务里,额外的安全检查往往会拖慢指令执行效率。现代编解码器必须重度依赖 SIMD(单指令流多数据流)技术,才能在多核架构下跑满数据吞吐量。早前的 Rust 生态在处理 SIMD 时遇到了难以逾越的瓶颈,开发者想在安全作用域内调用底层处理器指令,当时还没有稳定的特性可用,只能写 unsafe。

为了搬开这块横亘在性能与安全之间的绊脚石,Rust 社区合力将 target_feature_11 特性推进到了稳定状态,直接打通了安全调用 SIMD 指令的通道。借助这个底层设施更新,开发团队照着 C++ 领域的 Highway 库,量身打造了一套高度匹配的 SIMD 抽象层 jxl_simd。结果是解码器既没有 unsafe 区块,又能跨平台把处理器的 SIMD 用满,速度追平了非内存安全的传统实现。

互操作测试压住了格式站队

一项新标准想要最终落地,必须闯过各家浏览器厂商互不买账的利益博弈。在 2026 年的 Web Platform Tests Interop 提案中,JPEG XL 罕见地成了开发者群体呼声最高的待办项。Chrome 团队参与了 Interop 2026 的 JPEG XL 专项调查,把各类边界情况都纳入测试覆盖。当测试用例能证明各家浏览器按同一标准渲染出相同结果时,「这个格式没法互操作」这个理由就站不住了。

Q85 质量档下与 JPEG 等格式的压缩效率对比 图:Q85 质量档下与 JPEG 等格式的压缩效率对比。来源:JPEG XL 官方站

关于格式的站队从来没有停过。支持方把 JPEG XL 看成通用方案,认为它可以替代 AVIF、PNG、WebP,甚至部分 TIFF 场景。反方引用《The case against JPEG XL》,认为典型网页的有损压缩里 AVIF 几乎总是更好;这篇反对意见随即又被反驳,指其没有给出两种格式的确定性对比,也没考虑两边编码器在研发投入上的差距。Chrome 的处理办法是把选择交给开发者自己验证:要超高保真、要细粒度渐进解码的摄影图像用 JPEG XL,常规有损压缩继续推荐 AVIF。

决定权从内部路线图回到社区

在渐进式加载这种能大幅改善首屏体验的细分领域里,各家的推进步伐依然存在错位。目前 Chrome 和 Firefox 已经在非 Android 版本中默认开启了这项功能,而最早引入该格式的 Safari 却至今没有释放出原生 libjxl 的渐进加载潜力。博客的署名作者是 Luca Versari、Moritz Firsching 和 Philip Jägenstedt,这篇文章讲的重点也不是压缩算法本身。

一个被判出局的格式能重新上桌,靠的是三件事同时到位:解码器可以用内存安全的语言重写,重写之后速度不掉,跨浏览器的行为有一致性测试兜着。三年前那份弃用决定的前提,被这三条逐条抽掉了。

参考链接:

  • Chrome for Developers 博客
  • jpegxl.info 官方站
  • Interop 2026 JPEG XL Investigation
  • Hacker News 讨论
  • 《The case against JPEG XL》