JPEG XL（简称“JXL”）是图像压缩圈子里最能让人吵起来的话题。技术上说，它是 JPEG 的正式升级，比 WebP 通用更强，还有 lossless JPEG 重编码这种让运维团队两眼发光的功能。但 2023 年被 Chrome 拒绝之后，它就变成了一道裂痕——一边是不认同这个决定的工程师，另一边是觉得没道理为一个没用的东西多招一个兼容性负担的浏览器厂商。

最近一个 Rust 解码器被写进了 Firefox 和 Chrome，JXL 看起来有回潮的迹象。但 Gianni Rosato 不买账。他写了一篇长文解释为什么不。背景值得提一句：他是压缩工程师，干过 AVIF 优化的活，也见过 JXL 的两位核心作者 Jon Sneyers 和 Jyrki Alakuijala。他说他写这篇东西不是站队，是对当前状态的一次实证审视。

论点核心很简单：在 Web 场景下，JPEG XL 没什么比 AVIF 更强的地方。而它以前有过的优势，现在一个个被追平了。

Lossless 不是救命稻草。Web 上 lossless 图片的体量极小，JXL 在这块确实比 lossless WebP 小约 12%，但代价是 33% 更长的解码时间。而且这个测试样本不具代表性——157MP 照片和 27MP 书籍图片跟网页几乎无关。用 12% 的文件大小优势去换浏览器适配的阵痛，不值得。

Lossy 压缩效率输了。他给出了 CVVDP、MS-SSIM、SSIMULACRA2 三张图。AVIF、WebP、甚至未发布的 Halide Compression 新编码器 Aperture 在全部高质量区间都把 libjxl 甩在后面。差距大到他说我不信有什么隐藏的感知优化能翻转这几个图。AVIF 的 libaom 在 tune iq（感知优化）和 tune SSIMULACRA2（指标优化）之间只差两三个点，而 libjxl 要追的不是两个点，是一大段。

技术原因拆得也很具体。JXL 没有方向预测模式，边缘保持弱，它的替代方案 splines 理论上可行但至今没有可用的 PoC。没有去块滤波器，依然有蚊噪问题。XYB 色彩空间被过度吹捧，libjxl 靠对 B 通道大量量化省比特，颜色保持做得差。非摄影图片表现差，patches 机制开销太大了——在 libjxl 中 effort 7 以下默认不开启。

解码速度不忍直视。他在 M5 Pro 上跑解码对比，WebP 比 JXL 快 10 倍以上。有个社区成员做了个 1,918 字节的 JXL 图片，prime wall，在 Rust 解码器上花了 17.43 秒才解完——因为编码器允许在解码时计算素数到 33,599。而那个 Rust 解码器正在进入 Chrome 和 Firefox。Safari 原生支持 JXL，有人已经在低端苹果设备上用这种图片做 DoS 了。

渐进式渲染更是翻车。JXL 社区常用这个来对标 AVIF，但 AVIF 实现了渐进解码后，在 2-3% 的加载量就能显示出可用图像，JXL 这边连 Safari 都不支持。

社区对该话题的讨论异常激烈。Chrome 的 Jake Archibald（jaffathecake）表示 lossless 图片在 Web 上极其小众，且 lossless WebP 性能已经很接近 JXL。libjxl 贡献者 janwas 说作者引用的渐进式对比不公平——AVIF 的第一帧画面比 JXL 大 4 倍。作者回得很直接：JXL 就是难优化，没精力花这个时间。

最核心的矛盾不在技术本身。JXL 是为所有人做一切的规格——4096 通道、任意深度、渐进解码、JPEG 重编码——但 Web 需要的只是 4 通道、合理的 HDR、快速解码、没有安全漏洞。Rosato 补了一段回头判：3 年半前他说想要一个 AVIF 和 JXL 共存的 Web，现在他说 AVIF 已经覆盖了整个质量区间，那点优势没有了。

他承认 JXL 在 Camera RAW、医学影像、个人归档这类场景下比 AVIF 强得多。但在浏览器里，它是一套解决了一个已经不存在的问题的方案。每多一个图像编码器，就多一层兼容性负担。

来源：

• The case against JPEG XL — Gianni Rosato