浏览器重新拥抱 JPEG XL：WebP Cloud 已默认支持 JXL

上个月我们看到了一则很有意思的新闻：Firefox 和 Chrome 都准备默认启用对 JPEG XL 的支持。

如果只看结果，这似乎只是浏览器又多支持了一种图片格式，但 JPEG XL 的经历其实颇为曲折。Chrome 曾经提供过实验性支持，却又在 2023 年将相关代码移除；Safari 17 在同年率先支持了 JPEG XL；到了 2026 年，随着 Rust 解码器 jxl-rs 逐渐成熟，Chrome 和 Firefox 又重新开始推进这项工作。

现在，我们也已经在 WebP Cloud 上默认启用了 JPEG XL 输出。和 AVIF 一样，JXL 会在后台异步生成，并在转换完成后自动加入图片格式选择，无需用户修改图片 URL 或额外调整配置。

浏览器为什么又开始支持 JPEG XL

JPEG XL 是一种免版税的现代位图格式，同时支持有损和无损压缩。除了压缩效率，它还支持渐进式渲染、Alpha 透明通道、动画、高位深、广色域和 HDR，也可以将已有的 JPEG 图片无损转码为 JXL，并在需要时还原出原始 JPEG 数据。

Chrome 最初曾经实验性地集成 JPEG XL，但随后认为生态采用度和维护成本不足以支持默认启用，并在 Chrome 110 前后移除了相关代码。这一决定当时引起了不少争议：缺少 Chromium 的支持，会直接影响网站、CDN 和图片工具采用一种新格式的意愿；而生态没有采用，又会反过来成为浏览器不支持它的理由。

Safari 17 在 2023 年加入了 JPEG XL 支持，不过使用的是 C++ 实现的 libjxl。Mozilla 此前同样关注过 libjxl 的代码规模和多线程 C++ 带来的攻击面，因此向 JPEG XL 团队提出了一个明确的要求：提供一个安全、快速、体积紧凑且兼容的 Rust 解码器。

后来 Google Research 开发了 jxl-rs，Firefox 和 Chrome 都开始围绕这个 Rust 实现推进集成。Mozilla 在 2026 年 8 月发布了「Intent to Ship: JPEG XL」，Chrome 也几乎同时提交了 Intent to Ship。

这里需要更新一下最初新闻中的时间表：Firefox 原计划从 157 开始默认启用 JPEG XL，但随后因为剩余工作比预期更久，将目标调整到了 Firefox 158；157 中仍然可以通过 Firefox Labs 或 image.jxl.enabled 手动开启。Chrome 则已经把 JPEG XL 解码支持列入 Chrome 155 Release Notes，同样采用 jxl-rs。

也就是说，截至本文发布时，Safari 已经默认支持 JPEG XL，Firefox 和 Chrome 的默认支持正在进入正式发布流程。JPEG XL 终于不再只是少数工具中的实验性格式，而是开始具备成为 Web 输出格式的现实基础。

JXL、AVIF 和 WebP 应该怎么选

WebP、AVIF 和 JPEG XL 都比传统 JPEG/PNG 更新，但这并不代表它们之间存在一个对所有图片都成立的排名。

根据 Mozilla 在 JPEG XL 发布说明中的对比，AVIF 在 Web 常用画质的照片上往往能够得到更小的文件，而 JPEG XL 在无损图片上更有优势。JPEG XL 的渐进式渲染也很有特点：图片还没有下载完成时，浏览器就可以先展示低清晰度的完整内容，再随着数据到达逐渐增加细节，而不是让用户一直面对一片空白。

这也是为什么我们不打算简单地说「以后全部使用 JXL」或者「JXL 一定比 AVIF 小」。图片的内容、是否有损、质量参数和编码器实现都会影响最终结果。更合理的方法是把多个候选格式都准备好，再为每次请求选择浏览器可以解码且体积更小的那个。

WebP Cloud 怎么支持 JXL

WebP Cloud 的用户不需要把网站中的 .jpg 或 .png 地址改成 .jxl，也不需要自己维护 <picture> 中的多套图片。例如原始地址仍然可以是：

https://example.com/images/demo.png

接入 WebP Cloud 后，访客访问的 URL 也继续保持相同的路径。WebP Cloud 会根据请求中的 Accept 判断浏览器明确支持哪些图片格式，并从原图、WebP、AVIF 和 JPEG XL 中选择浏览器支持且体积更小的版本，通过正确的 Content-Type 返回。

这套内容协商方式也和我们最近在「WebP Server Go 0.16.0 发布：更可靠的图片格式协商与 CDN 缓存」中介绍的方向一致：由浏览器明确声明能力，而不是依赖 User-Agent 猜测浏览器版本。

考虑到 AVIF 和 JPEG XL 的转换都比 WebP 更消耗计算资源，我们没有让 JXL 编码阻塞访客的首次请求，而是采用后台异步转换：

1. WebP Cloud 回源取得图片，并先完成当前请求需要的基本处理和快速格式转换。
2. AVIF 和 JPEG XL 等候选格式进入后台转换流程。
3. 在后台文件还没有准备好时，WebP Cloud 会安全地返回原图、WebP 或已经可用的 AVIF，而不会向浏览器发送一个尚不存在或无法解码的文件。
4. JXL 转换完成后，后续请求会自动把它加入候选集合；如果浏览器支持 JXL 且它的体积更小，就返回 image/jxl。

JXL 已经对所有 WebP Cloud 用户默认开启，已有缓存也会逐步在后台回填，用户不需要逐个清理缓存或重新发布图片。

一张真实图片的对比

我们用博客中的一张构建输出截图进行了测试，并通过 width=900 生成相同尺寸的缓存版本：

测试地址：https://p2k7zwb.webp.ee/libvips-cgo/build.png?width=900

测试时分别只在 Accept 中声明 PNG、WebP、AVIF 或 JPEG XL，并记录 WebP Cloud 实际返回的 Content-Type 和文件大小，结果如下：

在这张截图上，JXL 最终只有原图体积的 9.7%，比 WebP 小约 8.6%，比 AVIF 小约 30.5%。因此，当访客的浏览器声明支持 JPEG XL 时，WebP Cloud 会选择 JXL；如果浏览器只支持 AVIF 和 WebP，则会选择这张图片中体积更小的 WebP。

这个结果也很好地说明了为什么需要动态选择格式：虽然 AVIF 经常能获得很好的压缩率，但在这张截图上 WebP 反而比 AVIF 更小，而 JXL 又比二者都小。一张图片的结果不能代表所有照片、截图和插画，WebP Cloud 的目标也不是强制输出某个固定格式，而是替用户完成这些比较。

如果想自己验证，可以用 cURL 明确声明 JPEG XL：

curl -sS -D - -o /dev/null \
  -H 'Accept: image/jxl' \
  'https://p2k7zwb.webp.ee/libvips-cgo/build.png?width=900'

转换完成后，响应中可以看到：

Content-Type: image/jxl
Content-Length: 56641
X-Compression-Rate: 0.09
Vary: Accept

在后台转换尚未完成时，同样的测试可能暂时得到 image/png；这正是兼容回退在发挥作用。稍后再次请求，响应就会自动切换为已经生成的 image/jxl。

用户需要做什么

答案是：什么都不需要做。

JPEG XL 输出已经默认对所有用户开启。网站继续使用原来的图片地址，WebP Cloud 会在后台准备 JXL，并根据访客浏览器的支持情况和实际文件大小选择输出。现在尚不支持 JXL 的浏览器会继续收到 WebP、AVIF 或原图，不会出现图片无法显示的问题；随着 Chrome 和 Firefox 默认启用 JXL，更多访客会自然开始获得 JXL 版本。

我们在 2023 年加入 AVIF 时，采用后台转换来平衡压缩效率和实时请求性能；这次的 JPEG XL 支持延续了同样的思路。新格式不是用来取代所有旧格式的唯一答案，而是给每张图片多一个可能更合适的选择。

如果你正在使用 WebP Cloud，这个功能已经在后台为你工作。如果还没有使用，也欢迎登录 WebP Cloud Dashboard 创建 Proxy，让 WebP Cloud 自动处理图片格式转换、缓存和浏览器兼容问题。

参考资料

1. Intent to Ship: JPEG XL - Mozilla Hacks
2. Intent to ship: JPEG XL - Mozilla dev-platform
3. Firefox JPEG XL 发布目标调整到 158
4. Intent to Ship: JPEG XL - Chromium blink-dev
5. Chrome 155 Release Notes
6. Image file type and format guide - MDN
7. JPEG XL 官方网站