缩略图要不要存成渐进式JPEG

我那个小工具站有个素材页一屏排着三四十张缩略图等人点开看大图。前两天我在琢磨给首页那张大图换成渐进式 JPEG 的时候顺手想到缩略图要不要一起换掉。改脚本也就一行的事，全站一起转最省心。真动手之前我还是先量了一下，量完以后缩略图这一块我决定不动。

先说大图这头的账。我测了网上找的一张缩到 2736×1824 的 Wikimedia Commons 风景照，按质量 85 各存一份。两份文件分别是 1,098,272 和 1,048,255 字节，渐进式小了 4.6%。渐进式真正的好处在下载还没完成的时候，我用解码器模拟过只收到一部分字节的情况。截到 10% 时基线式只画出最上面一条，渐进式已经是一整张偏软的图。大图下载要花时间所以先糊后清对它才有意义。代价是解码变慢，在 Chromium 149 开源构建上测出来的解码耗时渐进式是基线式的 2.3 到 2.6 倍。这张风景图从 11.1 毫秒涨到 28.3 毫秒。一张图多十几毫秒谁也感觉不到。

缩略图就是另一回事了。我在一台 Apple M4 / 16 GB 的 Mac 上用 Pillow 11.3 把同一张风景照缩到五个宽度，每档按质量 80 各存一份基线式和渐进式比字节数。1368 宽时渐进式小 5.0%，800 宽小 5.6%，400 宽小 5.3%。比例和大图差不多。可换成字节数一看就没什么意思了。400×267 这一档基线式 34,715 字节对渐进式 32,876 字节，一张只省 1,839 字节。240×160 那档只省 493 字节。到 120×80 的时候渐进式反倒从 3,404 字节变成了 3,492 字节，大了 2.6%。我又拿一张网上找的稿定设计放假通知模板试了一遍。这张 1242×2688 的竖版图在 400 宽时省 4.5%，240 宽省 3.8%，120 宽只省 2.1%，越小省得越少。

省得少还不是我不换的主要原因。缩略图本来就只有几十 KB 甚至几 KB，下载一眨眼就完了根本等不到先糊的那一步。先糊后清这个唯一的卖点在它身上用不上，解码变慢的那份代价却一张不落都要付。一屏三四十张图的时候这个倍数是要乘上去的。缩略图这种小尺寸的解码耗时我这次没单独测。上面 2.3 到 2.6 倍是大图上的数，小图上会不会是同样的比例我不确定。我先当它差不多来估。

还有一件事顺便记一下。我站里的图基本都是从浏览器里导出来的。一部分是用户上传时前端用 toBlob 转的，另一部分是我自己用图映 ImgIng 压的。图映 ImgIng 是个在浏览器里压图和转格式的在线工具，它导出的 JPG 走的是浏览器原生编码。这两类文件我读了文件头都是 SOF0 基线式。就算想全站换成渐进式也得在服务端单独跑一遍转换。这倒让我省了一件事，缩略图保持现状就什么都不用改。

最后我只转首页和详情页的大图，素材页的缩略图保持基线式。门槛先按宽度定在 800 以上才转，这条线是我拍脑袋定的。等哪天测了小图的解码耗时再调。你站上要是也排着成片的小图可以先挑一张缩略图按实际用的尺寸各存一份基线式和渐进式。比一下差出来的字节数再决定值不值得转。