打开一个网页，等它慢慢“爬”出来——你有没有想过，是不是图片压得太狠、JS 文件缩得太小，反而拖慢了速度？压缩率高，就一定快吗？
压缩率不是越高压得越快
压缩率是原始大小和压缩后大小的比值。比如一张 2MB 的 PNG 图片，用 TinyPNG 压到 200KB，压缩率就是 90%。听起来很美，但浏览器拿到这 200KB 后，得先解压再渲染。如果压缩算法太复杂（比如用了 zopfli 或 Brotli 的超高压缩档位），CPU 解压时间可能反超节省下来的传输时间。
真实场景：手机上更明显
拿微信内置浏览器举例：你发了个 1080p 的 JPG，后台用 WebP 有损压缩到 85% 质量（约 300KB），加载顺滑；但要是硬压到 40% 质量（80KB），文件虽小，低端安卓机解码 WebP 时会卡顿半秒——人眼反而觉得“更慢”。
关键在“平衡点”，不在“极限值”
实测过几组数据：
• 用 gzip -6 压 JS：120KB → 38KB，首屏解析快 120ms
• 改用 gzip -9：120KB → 35KB，但解压多花 80ms，净收益只剩 40ms
• 换成 Brotli -11：120KB → 32KB，解压却要 150ms，整体慢了 30ms
常见压缩工具默认档位参考：
gzip 默认：-6（平衡）
zopfli 默认：等效 gzip -11（慢，适合离线预压）
ImageMagick -quality 75：JPG 推荐档位
cwebp -q 75：WebP 实用起点所以别一上来就调“最高压缩”，先看设备类型、网络环境、资源用途。静态图标可以压狠点，首页首屏 JS 和关键 CSS，宁可多传 10KB，也要保证秒解。
真正拖慢加载的，常是别的事
压缩率再低，也救不了没开 HTTP/2 的老服务器；再高的压缩率，也盖不住图片没配 srcset、在 5G 下还塞个 3MB 视频 poster。加载速度是链条，压缩只是其中一环——拧太紧，整条链反而容易崩。