企业官网建设流程全解析

放假前我想把自己那个工具站的首页大图处理一下。首页顶上那张 2736×1824 的风景横幅是我把网上找的一张 Wikimedia Commons 照片缩小以后做的。有个朋友在老家用手机流量打开过这个页面。他说那张图是一截一截从上往下刷出来的，没等刷完他就把页面关了。我想换成渐进式 JPEG 让它先整张糊着出来再慢慢变清楚。可站里不止这一张图，我不想一张张点开属性去看，打算先批量查一遍再决定转哪些。

站里的图来路挺杂。有我自己放的横幅和文章配图和用户在页面上传的图，也有我先用在线工具压好再传上去的海报。我按这几种来源各挑了几张凑成一个 11 张共 4,537,081 字节的测试目录。机器是一台 Apple M4 / 16 GB 的 Mac。系统自带的 5.41 版 file 命令读文件头时会直接在输出里写 baseline 或者 progressive。我就拿它写了个几行的脚本把每张图的大小和扫描方式列出来再按大小倒序排：

find"${1:-site}"-name'*.jpg'|whileread-rimg;dokind=$(file-b"$img"|grep-o-ebaseline-eprogressive)printf'%9d %-11s %s\n'"$(stat-f%z"$img")""$kind""$img"done|sort-rn

跑出来 11 行全是 baseline，一张渐进式都没有。stat -f %z 是 macOS 的写法。Linux 上得换成 stat -c %s。

全是基线式这件事我想了一会儿才对上。用户上传的图在前端先画到 canvas 上再用 toBlob 转成 JPEG。我在 Chromium 149 开源构建里导出过一份，读出来的帧头是 SOF0。我自己压的那两张海报用的是图映 ImgIng（https://imging.cn/），也是在这台 Mac 的 Chromium 149 开源构建里导出的，帧头同样是 SOF0。它的 JPG 走浏览器原生编码所以结果跟 toBlob 一样也不奇怪。从浏览器里出来的 JPEG 默认就是基线式。想要渐进式得放到服务端或者用专门的编码库去转。

列表排在最前面的是一张用户上传的风景图和首页横幅，两张都在 1.1 MB 左右。按大小看它俩都该转，可我最后只转了横幅。用户上传的图只出现在详情页里。点进去的人本来就是冲着那张图去的，多等一会儿也能接受。缩略图列表那几张更不值得动，因为渐进式解码要多花时间。我测风景图时基线式解码要 11.1 毫秒，渐进式要 28.3 毫秒，差不多是 2.5 倍。一张图差这十几毫秒没人感觉得到，可一屏几十张缩略图就是另一回事了。首页横幅不一样。它是每个人进来第一眼看到的东西，也正是朋友说刷得最难受的那张。

转之前我先确认了先糊后清到底差多少。我用解码器模拟过只下载了一部分的情况。文件截到前 10% 的时候基线式只画出最上面一条，下面全是灰的。渐进式整张都在只是看着偏软。两者跟原图比出来的 PSNR 是 13.58 对 18.90。截到一半时渐进式已经到了肉眼很难看出差别的 30.97。这组数是解码器模拟出来的，不是浏览器里拍的。我也试过在本机限速截屏想把中间过程拍下来，可截到的画面总是整张下完才出现。

转换用的是 libjpeg-turbo 3.2.0 带的 jpegtran，参数是 -copy all -progressive。它不重新压缩，只是把原来的数据换一种顺序重写一遍。我先让它转到临时文件里再用 djpeg 把转前转后都解码成像素比一遍，完全一致才替换原图。横幅从 1,098,272 字节变成了 1,048,255 字节，小了 4.6%。转一次只要 0.05 秒。省下的 50,017 字节放到整站的 4,537,081 字节里只占 1.1%。我转它从来就不是为了省流量，图的是网慢时那几秒能先看到一整张图。

还有一件事我没法替朋友验证。那组先糊后清的数是模拟出来的。他那边真实的网络下能早多少看到整张图我手上没有数。下次他再打开首页我打算直接问问他。要是你也在犹豫站里的图转不转，可以先用上面那几行脚本把全站 JPEG 列一遍再挑出首屏那一两张大图单独转。