浏览器里转AVIF多等3倍,文字截图只小了5%

0 阅读5分钟

在网页里把图片转成 AVIF,点下去之后总要比转 WebP 多等一会儿。这两个都是比 JPG 更省地方的图片格式,AVIF 新一些,名声是同样清楚的时候文件更小。我平时搭小工具,转图是常事,等的次数多了就想弄明白一件事:多等的这点时间,到底换回来多少体积。我搭了个测试页,拿四张图量了一遍。

先说怎么比的。我试的四个浏览器里有三个自己导不出 AVIF,得在页面里带一个编码器,也就是把像素算成 AVIF 文件的那段程序。我用的是 @jsquash/avif 2.1.1,里面是 libavif v1.0.1 编成的 WASM。WASM 是把 C 这类语言写的库编译成浏览器能跑的格式,这样网页里也能用上它。WebP 那边用 @jsquash/webp 1.5.0。浏览器是 Chromium 149,机器是一台 Apple M4 的 Mac。四张图都缩到 200 万像素:一张湖景照片,一张水果摊照片,一张满屏文字的截图,一张后台表格界面的截图。AVIF 用质量 50、多线程版本、speed 6。speed 是编码器的速度档,数字越大越快,6 是这个库的默认值。

比体积之前得先把画质对齐,不然质量 50 的 AVIF 和随便一档 WebP 放一起没法看。我用的尺子叫 SSIM,它给「压缩后的图和原图有多像」打一个分,越接近 1 越像。我只算了亮度,也就是明暗那一层,颜色没算进去。做法是让 WebP 在 10 个质量档上各编一次,找到 SSIM 和那张 AVIF 相同的位置,估出这时候的 WebP 大概多大,下面 WebP 的数字前面都带个「约」就是这么来的。分数一样只是算出来的一样,不等于人眼看着一样。后面说的「同画质」都只是这个意思。

两张照片的结果比较规矩。湖景那张 AVIF 是 43,764 字节,对齐后的 WebP 约 63,610 字节,AVIF 是它的 69%。水果摊那张是 68%。时间上,在我这台机器上湖景编 AVIF 用了 324 毫秒,WebP 约 113 毫秒,水果摊是 509 对约 136。这里的毫秒只算编码那一步,读图、缩放都不在里面。合起来看,编码多花 3 到 4 倍时间,体积小三成左右。我又把 AVIF 质量换成 60、70、80 各跑了一遍,湖景是 73%、73%、71%,水果摊是 68%、70%、74%。没怎么漂。

四张图上 AVIF 与同 SSIM 的 WebP 的字节数和编码耗时

这张图先看中间带底色的那一列,是 AVIF 占 WebP 的百分比,四行里只有文字截图那格是红的。再看最右一列的耗时,前三行差得不多,最后一行突然变成 1,513 对约 85。

截图我原本当成一类,以为两张会差不多。结果正好相反。文字截图上 AVIF 是 172,174 字节,WebP 约 180,295 字节,AVIF 是它的 95%,只小了 5%。质量换到 60、70、80,比例是 96%、98%、97%,更贴近了。时间却一点没少花,357 毫秒对约 110 毫秒,还是 3 倍。表格界面那张是另一头:AVIF 31,672 字节,WebP 约 69,487 字节,只有 46%,不到一半。可它编了 1,513 毫秒,WebP 约 85 毫秒,是 17 倍。四张图里它的文件最小,等得最久,原因我没去查。它在质量 60 是 46%,70 是 51%,80 那档对齐的位置超出了我给 WebP 测的范围,没有数。这让我想到用真空压缩袋收东西,羽绒服一抽就瘪下去一大截,一摞书抽半天还是那么厚。

既然结果跟内容走,我就去看了一个现成的在线工具怎么对待不同内容。我用的是图映 ImgIng(imging.cn/)首页的格式转换,在 Chromium 149 里把湖景那张 200 万像素的 PNG 转成 AVIF。选中 AVIF 后画质滑杆自己停在 52,旁边有四个内容档,照片 52、平滑 48、纹理 56、图形/文字 60,湖景被标成了「照片 · 本图」,看得出默认画质是按图的内容分开给的。第一次转换从点下按钮到显示完成是 1678 毫秒。这是我在页面外面掐的整段等待,读图、界面更新和第一次才有的初始化都算在里面,和测试页里单算编码的毫秒数不是一回事,我没把两边放一起比。结果区显示 2.65 MB → 58.9 KB、省 98%,这个比例是和我喂进去的 PNG 比的,那张 PNG 底子就大,不是 AVIF 对 WebP 的差距。这一轮只跑了 1 次,别的浏览器没试,内部实现我也没去翻。

湖景照片转成 AVIF 后的操作面板

这张是转换完成后的面板。看画质那一行,滑杆在 52,「照片 52 · 本图」那一档是选中的。下面结果区是 2.65 MB → 58.9 KB,尺寸 1738×1150,写着 WASM AVIF 编码器。

我自己现在是先看手里是哪类图再决定等不等。照片多的那批,多等几倍时间换三成体积,我愿意等。满屏文字的截图就不折腾了,等了 3 倍只小 5%。表格、后台界面这一类最难办,体积能砍掉一半,可单张要一秒半,张数一多得掂量。这笔账只来自 4 张图、200 万像素一档、一台 M4 上的 Chromium 149,手机和 Windows 都没测。别的照片是不是也小三成,我不知道。想知道自己的图落在哪一类,挑两三张有代表性的,AVIF 和 WebP 各编一次,记下字节数和耗时,比看我这张表管用。两张照片出自维基共享资源,湖景的作者是 Jakub Fryš,水果摊的作者是 Josep M. Gracia,都是 CC BY-SA 4.0。两张截图是我自己渲染页面截的,不是真实产品界面。