HTML、CSS、JavaScript 這類文本文件有個特点：重复字符多、可预测性高，压缩率通常能到 60% 以上。也就是说，一個 100KB 的 HTML 頁面，压缩後可能只有 20 到 30KB。如果服務器没有開啟压缩，這部分体积就原样發给了訪客和蜘蛛，属于白白浪費的等待時間。
這件事值得單獨拿出来查一次，因為它成本极低、影响面却覆盖全站每一個頁面。
先確認：到底压了没有
別只看配置文件，要看真實响應。最简單的做法是用命令行工具請求两次：一次带上 Accept-Encoding: gzip 請求头，一次不带，然後對比两次响應的 Content-Encoding 和 Content-Length。
- 带压缩請求头时，响應里應该出現 Content-Encoding: gzip 或 Content-Encoding: br。
- 不带时，体积應明顯更大；如果两者体积完全一样，基本說明压缩没生效。
- 浏览器開發者工具的 Network 面板里，Size 一列通常顯示传輸体积，Content 一列顯示解压後体积，差异就是压缩收益。
抽查對象不要只挑首頁，至少覆盖：首頁、一個栏目列表頁、一篇内容頁、一個 CSS 文件、一個 JS 文件、站点地图文件。
哪些類型该压，哪些別压
大体原則是：文本類压缩收益高，二進制已压缩格式压了也白压。
- 建议開啟：text/html、text/css、application/javascript、application/json、image/svg+xml、XML（含站点地图和 RSS）。
- 不必開啟：JPEG、PNG、WebP、AVIF、MP4、WebM、WOFF2、ZIP 等。這些格式本身已经過压缩，再走一遍 gzip 只是消耗 CPU，体积几乎不會變小。
動態压缩與预压缩的選擇
動態压缩是每次請求时現场压一遍，配置简單但吃 CPU；预压缩則是提前把 .gz 或 .br 文件生成好放在同目錄，請求时直接發送，几乎零開销。流量較大的站点，建议静態资源走预压缩，動態頁面再考虑動態压缩。
無论用哪種方式，运营上要留意一件事：内容更新後，舊的预压缩文件有没有跟着重新生成。改了 CSS 却還在發舊的压缩文件，前端表現就會對不上。
別漏掉 Vary 响應头
如果 CDN 或反向代理是按 URL 缓存，却没有区分压缩與非压缩版本，就可能把压缩版發给不支持的客戶端，或者把未压缩版發给所有客戶端。加上 Vary: Accept-Encoding，或者干脆让 CDN 统一负责压缩、源站關閉压缩，都是可行做法，但不要两层同时压。
压缩級別的取舍
級別不是越高越好。gzip 一般设在 5 到 6 已经接近收益上限，Brotli 质量设 4 到 6 性價比通常較好。再往上調，体积减少有限，CPU 占用却明顯上升，高峰期容易變成瓶颈。
一份可照着走的自查清單
- 抽查各類资源的响應头，確認有 Content-Encoding。
- 確認源站與 CDN 没有重复压缩，避免二次压。
- 確認响應头里有 Vary: Accept-Encoding，缓存不會串味。
- 確認缓存策略對压缩版本和非压缩版本的處理一致。
- 確認静態资源有预压缩文件，且内容更新後會重新生成。
- 確認极小文件（1KB 以下）不必强压，收益有限。
- 換服務器、換 CDN、調整缓存規則後，重新驗證一遍。
几個常见誤区
- 以為配置文件里寫了 gzip on 就萬事大吉，没看真實响應。
- 只压了 HTML，漏掉 CSS、JS、JSON 和站点地图。
- 對图片再压一次，徒增 CPU 開销。
- 在源站開了压缩，CDN 又压一遍，结果头部信息混乱。
传輸压缩算不上什么高級技巧，更像一次性的基础设施检查。花十几分钟確認一遍，把這几個检查点寫進运维清單，之後每次环境變更时复测一次就够了。