上个月帮运营同事赶一批活动图投放后台卡死单张不能超过 2MB。我图省事找了个「压到指定大小」的网页工具把几十张一口气拖了进去。出来的图全部合格可有几张放大一看明显比原图糊体积离 2MB 却还空着一大截。额度明明给够了它凭什么不用满后来我把几种常见做法挨个跑了一遍才想明白差别不在编码器在它怎么找那个质量值。那个工具的源码我看不到只能从结果倒推这类功能大概就三种办法。第一种叫逐档下调从质量 0.92 开始每次降 0.05 重压第一次够小就停手。第二种是整数二分在 30 到 100 的整数里每次试中间那个值再砍掉一半最多试 7 次。第三种浮点二分跟整数二分是一个路子只是要找到小数点后两位才停。另外它开头会先拿最低质量 0.30 试一次。我跑的机器是一台 16 GB 内存的 Apple M4 Mac浏览器用的 Chromium 149 开源构建编码全靠它自带的 canvas 导出。样本有三类系统自带的一张 3840×2160 风景照片、程序生成的 2400 万像素类照片纹理图不是拍的和一张图映说明页的网页截图。我管结果体积除以目标体积叫「填充率」。这个数越接近 100%额度就用得越满画质也牺牲得越少。先看逐档下调风景照压到 2MB 这一组最能说明问题。JPEG 用逐档下调只编了 1 次就交差填充率才 64.4%。两种二分都拿到了 96.7%整数二分编了 6 次、浮点二分编了 8 次。换成 WebP 更夸张逐档下调照样 1 次就停填充率只有 48.9%。差不多一半额度就这么扔掉了。同一张图用整数二分能用到 93.0%。浮点二分是 94.9%。道理其实很简单这张照片在 0.92 时就已经不到 2MB 了。逐档下调第一步就合格了它压根不会回头往上试。我那批活动图糊掉的几张大概率就是这么来的。这张图只看每组里那根橙色短条就行。它代表逐档下调。四组里没有一组的填充率超过 78%最高的是截图压到 200KB 以内那组也只有 77.7%。绿色和蓝色两根几乎一样长分别是整数二分和浮点二分。右边的数字是编码次数逐档下调常常只有 1 次二分要 6 到 8 次。逐档下调快是因为少干了活。再看两种二分。我原本以为浮点二分找得更细结果肯定更好。JPEG 上完全不是这么回事两种二分拿到的是同一个文件浮点二分多出来的那两次编码纯属白干。我猜是浏览器把 JPEG 的质量四舍五入成了整数档质量填 0.955 已经按 96 算了。填 0.951 还是按 95 算。小数点后面找得再细也没用落到编码器那里只剩整数。WebP 不按整数档走浮点二分偶尔能多挤出一点。2400 万像素的图压到 2MB 以内时浮点二分的填充率是 99.7%整数二分是 95.8%。代价是 WebP 每次编码都慢这组浮点二分花了 8.83 秒整数二分也要 7.89 秒。更常见的情况是光调质量根本压不进去。风景照要压成 200KB 以内的 JPEG 就是这样质量拉到最低的 0.30 都还有 315 KB。浮点二分一上来就试了最低质量1 次编码就知道没戏。整数二分要试满 6 次才发现。逐档下调最离谱一路降了 13 次才肯放弃。这种时候只能去缩尺寸。先试最低质量只多花一次编码却能早早告诉你该去改尺寸了。我平时手动压图用的是图映 ImgIng一个在线免费的图片处理工具也是在这台 M4 上开 Chromium 用的。它没有「填目标大小」这一项给的是 30 到 100 的质量滑杆外加按图片内容推荐的档位。照片类它推荐 WebP 75、JPG 80图形和文字类给得更高WebP 84、JPG 88。这个思路我觉得挺实在与其帮你凑满一个体积不如直接告诉你质量给到多少就够看了。非得卡死一个上限的话我现在都先看结果体积占了限制的几成。限制是 2MB、结果才一兆出头的就把质量手动往上调一档再压一次。还合格就留这张。压不进去的先缩尺寸再调质量。别在质量上来回磨。