AVIF 还是 WebP——更小的文件不一定是对的那个

有天晚上我干过一件挺丢人的事：把同一张主视觉大图分别存成 WebP 和 AVIF，在两个浏览器标签之间来回切，想抓出一处我眼睛真能看出来的差别。那张 AVIF 小了 31%，我却怎么都分不出谁是谁。当时我坐在那儿，觉得自己像捡了笔白来的钱——然后我拿一个装了 200 张图的文件夹跑了一遍批量转换，才想起来那个坑。

多数时候，AVIF 确实是更小的那个文件。这一点是真的，也值得知道。可「更小」只是这张表里的一列，真正决定怎么选的，在别的列里。

AVIF 赢在哪

AVIF 建立在 AV1 视频编码之上，比起 WebP，它确实是更新、更聪明的设计。在照片类内容上，同等观感画质下，它通常比 WebP 小 15–30%。它能处理平滑的渐变——天空、皮肤、柔和的阴影——不会像老编码器那样在上面糊出块状的瑕疵。它支持 HDR 和广色域，这是 WebP 做不到的。它也保留完整的 alpha 透明通道，跟 WebP 一样。

下面是我从刚才提到的那个文件夹里随手记的一些大概数字，全都在一个我看不出差别的画质设置下：

再看最后一行。在扁平、简单的图形上，AVIF 有时反而更大。它的聪明劲儿是为照片的复杂度调校的，面对一张双色插画，它无从下嘴。这种场合，WebP、甚至 PNG，都能赢。

AVIF 让你付出的代价

体积上的这份便宜不是白来的。两笔实实在在的账：

编码时间。 AVIF 压缩起来慢得多。同一张图，AVIF 的编码可能比 WebP 慢好几倍——有时候就是「瞬间完成」和「每个文件等上一两秒」之间的差别。一张主视觉大图，无所谓。可换成一批 200 张，每一秒你都感受得到。WebP 编码快到基本可以当免费的。

解码与支持。 大家实际会用的浏览器现在都能解 AVIF——Chrome 从 2020 年起，Firefox 没过多久也跟上，Safari 从 2022 年底的第 16 版起支持。到了 2026 年，这已经覆盖了绝大多数真实流量。但「支持」和「通用」并不是同一个词。WebP 背后多攒了好几年的普及度，而且它在低端手机上解码更快——在那些机器上，解 AV1 是会实打实消耗电量和 CPU 的。还有一些邮件客户端、老旧的内嵌 webview，到现在压根不碰 AVIF。

那个 20% 的问题

所以真正的决定归结成这么一句：对于这一张图、放在这个位置，那多出来的约 20% 到底重不重要？

对于落地页上一张大幅的主视觉——那个每位访客都要下载的重资产——重要。给这个卡住你首屏渲染的东西削掉 100 KB，值得你只付一次的、更慢的编码。这是我知道的、最清晰的该上 AVIF 的场景。

而对于一片缩略图网格、一篇博客里的内嵌截图，或者任何存成 WebP 已经在 50 KB 以下的东西，答案通常是不重要。一个小数字的 20%，还是个更小的数字。你拿编码时间和一丝兼容性，去换根本没人在等的那点字节。这种场合，WebP 是更省心的默认选项。

什么时候我懒得用 AVIF

只要一个文件要去到现代浏览器之外的任何地方——一封邮件通讯、一个老 CMS、一个我管不着的合作方系统——我就不拿 AVIF 去赌。我用 WebP，想要零风险就干脆用普通 JPG。一个渲染不出来的最小文件，一文不值。

还有，扁平图形、logo、线条图，我不拿 AVIF 去编码。那不是这个编码器该干的活，而且我亲眼看它在这类文件上输给 WebP 的次数，多到让我不想再试。

我实际上是怎么决定的

说实话，我的工作流是这样的：把重的照片类素材转成 AVIF，把轻的、简单的、要广泛分发的东西留成 WebP。世上没有一种格式能通吃。得一张一张地挑。

想自己试试这个对比，两个都能在你的浏览器里跑——WebP 转 AVIF 用来把现有的 WebP 素材再挤一挤，PNG 转 AVIF 则直接从母版转过去。什么都不会上传到任何地方，编码就发生在你自己的机器上——这也正是你会亲身感受到 AVIF 有多慢的原因。那不是 bug。那是编码器为了一个更小的文件多干了活，就在你眼前。

拿你自己的一张主视觉大图，两边都跑一遍。要是你看不出差别，而 AVIF 又明显更小，那你的答案就有了。只是别想当然地以为，接下来那 200 张的答案也一样。