JPEG 存了十年，不用重压也能瘦 20%——Firefox 157 和 Chrome 这季度同时把 JPEG XL 默认打开了

存了十年的 JPEG 图片库，不用重新压一遍也能瘦 20%——这件事这两个月刚刚变成默认能力。

如果你手上有一堆老项目的图片，或者负责过图床/CDN 的图片管线，大概率听过「上 AVIF 吧」这句话。但真动手时总会卡在两个地方：一是老图都是 JPEG，重新编码一次就是有损再叠一层损；二是大图（Hero、Banner、长截图）的首屏体验还是差。JPEG XL（.jxl）这两个问题都能解，可惜过去几年它一直躺在 Safari 和实验性 flag 里，Chrome 2022 年还直接把支持删过。这个局面，2026 年第三季度正式翻篇了。

现在到底发生了什么

• Mozilla 8 月 24 日发布 intent-to-ship：Firefox 157（9 月底发布）在所有平台默认开启 JPEG XL 解码，不再需要去 Firefox Labs 手动勾选。
• Chrome 同步提交了 intent to ship，Blink 默认开启 JXL 解码；Mozilla 官方预计两家落地时间相差一周左右。
• Safari 从 17（2023 年）起就原生支持 JXL，但缺了渐进式渲染。
• 结论：今年之内 JXL 会在三大引擎全部默认可用，全球覆盖率从目前的 ~20-30% 冲到 85% 以上。

为什么拖了这么多年

不是技术不行，是安全账。JPEG XL 的参考解码器是大约 10 万行多线程 C++，Mozilla 明确表示不敢接下这么大一块攻击面——解码器直接处理来自公网的文件，一个内存错误就是沙箱逃逸级别的风险。

于是 Mozilla 做了一件不太寻常的事：公开向 Google Research 的 JPEG XL 团队下战书——用 Rust 写一个安全、够快、够小的解码器，我就发。这个解码器就是 jxl-rs。到 0.6.0 已经多线程化，Mozilla 内部跑大图基准时持平甚至超过 Safari 的 C++ 解码器。Chromium 也在 2025 年 11 月正式掉头重新接收这个 Rust 实现（Chrome 145 起回到 flag 后面）。

对前端来说，这条路径本身就是个信号：新编解码要进浏览器，Rust 重写正在变成事实门槛。 AVIF 走的也是同样的路子（Rust 化的 AV1 解码）。

JXL 和 AVIF 到底怎么选，别听口号看数字

Mozilla 自己在博客里给了一组同图对比（SSIMULACRA 2 感知质量分）：

• 中高质量（SSIMULACRA 2 = 62.8）：AVIF 116 KB，JXL 134 KB —— AVIF 更小
• 很高画质（= 80）：AVIF 227 KB，JXL 264 KB —— AVIF 更小
• 无损：AVIF 1.76 MB，JXL 1.45 MB，无损 WebP 1.55 MB —— JXL 赢
• 截图类内容无损：AVIF 164 KB，JXL 92 KB，WebP 96 KB —— JXL 明显赢

再叠一组第三方实测（同一张 4032×3024 手机照片，「视觉等同」画质）：

• JPEG (q92) 2.8 MB → WebP (q80) 1.1 MB（-61%）→ AVIF (q60) 0.78 MB（-72%）→ JXL (effort 7) 0.92 MB（-67%）
• 编码耗时（单核）：JPEG 0.05s / WebP 0.18s / JXL 0.32s / AVIF 1.4s（AVIF 默认档比 JPEG 慢 7-10 倍）

所以判断标准很清晰：

• Web 质量的摄影图 → AVIF 仍然更小，继续用；
• 无损、大尺寸、截图/UI 图、HDR → JXL 更小，而且只有它支持无损 JPEG 转码；
• 编码成本敏感 → JXL 比 AVIF 快 4 倍以上，批处理管线能省下真实时间。

对我们最实用的一个能力：无损重压现有 JPEG

JXL 能把现有 JPEG 直接无损转码，体积大约降 20%，而且可以逐比特还原回原 JPEG。这是目前唯一一个现代格式能做到的事。

意味着你那条「旧图全部重编码 → 有损叠有损」的顾虑不存在了：老图库可以原地转 JXL，画质零损失，还省 20% 存储和传输。AVIF 做不到这点，它只能从源图重编。

大图首屏：渐进式渲染才是真痛点

JXL 的渐进式解码意味着图片一边下载一边渲染：Mozilla 的演示图完整 135 kB，但没有下载完几个 kB 时，用户已经能看出画面主体。对超大 Banner、长截图、移动弱网，这直接决定用户「觉得快不快」。

Safari 的 JXL 实现恰恰缺了这一块，所以才被 Mozilla 单独拎出来对比——这也是它推 Rust 实现时特意加进去的能力。

可落地的下一步

1. 先别急着切主格式。等 Chrome 默认开启落地后（预计几周内），再评估；现在可以先用 <picture> 做渐进增强：

   <picture>
     <source srcset="hero.jxl" type="image/jxl">
     <source srcset="hero.avif" type="image/avif">
     <source srcset="hero.webp" type="image/webp">
     <img src="hero.jpg" alt="..." width="1600" height="900" decoding="async">
   </picture>

2. 优先给两类图升 JXL：一是存量 JPEG 归档（无损转码省 20%），二是 200 KB 以上的 Hero/长截图（吃渐进式渲染的红利）。
3. 编码侧换工具：cjxl（libjxl 官方 CLI）或 sharp 的 JXL 支持；批处理时 JXL 比 AVIF 快得多，CI 时间能明显下降。
4. 别信单一基准：不同内容（平坦色块 vs 高频细节）差异能到 10-20%。拿你自己站点代表性的 20 张图，在目标画质档位跑一遍再定策略。

一句话判断标准

存量 JPEG 和有损转码需求 → JXL；纯 Web 质量摄影图 → 继续 AVIF；两者都用 <picture> + WebP/JPEG 兜底，等 Chrome 默认开关一落地，把 JXL 提到第一个 <source> 就行。