很多人一看到“压缩率高”，下意识觉得“文件小了，肯定快了”。但现实往往不是这样——压缩率太高，反而可能让网页加载更慢。
压缩不是越狠越好
比如你用 gzip 把一个 1MB 的 JS 文件压到 200KB，看着省了 80% 流量，但浏览器得花更多 CPU 时间去解压。低端手机、老款笔记本上，解压过程卡个 200–300ms 很常见。用户点开页面，白屏时间反而变长了。
真实场景对比
某电商首页的 banner 图用了 WebP 格式，压缩率设到 95（最高100），图片从 480KB 压到 110KB。结果在一台 i3-7100 + Chrome 115 的机器上，首屏渲染延迟了 370ms——因为解码耗时翻倍。换成压缩率 75（文件 190KB），整体加载反而快了 120ms。
服务器和浏览器都在“权衡”
现代服务器（如 Nginx）默认 gzip 压缩级别是 1–6，不是最高 9。为啥？因为级别 9 虽然体积最小，但 CPU 占用高、延迟大，对并发请求多的网站反而是负担。浏览器也一样：Safari 对 Brotli 级别 11 的支持不全，强行用反而触发降级回 HTTP/1.1 + gzip，得不偿失。
简单自查建议
打开 Chrome DevTools → Network 标签页，找一个 JS/CSS 文件，看它的 Content-Encoding 和 Transfer Size，再右键 → “Open in Sources”，观察它在 Waterfall 里“Waiting (TTFB)”之后的“Content Download”和“Finish”之间有没有明显空白——那可能就是解压或解析卡住了。
另外，别光盯着“压缩率”，更要看：传输时间 + 解压时间 + 解析时间 这三段加起来是不是最短。有时候多传 50KB，换来解压快 200ms，用户感知更流畅。