AVIF vs WebP vs JPG：现代图片格式大对决
为什么这场比较如此重要
别把图片格式当成一个无关紧要的选择，它们不是。在高流量的产品页面上，一个选择不当的格式就可能让每张图片增加 200–400 KB。这会累积成数秒的额外加载时间，并导致转化率明显下降。Google 的核心网页指标会直接惩罚“最大内容绘制”速度慢的网站，而图片通常就是罪魁祸首。在 AVIF、WebP 和 JPG 之间做选择，会对 SEO、带宽费用以及用户是否愿意留下来产生实实在在的影响。 自 90 年代中期以来，JPG 一直是摄影领域的霸主。它无处不在，编码速度快，而且每个开发者都知道如何处理它。谷歌在 2010 年推出了 WebP 作为其替代品，承诺在同等质量下提供更好的压缩效果。而新来者是 AVIF，由开放媒体联盟于 2019 年标准化。它借鉴了 AV1 视频编解码器的技术，将压缩推向了新的高度。 这里的目标不是要宣布某个格式是最终赢家，那毫无意义。目标是让你理解它们各自具体的优缺点，这样你才能为*你的*项目做出正确的决定，而不是盲目听从一些 2021 年的过时建议。我们将深入分析实际的压缩效果、浏览器支持以及编码速度等隐藏成本，为你提供有效使用每种格式的背景知识，并让你知道何时应该进行转换。
压缩性能：宣传背后的真实数据
是的，现代格式确实比 JPG 小得多。宣传中的这一点是真的。但具体小多少，取决于图片本身、使用的编码器以及你追求的质量。 对于一张典型的照片，WebP 文件通常比同等视觉质量的 JPG 小 25–35%。AVIF 更进一步，通常能比 JPG 小 40–55%，这大约比 WebP 又小了 15–25%。这意味着一张 180 KB 的产品照片（JPG，质量 85），可能会变成 120 KB 的 WebP 或 90 KB 的 AVIF。节省的体积是实实在在的。 但你不能直接跨格式比较质量数值，它们并不等同。“质量 85” 的 JPG 和 “质量 85” 的 WebP 不是一回事。在 ImageMagick 中把 JPG 的质量从 85 降到 75 可能会大幅减小文件大小，但也会在渐变和天空中引入块状瑕疵。WebP 使用 0–100 的范围，80 是一个不错的起点，大致相当于 JPG 的 85。AVIF 使用恒定速率因子 (CRF) 范围，通常是 0–63，数值越低越好。对于网页照片，CRF 在 30–40 之间通常是最佳选择。 对于 UI 截图、logo 或信息图这类图形，情况就不同了。PNG 因其无损质量一直是首选，但 WebP 的无损模式能稳定地生成小 20–30% 的文件。AVIF 的无损模式还不那么成熟，有时为这类内容创建的文件甚至会比 WebP 无损模式*更大*。不要想当然地认为 AVIF 在所有方面都胜出。 谷歌的 Squoosh 团队进行的测试证实了 AVIF 在压缩方面的普遍优势，但他们也发现，当你处理的源文件本身已经被高度压缩时，这种优势会减小。如果你是重新转换一堆旧的 JPG，而不是从高质量的原图开始，你将看到收益递减。输入的是垃圾，输出的也只是稍微小一点的垃圾而已。
浏览器和平台支持：情况开始变得复杂
首先要明确一点：JPG 的支持是普遍的。每个浏览器、操作系统、图片查看器、内容管理系统、CDN 和电子邮件客户端都能处理它。不要低估这个优势，这是一种新格式目前根本无法匹敌的普及程度。 在网页使用方面，WebP 的支持现在已经非常出色。截至 2024 年，所有主流浏览器——Chrome、Firefox、Safari（自 14 版起）、Edge、Opera——都已支持。在 caniuse.com 上的全球支持率超过 97%。唯一不支持的只有 iOS 13 及以下版本的古老 Safari，这对你的用户群体来说可能不是问题。 AVIF 的支持也不错，但你需要更加小心。Chrome 自 85 版（2020 年）就已支持，Firefox 自 93 版（2021 年），Safari 最终也在 16 版（2022 年）加入了支持。这覆盖了大多数用户，但你仍然可能在旧版 Windows 10 的 Edge 或某些 Android WebView 中遇到问题。全球支持率在 93-95% 左右徘徊。这听起来很棒，但对于一个高流量网站来说，那 5-7% 看到破损图片的用户是一个非常现实的问题。 在浏览器之外，情况就变得复杂了。对于桌面应用、移动应用或电子邮件，支持情况参差不齐。macOS 从 Ventura (13.0) 开始支持 AVIF。Windows 11 支持它，但 Windows 10 需要从微软商店安装一个编解码器。Android 从 12 版开始支持，iOS 从 16 版开始。如果你使用了带有正确备用选项的 HTML `<picture>` 元素，这些都无关紧要，但如果你希望用户自己下载并打开这些文件，那将是个大麻烦。 对于一个生产环境的网站来说，唯一明智的策略是级联式地提供图片：首先是 AVIF，然后是 WebP 作为备用，最后是 JPG 用于其他所有情况。你可以使用 `<picture>` 元素的带有 `type` 属性的 `source` 标签来实现，或者在服务器上检查 `Accept` 请求头。不要只提供 AVIF 然后祈祷一切顺利。
编码速度与工具链：隐藏的成本
AVIF 惊人的压缩效果背后有一个隐藏成本：时间。与 JPG 或 WebP 相比，AVIF 的编码速度慢得惊人，这对你的工作流程有实实在在的影响。 让我们看看数据。在一台现代机器上，将一张 2000×1500 的照片编码为 JPG（质量 85，使用 libjpeg-turbo）可能需要 50-80 毫秒。同一张图片编码为 WebP（质量 80，使用 libwebp）需要 200-400 毫秒。但编码为 AVIF（CRF 32，速度 6）则可能需要 2 到 8 *秒*。如果你把编码器调到最慢、最高质量的设置，你可能需要为一张图片等待 30 秒或更长时间。 对于 500 张产品图片的批量处理，这意味着是 5 分钟的咖啡休息时间和 4 小时等待的区别。如果你是即时生成图片，就像一些 CDN 所做的那样，除非你的缓存策略完美无缺，否则这种编码开销会增加无法接受的延迟。 libavif 编码器有一个速度设置，从 0（最慢，压缩最好）到 10（最快，压缩最差）。速度 6 是标准推荐，是文件大小和你自己理智之间的一个良好折衷。速度 10 几乎和 WebP 一样快，但你会牺牲掉 AVIF 的大部分压缩优势。 CocoConvert 在服务器上为你处理了这种复杂性，但物理定律依然适用：大批量 AVIF 转换会比 WebP 或 JPG 任务花费更长的时间。如果你赶时间，WebP 通常是更实际的选择，即使 AVIF 可能能再省下几 KB。 WebP 的工具链已经成熟稳定；cwebp、Squoosh、ImageMagick 和 Node.js 的 Sharp 库都有强大的支持。AVIF 的工具链正在迎头赶上——Sharp 在 v0.27.0 中增加了支持，ImageMagick 使用 libheif——但任何与库依赖问题作过斗争的人都知道，“迎头赶上”可能意味着会遇到在 JPG 和 WebP 世界中根本不存在的奇怪错误和版本冲突。
低比特率下的图像质量：格式差异最大之处
在高画质设置下，大多数压缩图片看起来都不错。真正的考验是在低比特率下，当你极力从文件中榨取每一字节时。这时，各种格式的本色才显露出来，差异是显而易见的。 重度 JPG 压缩因其块状瑕疵而臭名昭著。在质量 40-50 时，蓝天中的平滑渐变会碎裂成一块块的方格。文字周围会出现模糊的振铃效应。我们都见过这种图片，它们很难看。 在同样低的文件大小下，WebP 倾向于模糊而不是产生块状。它会平滑掉精细的细节。对于肖像照来说，这可能是一种更讨喜的瑕疵，因为模糊看起来比 JPG 的生硬方块更自然。然而，对于有清晰线条或文字的图片，同样的模糊可能是一个主要缺点。 这正是 AVIF 大放异彩的地方。在低比特率下，它完胜其他两种格式。其基于 AV1 的编码在保留细节和处理渐变方面表现得更出色。一张 50 KB 的 AVIF 图片看起来就是比同等大小的 WebP 或 JPG 更清晰。AVIF 的真正优势不在于质量 90 的时候（此时一切都很好），而在于质量 50-60，当你挑战极限的时候。 感知指标也证实了这一点。一张 1200×800 的风景照压缩到 50 KB，JPG 的 DSSIM 分数可能是 0.008，WebP 是 0.005，而 AVIF 是 0.003（越低越好）。这些不仅仅是数字，它们代表了肉眼可见的改进。如果你的文件大小预算非常严格，AVIF 将始终为你提供最好看的图片。 但有一个例外：精细的胶片颗粒或自然纹理。AVIF 的编码器在平滑这些细节时可能过于激进，导致一些高 ISO 照片看起来有点不自然，有种塑料感。一定要用你自己的图片进行测试，不要想当然地认为 AVIF 是解决所有内容类型的灵丹妙药。
实际应用场景：根据用途选择格式
理论虽好，但你到底应该在什么地方使用哪种格式呢？这里有一份针对常见场景的实用指南。 **网站主图和产品照片：** 首选 AVIF，依次降级到 WebP，然后是 JPG。你控制着环境，所以可以使用 `<picture>` 元素来提供最佳格式。节省的带宽是巨大的。像 CocoConvert 这样的工具可以轻松地将你的 JPG 原图批量转换为 AVIF 和 WebP。 **电子邮件图片：** JPG，没得商量。电子邮件客户端在渲染方面简直是一片混乱。无论是 AVIF 还是 WebP，在 Outlook、Apple Mail 或 Gmail 中都没有可靠的支持。发送一张 WebP 只会让你的一大批收件人看到一张破碎的图片。 **社交媒体上传：** 坚持使用高质量的 JPG。无论你上传什么，每个平台（Instagram、Twitter/X、Facebook）都会重新编码你的图片。给它们的编码器提供尽可能好的源材料，上传一个预先压缩的 AVIF 对你没有任何好处。 **打印或存档：** 两种都不要用。为你的原始文件使用像 TIFF 或 PNG 这样的无损格式。如果必须发送压缩预览，高质量的 JPG（90-95）是任何打印店或编辑都能打开的通用标准。 **移动应用资源：** 这取决于你的最低操作系统目标。如果你是为 Android 12+ 和 iOS 16+ 开发，AVIF 是一个很好的选择。为了更广泛的支持，WebP 是更安全的选择，它可以兼容到 Android 4.0 和 iOS 14。 **CMS 内容：** 对 AVIF 要谨慎。当非技术用户上传图片时，你想要最可靠的工作流程。许多 CMS 的媒体库和缩略图生成器仍然不能很好地处理 AVIF。JPG 和 WebP 更实用，也更不容易导致关于图片预览损坏的技术支持请求。
如何在这些格式间转换（以及注意事项）
使用合适的工具在这些格式之间转换很容易，但如果你不小心，一些“雷区”可能会毁掉你的批量处理任务。 转换的首要规则是：始终从最高质量的源文件开始。将 JPG 转换为 AVIF 并不会神奇地恢复已被 JPG 压缩破坏的细节，它只是将同样退化的数据包装在一个新格式里。如果你有 RAW 或 TIFF 原图，就用它们。如果你只有 JPG，将其转换为 AVIF 会使文件变小，但不会让图片看起来更好。 使用像 CocoConvert 这样的工具可以简化这个过程：上传，选择一个格式，然后下载。从 JPG 到 WebP 的默认质量设置经过调整，以保持视觉质量。对于 JPG 到 AVIF，默认设置在文件大小和质量之间取得了平衡，但对于那些将被放大显示并被用户仔细审视的图片，你应该考虑要求更高的质量。 让我们坦率地谈一个限制：CocoConvert 不处理动画格式。将动画 WebP 转换为动画 AVIF 是完全不同的事情，涉及到帧时序和调色板。为此，你需要动用像 FFmpeg 这样的命令行工具。 注意透明度。JPG 完全不支持透明度。如果你将一个透明的 PNG 或 WebP 转换为 JPG，背景将被填充为纯色，通常是白色或黑色。AVIF 和 WebP 都能很好地处理透明度（alpha 通道），所以在它们之间转换会保留透明度。只需确保你不会在处理流程中意外地让一张透明图片经过 JPG 转换步骤。 最后，一点实用主义的建议。在你为每张图片生成 AVIF 和 WebP 版本之前，问问自己是否真的需要两者。生成两种格式会使你的处理时间和存储空间加倍。对于许多网站来说，简单地统一使用 WebP 就已经是相比 JPG 的巨大改进，并且能覆盖 97% 以上的用户，复杂性也低得多。AVIF 很强大，但只有当你的带宽费用真正证明这额外的功夫是值得的时候，才去添加它。