昨天刷 Hacker News，看到 Chrome 官方博客发了篇 "Shipping JPEG XL in Chrome"，评论区 296 条，热度不小。一个图片格式而已，至于这么多人激动吗？

至于。因为四年前，这个格式差点被 Google 自己亲手埋掉。

一、四年前的处决

2022 年 11 月，Google 在 Chromium 里正式移除了 JPEG XL 的支持。当时给出的理由是"缺乏令人信服的生态系统收益"——翻译成大白话就是：我们觉得没必要。

这个决定在当时引发了不小的波澜。要知道 JPEG XL 本身就是 Google 团队和 Cloudinary 联合推动的，2019 年立项，2021 年成为 ISO 国际标准（ISO/IEC 18181）。从立项到被砍，前后不过三年。

我当时看到这个新闻的第一反应是：Google 在推 AVIF。AVIF 基于 AV1 视频编码，是 Google 主导的开放媒体联盟（AOM）的孩子。JPEG XL 虽然也有 Google 人参与，但不是"亲儿子"。在浏览器厂商的格式战争里，血统比技术更重要——这跟我之前理解的"技术好就会赢"完全不是一回事。

二、JPEG XL 到底好在哪

先说硬数据。JPEG XL 在同等视觉质量下，文件大小比 JPEG 平均小 60%。这个提升幅度已经很大了，但还不是最关键的。

真正让我觉得有意思的是它的无损转码能力。你已有的 JPEG 图片，可以无损转换成 JPEG XL，平均再省 20% 空间。而且这个过程是可逆的——需要的时候还能还原出原始 JPEG。这意味着什么？你不需要把整个图片库重新编码一遍就能享受新格式的红利。

我之前在做产品列表页性能优化时，试过把 JPEG 全量转 WebP。工作量不是最大的问题，最大的问题是过渡期——有些用户的浏览器不支持 WebP，你得同时维护两套图片，CDN 存储成本翻倍，图片处理服务要加判断逻辑，运维复杂度直线上升。如果当时有 JPEG XL 的无损转码能力，这个迁移成本会低很多。

渐进式解码也值得一提。JPEG XL 的设计里有个"显著性优先"的渐进加载策略——先传视觉上重要的区域，再补细节。只需加载 1% 的数据就能看到一张可辨识的图片。这对电商详情页那种大图场景是有实际意义的，用户看到首屏内容的时间可以提前几百毫秒。

至于 AVIF，它确实在压缩率上跟 JPEG XL 差不多，但编码速度慢得多。我见过一个 benchmark，同等质量下 AVIF 的编码时间是 JPEG XL 的 3-5 倍。对于 UGC 平台这种需要实时处理大量用户上传的场景，编码速度直接影响服务器成本和用户体验。

三、技术好不等于赢

图片格式战争的历史，本身就是一部"技术好不一定赢"的教科书。

JPEG 2000 技术上全面碾压 JPEG，但它需要更多内存、计算更复杂、硬件支持不到位。二十年过去了，你在网上几乎看不到一张 JPEG 2000 图片。WebP 刚出来的时候也被认为会取代 JPEG，结果因为早期只被 Chrome 支持，Firefox 到 2019 年才加上，Safari 更是拖到 2020 年。那十年里，WebP 在前端的渗透率远不如大家想象的高——很多团队只在 CDN 边缘层做转换，源站还是 JPEG。

AVIF 现在面临的处境类似。压缩率好，但硬件解码支持不全面，尤其是中低端 Android 设备。我之前在一个低端安卓机上测 AVIF 解码，一张 4K 图片的解码时间比 JPEG 多了将近 200ms。用户感知到的不是"图片更清晰了"，而是"图片加载变慢了"。

格式之争的本质，从来不是谁压缩率好 2% 的问题，而是谁的生态链更完整——编码器、解码器、CDN、CMS、浏览器、操作系统，每一环都得跟上。JPEG 之所以活了三十年，不是因为技术好，而是因为它无处不在。你甚至能在 2001 年的 Nokia 手机上解码 JPEG。

四、反转是怎么发生的

2022 年 Google 砍掉 JPEG XL 之后，事情并没有按预期发展。

Apple 在 2023 年的 Safari 17 里加上了 JPEG XL 支持，而且不是实验性的，是直接作为默认格式支持。iPhone 15 Pro 的 ProRAW 格式也开始用 JPEG XL 做无损压缩。这个信号很重要——Apple 选择 JPEG XL 而不是 AVIF 作为下一代照片格式，等于给整个生态打了一针强心剂。

与此同时，社区对 Google 的反对声一直没停。Change.org 上有个请愿书收集了数万个签名，要求 Google 恢复 JPEG XL 支持。开源社区里的 libjxl 项目也没有因为 Google 撤资源而停摆——Cloudinary、GNOME、KDE 等组织持续贡献代码。到 2024 年，libjxl 的编码性能已经比 2022 年提升了约 40%。

最终推动 Chrome 回头的，可能不完全是社区压力。Apple 设备在 Web 流量中的占比、HDR 和广色域图片的普及趋势、以及 JPEG XL 在专业影像领域的快速采纳，这些因素叠加起来，让 Google 重新评估了"生态系统收益"的判断。

有时候我觉得技术决策跟投资很像——2022 年 Google 认为 JPEG XL 没有回报前景，四年后发现市场变了，果断止损。这不丢人，反而说明他们的决策机制是能响应外部变化的。

五、前端该怎么接

Chrome 支持 JPEG XL 之后，"picture 元素"策略变得更实际了。你可以用 <picture> 标签做渐进增强：先放 JPEG XL，不支持就降级 WebP，最后兜底 JPEG。

但这里有个坑。我之前试过用 <picture> 做多格式降级，发现某些 CDN 的 Accept 头判断逻辑不够精细，把不支持 AVIF 的请求也返回了 AVIF，导致老浏览器显示破图。排查这个问题花了大半天，最后是在 CDN 层加了一层 Vary: Accept 头才解决。多格式策略的复杂度不在前端，在 CDN 和源站的协商逻辑。

另一个实际考量是团队认知成本。我身边的人，大部分能说出 WebP 比 JPEG 小，但不知道 JPEG XL 是什么。格式迁移的阻力不只在技术，还在人的认知惯性。一个格式如果团队里没人了解，推动起来比技术上难十倍。

这个问题我自己也还在想：等到 JPEG XL 全面铺开，我们到底是该主动迁移，还是等新格式成为默认选项再跟进？可能取决于你的图片量级和性能预算。一个日活百万的产品，每张图片省 20KB，CDN 带宽节省的年化成本可能是六位数。但如果只是一个内部管理系统，JPEG 够用就行，没必要折腾。

写这篇文章的时候我翻了一下自己三年前在技术群里说过的话，当时信誓旦旦地说"JPEG XL 凉了，AVIF 会赢"。现在看来，格式战争比我想的复杂得多，不到最后一刻，真不好说谁赢。可能也没有赢家——JPEG、WebP、AVIF、JPEG XL 四种格式共存十年，大概才是最终结局。