JPEG XL 与 AVIF：Web 场景下谁才是下一代图像格式

Web 图像格式的竞争从未像现在这样胶着。JPEG XL 曾被寄予厚望，却在 Chrome 的路线图中被搁置；AVIF 凭借先发的浏览器支持迅速铺开，但编码速度与工具链成熟度始终被开发者吐槽。近期在 Hacker News 上围绕「JPEG XL vs. AVIF for web use-cases」的讨论再次把这个问题推到台前，评论区从压缩效率、渐进式解码一路吵到生态支持，几乎涵盖了选型时真正会踩到的每一个坑。

两套格式的技术底色

AVIF 基于 AV1 视频编码的帧内压缩，本质上是从视频编解码器「降维」到静态图像。这带来的好处是压缩率相当激进，在同等主观质量下往往能把文件体积压到 WebP 的六成左右。代价则体现在编码端：AV1 编码器复杂度高，构建耗时较长，批量处理大图时对 CPU 的占用不容忽视。

JPEG XL 的路线完全不同。它同时保留了对传统 JPEG 的「无损转码」能力——已有的 JPEG 文件可以在不损失画质的前提下重新封装，体积直接缩小约 20%。这意味着存量图片库不需要重新编码就能获得收益，这是 AVIF 无法提供的迁移路径。此外 JPEG XL 原生支持渐进式解码和更高的位深，从设计上就更贴近「取代 JPEG」这个目标。

讨论中一个被反复提及的点是：两者并非同一维度的竞争。AVIF 更像是「把视频编码塞进图片容器」，JPEG XL 则是「重新设计 JPEG 的下一代」。

AV1 帧内压缩：AV1 是由开放媒体联盟（AOMedia）主导的下一代视频编码标准，其帧内编码（intra-frame coding）指的是不依赖前后帧、仅利用当前帧内部空间相关性来压缩单幅画面的模式。AVIF 正是把这一模式「挪用」到静态图像上：编码器把每张图当作只有一帧的视频来处理，从而继承 AV1 成熟的方向性预测、变换编码与熵编码工具链。这也解释了为什么 AVIF 的编码复杂度与 AV1 编码器绑定——它复用了同一套庞大的工程实现，压缩率收益的背后是算力开销。

JPEG 无损转码：JPEG XL 内建一个「JPEG 重压缩」模式，能把已有 JPEG 的 DCT 系数重新用更高效的熵编码和预测模型打包，同时保证解码后像素与原始 JPEG 完全一致。也就是说它并不重新量化图像，而是只替换外层的编码方式，因此画质严格无损、体积却能下降约 20%。这一能力让存量图库无需重新编码即可受益，是与 AVIF 最本质的差异之一。

响应式图片与内容协商：现代网站通常用 srcset/sizes 为同一张图提供多个尺寸，再用 <picture> 配合 <source type="image/avif"> 之类的写法让浏览器按支持情况挑选格式，这就是所谓内容协商。理解这一点很关键：格式选型的收益往往被尺寸切分、缓存命中和网络条件稀释，单看某种格式的极限压缩率并不能直接换算成真实性能提升。

Web 场景下的真实取舍

浏览器支持的现实

AVIF 在主流浏览器中的支持已经相当完整，Chrome、Firefox、Safari 都能原生解码，这让它在生产环境中几乎没有落地阻力。JPEG XL 的处境要复杂得多：Firefox 和 Safari 提供支持，Chrome 曾在实验性阶段启用后又移除，导致大量团队在评估时直接把它划出候选名单。

这种支持格局直接决定了选型的惯性。对绝大多数面向公众的网站来说，如果目标用户里有一半以上使用 Chrome，那么选择 JPEG XL 就意味着要么放弃这部分用户的优化收益，要么额外维护一套回退逻辑——而回退到 JPEG 或 WebP 后，JPEG XL 的核心优势就被大幅稀释了。

Chrome 移除 JPEG XL 的背景：Chrome 曾在 M91 左右以实验性 flag 的形式支持 JPEG XL，社区一度认为它即将转正。但在 2022 年底，Chrome 团队以「生态兴趣不足、维护成本与收益不匹配」为由将其从路线图中移除，引发大量争议。这一决策并非单纯的技术结论，而牵涉到 Google 对 AVIF/AV1 生态的长期投入——AV1 由 Google 参与主导，而 JPEG XL 出自与它竞争的阵营。因此讨论中「生态博弈」的说法并非空穴来风。

渐进式解码：渐进式解码指浏览器可以在只接收部分数据时就先渲染出模糊但完整的图像轮廓，随后逐层细化。它对首屏观感影响很大，尤其在慢网络下能让用户更早看到内容。JPEG XL 从设计上原生支持这一特性，而 AVIF 的渐进能力较弱，这让它在「先见轮廓、再提清晰度」的体验上具备长期潜力。

压缩效率不等于实际收益

评论区里有开发者指出，纯看压缩率的对比容易产生误导。真实网站里图片往往是响应式的，同一张图会生成多个尺寸。AVIF 在中小尺寸下的表现通常足够好，而 JPEG XL 的无损转码优势主要体现在有大量存量 JPEG 的场景，比如内容站、电商图库。

换句话说，决定收益的不是格式的理论极限，而是你手上图片资源的形态。全新项目从零开始用 AVIF，收益直接且工具链成熟；维护着几十万张历史 JPEG 的站点，JPEG XL 的转码路径反而更划算。

编码速度与工作流

AVIF 的编码耗时是讨论中最集中的抱怨点。有用户提到，在 CI 里批量生成 AVIF 会让构建时间显著拉长，需要引入缓存或分布式编码来缓解。JPEG XL 的编码器在速度上普遍被认为更友好，尤其无损转码几乎是「顺手就做了」。

这部分差异在开发体验上被放大了：AVIF 的优化往往需要在构建流程上投入额外工程，而 JPEG XL 的低门槛更容易被小团队接受。

Hacker News 上的分歧点

讨论并非一边倒。支持 AVIF 的一方强调生态的不可替代性——完善的浏览器支持、成熟的 CDN 与图片服务集成、以及围绕 AV1 的长期投入，都是 JPEG XL 短期内难以追赶的。有评论直言，一个格式能否胜出，取决于工具链和平台支持，而非单纯的压缩数据。

支持 JPEG XL 的一方则把矛头指向 Chrome 的决策，认为这更像是一次生态博弈的结果，而非技术评估的结论。他们看重的是无损转码带来的平滑迁移，以及格式本身在渐进式加载和高动态范围上的长期潜力。

一个折中的共识是：短期内 AVIF 是更安全的默认选择，而 JPEG XL 的价值在特定场景下依然成立，尤其是那些拥有庞大 JPEG 资产、且能控制客户端环境的项目。

实际选型建议

把讨论落到操作层面，可以按几个维度来判断。如果你的站点服务的是开放互联网用户、图片更新频繁、团队希望用最少工程成本拿到优化，AVIF 配合 WebP 回退是当下最稳妥的方案。

如果你维护的是内容存档、电商图库，或者客户端环境可控（比如企业内部应用、桌面端），JPEG XL 的无损转码能力能带来实打实的存储和带宽节省，值得投入评估。

还有一种被讨论提及的路径是同时输出两种格式，用 picture 元素配合 source 的 type 属性做内容协商。这能兼顾不同浏览器，但会增加构建复杂度与存储开销，适合对图片性能极度敏感的场景。

格式之争从来不只是技术参数的比拼，浏览器厂商的路线、CDN 的支持、以及团队已有的工程积累，都会影响最终答案。对多数开发者而言，先弄清楚自己的图片资产长什么样，比追逐「最强格式」更有意义。