JPEG XL vs AVIF：你该选择哪种格式？

在2026年的生产环境Web交付中，应当选择AVIF：截至2026年中期，其全球浏览器覆盖率约为93%，且已在CDN、CMS和构建工具中获得成熟支持。JPEG XL在技术层面更为出色——编码速度更快、无损压缩效果明显更好、原生支持渐进式解码——但Chrome仍将其置于实验性标志（flag）之后，导致JXL的覆盖率仅约15%，且全部来自Safari，caniuse将其标注为部分支持。这一事实直接决定了所有面向公众网站的选择：在Chrome默认启用JXL之前，以JXL为主的交付方案仍需向绝大多数用户回退至AVIF或JPEG。

本文直接解决那些已处于决策中间阶段的场景：你已经在使用WebP或AVIF，了解JPEG的局限性，并希望基于当前浏览器实际情况做出有据可查的决策，而非盲目追随某种格式。文章将逐项分析——压缩率、浏览器支持、编码开销、渐进式渲染——提供正确的<picture>代码片段，并告诉你哪个具体信号会改变本文的建议。

两种格式的本质

AVIF和JPEG XL解决的是同一个问题——在相同或更高质量下获得更小的图像体积——但二者来自截然不同的设计谱系。AVIF（AV1图像文件格式）由开放媒体联盟于2019年推出，源自YouTube、Netflix等服务所使用的AV1视频编解码器的关键帧帧内编码技术。JPEG XL（ISO/IEC 18181）则由联合图像专家组联合Google和Cloudinary专门为静态图像格式而设计，并于2022年完成标准化。

这种谱系差异——AVIF派生自视频编解码器，JPEG XL专为静态图像而生——解释了下文大多数权衡取舍的根源。AVIF继承了AV1强大的有损照片压缩能力及其CPU密集型编码器。JPEG XL则围绕图像特有的需求进行工程设计：渐进式解码、高位深色彩、无损模式，以及一项其他现代格式均不具备的特性——无损JPEG再压缩。现有JPEG可被转码为JXL，文件大小减少约20%，并能逐字节还原为原始JPEG。这使JXL成为在不损失质量的前提下归档大型JPEG图库的唯一可行格式——这是一个真正的决策依据，而非注脚。

压缩率：谁占优取决于内容类型

在有损照片压缩的低至中等质量档位，AVIF占优；在高质量档位、非摄影类或平面图形内容以及无损压缩方面，JPEG XL占优。不存在”X比Y小N%“这样的单一答案，任何给出此类结论的文章都是在夸大一个依赖内容的结果。

实际情况分析如下：

• 有损照片，中等质量： 在激进的码率下，AVIF的失真更柔和、更自然——它会模糊边缘并隐藏伪影，而JPEG XL的VarDCT模式可能产生类似传统JPEG的振铃效应或块状伪影。这是AVIF的主场，也是最常见的Web使用场景。
• 高质量及非摄影内容： JPEG XL与AVIF相当甚至更优，尤其在插图、Logo、截图和文字密集型图形方面，其模块化编码模式能够干净地处理纯色区域。
• 无损压缩： JPEG XL明显更优。无损AVIF几乎没有实用价值——其效果仅略优于PNG——而无损JXL与PNG相当，且通常小得多。

压缩比因图像内容和质量设置的不同而存在显著差异；JXL与AVIF之间的差距尤其依赖于内容，并非一个确定的数值。在将内容库锁定到某种格式之前，请在Squoosh中测试你的具体资源——它可以在浏览器中编码两种格式，并针对你自己的图像（而非他人的基准测试集）展示大小/质量的权衡关系。

浏览器支持：决定性因素

浏览器支持才是这个决策真正做出的地方，也是大多数参考文章出错或报告过时信息的维度。截至2026年中期，AVIF的全球覆盖率约为93%，并已在Chrome、Edge、Firefox和Safari中默认启用。JPEG XL的覆盖率约为15%——全部来自Safari，且被标注为部分支持。

Chrome的历史沿革至关重要，因为三篇被广泛引用的文章中有两篇对此报告有误。准确的时间线如下：

“Chrome已放弃JPEG XL”这一被广泛传播的说法现已过时。Chromium撤销了对该格式的废弃标注，并使用基于Rust的新解码器（而非C++版libjxl）重新集成了解码功能。但重新集成并不等同于正式发布：在当前稳定版渠道中，Chrome中的JXL解码功能仍默认禁用，需要通过chrome://flags/#enable-jxl-image-format手动激活。Firefox在Nightly版本中通过image.jxl.enabled偏好设置保留了JXL代码，但并未将其编译进正式发布版本，也未公布任何发布时间表。

将上述情况转化为部署决策，是每篇参考文章都暗示但从未明确说明的部分：当前以JXL为主的<picture>元素会向约85%的用户回退至AVIF或JPEG。你需要编码并存储三种格式变体，才能向约七分之一的访客交付JXL——即便如此，这部分覆盖也仅是Safari的部分支持。这才是现在就采用JXL优先方案的实际成本，只有在Chrome默认启用该格式后，这一成本才能得到回报。

编码开销与渐进式渲染

JPEG XL的编码速度快于AVIF，且独特地支持渐进式解码；AVIF编码对CPU要求较高，且没有真正的渐进式模式。这两个差异在实际操作中都有影响——一个体现在构建流水线中，一个体现在用户的感知加载时间上。

AVIF编码是大多数流水线中的瓶颈

使用AV1参考编码器（libaom-av1）进行AVIF编码是典型图像处理流水线中最慢的阶段，在相同感知质量下，其每张图像的编码时间明显慢于JPEG XL。对于手动转换单张主图，这一差异可以忽略不计。但对于在每次部署时处理数百张产品图像的CI任务，这是一个实际的约束：编码时间随图像数量线性增长，而AV1编码器在设计上就是计算密集型的。

针对Node.js流水线的实际优化措施：

• 使用封装了libvips的Sharp进行AVIF和JXL编码。它提供quality和effort参数，可在编码时间和输出大小之间进行权衡。
• 调整effort/speed参数，而非默认以最高effort运行编码器——高effort的AVIF编码仅能以大量时间成本换取边际性的文件体积缩减。
• 通过worker线程或CPU核心并行处理，或将转换推送至支持按需编码的CDN，从而避免阻塞构建流程。

const sharp = require("sharp");

// AVIF: 降低 `effort` 值，以略微增大文件体积换取更快的CI编码速度
await sharp("hero.png")
  .avif({ quality: 60, effort: 4 })
  .toFile("hero.avif");

// JXL在相当质量下编码更快（需要启用了libjxl的构建版本）
await sharp("hero.png")
  .jxl({ quality: 60 })
  .toFile("hero.jxl");

通过sharp.format检查已安装的sharp构建版本以确认格式可用性——JXL支持取决于捆绑的libvips/libjxl，并非在所有发行版中都有保障。

渐进式解码影响感知LCP

JPEG XL原生支持渐进式解码：浏览器会立即渲染图像的低质量版本，并随着数据到达逐步清晰化。AVIF没有真正的渐进式模式，因此大型AVIF图像要么完整显示，要么完全不显示。在网络较慢的情况下，这会导致明显的最大内容绘制（LCP）延迟——主图区域在完整文件到达之前一直保持空白。

这类问题在会话回放中可以直接观察到：在图像密集型页面上，在网络受限的情况下，主图区域在整个大型图像下载过程中保持空白，LCP时间戳被固定在完整文件最终渲染的那一刻。JXL风格的渐进式解码恰好解决了这一问题——图像先以低质量出现，然后逐渐清晰——这是对慢速网络上真实用户而言真正重要的感知性能表现，也是为什么文件大小和渐进式渲染是影响LCP的关键因素，而非仅仅是视觉偏好。

决策框架：在何种情况下选择哪种格式

对于面向公众的Web生产环境，应通过<picture>元素以WebP和JPEG作为回退方案来部署AVIF。在特定的、有边界的场景中才考虑JPEG XL：无损或归档工作流、非摄影类图像库、以Safari为主的受众群体，或希望在不损失质量的前提下再压缩大型JPEG图库。

在以下情况下选择AVIF：

• 你运营的是需要当前广泛覆盖的面向公众的生产网站。
• 你的资源主要是摄影类或混合类型。
• 你使用的CMS或CDN具有原生支持——AVIF自WP 6.5（2024年4月）起已在WordPress中原生支持，主流CDN也支持按需编码。
• 你希望在不管理第四种格式变体的情况下，相比JPEG/WebP获得可量化的LCP提升。

在以下情况下考虑JPEG XL：

• 你维护着大型JPEG图库，并希望进行无损再压缩——转码为JXL（体积缩小约20%）并能逐字节还原原始文件。
• 你的内容以非摄影类为主：插图、Logo、图表、截图。
• 你的受众以Safari用户为主，且你在无头架构或自定义设置中完全控制<picture>标记。
• 你正在为Chrome默认启用JXL的那一刻构建面向未来的交付方案。

截至2026年中期，JPEG XL尚未在WordPress中获得原生上传支持，这进一步强化了AVIF作为实际CMS选择的地位。

一个正确且最新的<picture>代码片段

在<picture>元素中，浏览器按文档顺序评估<source>条目，并选择第一个其支持的type，若无匹配则回退至<img>。因此，排列顺序不仅仅是形式——它就是选择算法。按优先级从高到低列出格式，并将<img>回退设为通用支持的JPEG，而非WebP（WebP需要独立的<source>条目，因为它是一种不同的MIME类型）。

<picture>
  <!-- JXL优先：仅向Safari 17+（部分支持）提供；2026年中期Chrome默认关闭 -->
  <source srcset="hero.jxl" type="image/jxl">
  <!-- AVIF：约93%覆盖率，承载几乎所有流量的主力层 -->
  <source srcset="hero.avif" type="image/avif">
  <!-- WebP：覆盖AVIF普及之前的旧版Chrome/Firefox -->
  <source srcset="hero.webp" type="image/webp">
  <!-- JPEG：无条件回退；始终能够渲染的src -->
  <img src="hero.jpg" alt="描述文字" width="1200" height="630"
       loading="lazy" decoding="async">
</picture>

对这个四层方案的客观评价：当前你需要编码四种格式变体，才能向仅限Safari的少数用户提供JXL。如果你的受众并非以Safari为主，且没有归档方面的JXL需求，可以去掉第一个<source>，改用AVIF/WebP/JPEG三层方案——它以少一种格式的构建和存储成本覆盖了几乎所有流量。等Chrome翻转标志之后，再添加JXL source，而不是在此之前。

关注哪些信号以判断建议是否改变

将JPEG XL作为主要交付格式的实际触发信号是Chrome将chrome://flags/#enable-jxl-image-format默认设为开启；在此之前，覆盖率数据——JXL约15%（仅限Safari部分支持）对比AVIF约93%——使AVIF成为面向公众的Web生产环境中唯一站得住脚的主要格式。值得持续关注的具体信号：

• Chrome Platform Status中JPEG XL的条目从”标志后”变更为”已发布/默认启用”。
• caniuse.com/jpegxl的完整支持覆盖率突破可用阈值，并取消部分支持标注。
• Firefox将JXL从Nightly版本引入正式发布版本。
• 主流CDN在其图像处理流水线中默认启用JXL转换。

当上述任一信号出现时，以JXL为主的<picture>方案将不再是投机性的成本，而将成为默认推荐，上述框架也将随之反转。

结论

现在部署AVIF，同时为JPEG XL准备好你的<picture>标记。AVIF是当前能够覆盖你的用户的格式，并拥有相应的工具链和CMS支持；JPEG XL在技术指标上更为出色，且是无损归档和JPEG再压缩的正确工具，但其公共Web应用场景完全取决于Chrome是否默认启用它。将你的资源转换为AVIF，添加WebP和JPEG回退，并关注Chrome Platform Status条目——那个标志默认开启的那天，就是重新审视JXL作为主要source的时候。

常见问题

在同一个picture元素中同时提供AVIF和JXL source，会使我的存储和带宽翻倍吗？

这会增加存储占用，但不会影响每次请求的带宽。你列出的每种格式变体都会增加一个需要存储的编码文件，因此JXL、AVIF、WebP、JPEG四层方案意味着每张图像需要存储四个文件。带宽不受影响，因为浏览器只会下载它选择的第一个受支持的source，而不会同时下载多个变体。采用JXL优先方案的真实成本在于额外的编码和存储，以覆盖仅限Safari的少数用户，而非重复下载。

我能在不从原始文件重新编码的情况下，将AVIF图像转换为JPEG XL吗？

不能，这样做会有质量损失。JPEG XL的无损转码特性仅适用于JPEG源文件，不适用于AVIF或WebP。你可以将现有JPEG封装为JXL并逐字节还原，但AVIF和WebP是有损格式，没有这样的可逆路径。将AVIF转换为JXL意味着解码已经压缩的AVIF，然后重新编码，从而叠加伪影。请务必保留原始无损母版，以便能够干净地重新编码为任何格式。

为什么我的AVIF主图文件比JPEG小，却仍然影响最大内容绘制（LCP）？

AVIF没有真正的渐进式解码，因此大型AVIF图像只有在完整文件到达后才会渲染，而不会先显示低质量预览。在网络较慢的情况下，主图区域在整个下载过程中保持空白，LCP时间戳被固定在最终渲染的那一刻。更小的总文件大小并不能改变这种全有或全无的行为。JPEG XL的渐进式解码会逐步清晰化，即使在字节数相近的情况下也能改善感知加载体验。

同时支持AVIF和JPEG XL的浏览器，会选择我列出的第一个source吗？

是的。picture元素会选择第一个浏览器支持其type属性的source，按文档顺序评估，与文件大小或格式能力无关。如果你将JXL列在AVIF之前，同时支持两者的Safari版本会提供JXL；反转顺序则提供AVIF。浏览器不会比较质量或权重，因此source顺序就是选择机制。将你偏好的格式放在最前面，并以通用支持的JPEG img作为最终回退。