2026 年的图像格式：AVIF 何时胜过 WebP，何时并非如此

2026 年图像格式的现状

AVIF 被称为“未来”已经足够久，以至于现在它更像是“当下”。浏览器支持率在 2024 年底超过了全球 95% 的覆盖率，CDN 增加了自动 AVIF 转码，大多数图像优化工具现在也默认提供 AVIF。与此同时，WebP 已成为安全的回退格式——无处不在、编码快速，并且对大多数用例来说已经足够好。

问题不再是 AVIF 在理论上是否更好。它确实更好。问题在于，编码时间、工具成熟度、边缘场景行为等实际权衡，是否值得你针对自己的具体工作负载进行切换。

本文将梳理这棵决策树。如果你要提供数千张用户上传的图像，答案会不同于你手动调校十几张营销主视觉图。如果你在意编码速度，答案也会再次改变。

AVIF 明显胜出的场景

AVIF 使用 AV1 视频编解码器的帧内压缩，这意味着它受益于多年面向动态视频的优化。其结果是，在等效感知质量下，文件大小通常比 WebP 更小，尤其是在摄影内容上。

在针对多种图像集的重复测试中，在相同 SSIM 分数下，AVIF 文件比 WebP 小 20-30%。对于高分辨率照片——产品图、编辑图片、任何宽度超过 1200px 的内容——这种差异会很快累积。一个 2MB 的 WebP 会变成 1.4MB 的 AVIF。把这一点乘以页面上的一百张图片，带宽节省就非常可观。

AVIF 对平滑渐变和低对比区域的处理也优于 WebP。WebP 的 VP8 血统意味着它可能会在天空、阴影和其他细微色调变化中引入色带。AVIF 更复杂的变换编码可以避免这一点。如果你的图像包含大量渐变——设计作品、插图、日落——AVIF 会在更小的文件大小下显得更干净。

浏览器支持现在已经足够强，使 AVIF 可以成为大多数网站的主格式。Safari 在 16.4（2023 年 3 月）中增加了支持，这是最后一个主要的阻力点。截至 2026 年初，全球支持率已超过 95%。剩下的缺口是较旧的 Android 设备和遗留企业浏览器，这也是为什么你仍然需要回退格式。

WebP 仍然有意义的场景

编码速度是最大的实际约束。AVIF 编码比 WebP 慢 5-10 倍，具体取决于质量设置和编码器实现。对于用户生成内容——头像、论坛附件、任何实时上传的内容——这种延迟很重要。一次需要 200ms 的 WebP 编码会变成一次 2 秒的 AVIF 编码。如果你同步处理上传，这就是用户可感知的延迟。

解决方案要么是异步编码（上传原始文件、提供占位图、在后台编码），要么是对用户生成内容继续使用 WebP，并把 AVIF 留给你可控的精选资产。许多网站两者都做：营销图像使用 AVIF，用户上传使用 WebP。

WebP 的工具成熟度也更高。每个图像库、CMS 插件和 CDN 都已经支持 WebP 多年。AVIF 支持正在追赶，但边缘情况仍然存在。一些较旧的 ImageMagick 构建会生成质量较差的 AVIF 输出。一些 CDN 会对 AVIF 转码额外收费。如果你在受限环境中工作——遗留 CMS、预算有限、期限紧迫——WebP 是阻力最小的路径。

最后，WebP 在几乎所有情况下仍然比 JPEG 更小，而且编码速度足以用于实时场景。如果你当前的基线是 JPEG，并且尚未迁移到现代格式，那么 WebP 是更安全的第一步。之后你总可以把 AVIF 作为渐进增强加入进来。

实用决策树

以下是选择方式：

• 精选营销图像、主视觉图、编辑照片：使用 AVIF 作为主格式，WebP 作为第一回退，JPEG 作为最终回退。文件大小节省足以证明编码成本是合理的，而且你可以控制流水线。
• 实时上传的用户生成内容：使用 WebP。编码速度比最后 20% 的压缩效率更重要，而且你承担不起数秒级延迟。
• 插图、纯色图形、截图：AVIF 比 WebP 更好，但对于有大面积纯色区域的简单图形，PNG 往往也有竞争力。两者都测试一下。如果你的 PNG 已经很小且压缩良好，格式迁移可能不值得。
• 缩略图和小图像：WebP 通常就可以。AVIF 带来的绝对字节节省很小（一个 10KB 的 WebP 变成 8KB 的 AVIF），而在规模化场景下编码速度更重要。
• 遗留浏览器支持至关重要：坚持使用 WebP 作为主要的现代格式。AVIF 的 95% 覆盖率很优秀，但如果你的用户群包含较旧设备或企业环境，WebP 近乎普遍的支持更安全。

如果你不确定，最安全的模式是向支持 AVIF 的浏览器提供 AVIF，并提供 WebP 回退和 JPEG 最终回退。<picture> 元素让这件事很直接：

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Description">
</picture>

这种方法让你兼得两者之长：为现代浏览器提供最大压缩，为较旧浏览器提供安全回退。

重要的编码设置

如果你采用 AVIF，编码设置对输出质量的影响会比 WebP 更大。AVIF 的灵活性意味着也有更多方式会产生糟糕结果。

最重要的两个设置是 quality 和 speed。Quality 很直接：数字越高，图像看起来越好，文件也越大。对于 AVIF，75-85 的质量设置通常是摄影内容的甜点区间。低于 70，你会开始看到明显伪影。高于 90，文件大小会膨胀，而质量提升并不显著。

Speed 控制编码器花多少时间优化输出。更慢的编码会生成更小的文件，但收益很快递减。大多数编码器使用 0-10 的尺度，其中 0 最慢，10 最快。6-8 的 speed 设置是不错的折中：编码速度足以用于批处理，文件大小也在理论最小值的 10-15% 范围内。

如果你在服务器上编码 AVIF，请使用较新版本的 libavif 或 avifenc。较旧的编码器（2024 年之前）在相同文件大小下会产生明显更差的输出。该格式仍在成熟，编码器改进已经相当显著。

JPEG XL 呢？

JPEG XL 在技术上优于 AVIF 和 WebP。它压缩更好、编码更快、支持无损压缩，并且能处理更广泛的图像类型。但它也是一个已经失去生命力的格式。

Google 在 2022 年从 Chrome 中移除了 JPEG XL 支持，理由是采用率低且复杂度高。Apple 从未增加支持。截至 2026 年，JPEG XL 仅在 Firefox 和 Safari Technology Preview 中受支持，这意味着它不适合生产使用。除非浏览器厂商改变方向——这不太可能——JPEG XL 将仍然是面向爱好者和归档工作流的格式，而不是面向 Web 的格式。

迁移路径

如果你正在从 JPEG 迁移到现代格式，最安全的路径是：

1. 审计你当前的图像流水线。识别图像来自哪里（CMS、用户上传、CDN）、如何处理，以及你当前提供哪些格式。为什么在浏览器中处理图像有利于隐私 介绍了围绕图像处理发生位置的一些权衡。
2. 从 WebP 开始。它编码快、支持广，并且能立即减少文件大小。这是低风险的第一步。
3. 为精选内容添加 AVIF。一旦 WebP 稳定运行，就为文件大小最重要的高价值图像添加 AVIF。测试编码时间，并确保你的 CDN 或图像服务支持它。
4. 监控浏览器支持。AVIF 覆盖率现在很优秀，但如果你的分析数据显示有相当比例的用户使用较旧浏览器，请保持 WebP 作为主格式。
5. 衡量影响。使用真实用户监控来跟踪迁移前后的页面加载时间和 Largest Contentful Paint。如何读懂 Lighthouse 报告而不恐慌 是解读性能指标的有用指南。

目标不是因为某个格式新就使用它。目标是在不牺牲质量的前提下提供更小的图像，从而提升页面速度并降低带宽成本。AVIF 在大多数情况下比 WebP 更擅长做到这一点，但编码速度、工具、浏览器支持等实际约束意味着，对某些工作负载来说，WebP 仍然是正确选择。

关键要点

• 在等效质量下，AVIF 比 WebP 小 20-30%，尤其适用于摄影内容和带渐变的图像。
• AVIF 编码比 WebP 慢 5-10 倍，这使得它不适合实时用户上传，除非你进行异步编码。
• AVIF 的全球浏览器支持率超过 95%，但 WebP 近乎普遍的支持使它成为更安全的回退。
• 对于精选营销图像，使用 AVIF 作为主格式，并提供 WebP 和 JPEG 回退。对于用户生成内容，坚持使用 WebP。
• JPEG XL 在技术上更优，但没有可行的浏览器支持，不应在生产网站中使用。

FAQ

Q: Can I serve AVIF without a fallback?

A: 还不行。AVIF 支持率超过 95%，但这仍然意味着数百万用户使用较旧浏览器。始终使用 <picture> 元素包含 WebP 或 JPEG 回退。浏览器会自动选择它支持的最佳格式。

Q: Does AVIF support transparency?

A: 是的。AVIF 支持 alpha 通道，因此在需要透明度的场景中，它可以成为 PNG 的可行替代。文件大小通常小于 PNG，不过编码更慢。

Q: Should I re-encode all my existing images to AVIF?

A: 只有在带宽节省足以证明投入合理时才这样做。从高流量页面和大图像开始，因为影响在那里最明显。对于低流量页面或小图像，ROI 很低。先关注新内容，再有选择地回填旧内容。

Q: What's the best tool for batch-encoding AVIF?

A: avifenc（libavif 的一部分）是使用最广泛的命令行工具。对于 GUI 工具，Squoosh（基于 Web）和 ImageOptim（Mac）都支持 AVIF。大多数现代 CDN 和图像服务（Cloudflare、Cloudinary、imgix）都可以自动转码为 AVIF。

Q: Does AVIF work with responsive images and srcset?

A: 是的。使用带有多个 <source> 元素的 <picture> 元素进行格式回退，并在每个 <source> 中使用 srcset 进行响应式尺寸设置。浏览器会根据支持情况和视口宽度选择最佳格式和尺寸。

<!-- tool-cta:start -->

💡 试试这个： 使用 Image Converter 在你自己的素材上比较这两种格式，它可以同时输出 AVIF 和 WebP，方便你衡量真实场景中的大小和质量。

<!-- tool-cta:end -->

Sources

• AVIF vs WebP：全面比较 — 对不同图像类型中的压缩效率和质量设置进行详细分析。
• Can I use AVIF? — AVIF 图像格式的当前浏览器支持数据。
• libavif GitHub repository — AVIF 的参考编码器实现和文档。
• Web Almanac：Images — 关于 Web 上图像格式采用情况和性能的年度报告。