不少站点在做性能自查时，第一反應是压图片、加缓存，却漏掉了更基础的一件事：HTML、CSS、JS 這些文本资源，很可能是原样發出去的。一個 200KB 的 HTML 文档，正常配置压缩後通常只剩三四十 KB。對用戶来说是打開快一点，對搜尋引擎的抓取程序来说，則是同样的抓取時間和带宽能多看几個頁面。
為什么压缩值得單獨拿出来查
压缩不像換服務器那样有明顯感知，它属于「預設開着就没人提，預設關着也没人喊」的配置。很多問题出現在這几種场景：服務器迁移後没带上原来的压缩配置；新上的 CDN 回源时把压缩头丢掉了；或者站点為了省 CPU，把压缩等級調得极低，几乎等于没压。
- 頁面体积偏大，首屏资源下载時間被拉長；
- 抓取程序在相同時間预算内能取的頁數變少；
- 移動網絡下用戶等待明顯，跳出率容易上升；
- 带宽帳單比预期高，但排查时找不到原因。
自查清單
一、確認压缩是否真的生效
不要只看配置文件里寫了什么，要看响應里實际返回了什么。用浏览器開發者工具的 Network 面板，点開一個 HTML 文档，看响應头里有没有 Content-Encoding: gzip 或 br，同时對比 Size 和 Transferred 两列的差距。也可以直接在命令行里带請求头訪問，观察返回结果。
二、看压缩覆盖了哪些類型
压缩最该覆盖的是文本類资源：HTML、CSS、JS、JSON、SVG、XML，以及纯文本的接口返回。有些服務器配置只對 .html 生效，CSS 和 JS 依然裸奔，這时候頁面看着能開，實际传輸量並不小。建议逐類抽查，而不是抽查一個頁面就下结论。
三、別對已经压過的文件再压一遍
JPEG、PNG、WebP、WOFF2、MP4 這類格式本身已经做過压缩，再用 Gzip 處理一遍，往往只增加 CPU 開销，体积几乎没有變化。配置里如果寫的是「全站所有類型都压」，可以把這几類排除掉，把 CPU 留给真正受益的文本资源。
四、CDN 和源站是否一致
压缩可以在源站做，也可以在 CDN 邊缘做，两邊都做容易重复，两邊都不做就直接漏掉。自查时至少要確認一件事：用戶實际拿到的那份响應，压缩是不是生效的。另外，如果按請求头来决定是否压缩，记得让缓存能区分開压缩和未压缩的版本，否則可能出現一部分用戶拿到乱碼或異常内容。
几個容易踩的坑
压缩等級不是越高越好。等級調到最高，体积可能只比中等档小几個百分点，但 CPU 占用明顯上升。對绝大多數站点，選一個中間档位，把稳定性放在第一位更划算。
- 只测首頁：首頁往往是特殊處理的，内頁和列表頁才是大多數抓取目标；
- 忽略動態頁面：模板渲染出来的 HTML 同样需要压缩；
- 改完不复查：压缩配置變更後，最好隔天再抽查一次，確認没有回滚或被覆盖；
- 只看体积不看内容：確認解压後頁面顯示正常，別只顾着數字變小。
可以照着做的落地步骤
- 挑三類頁面各一個：首頁、栏目列表頁、正文詳情頁；
- 分別查看响應头中的编碼字段，记錄是否压缩、用了哪種算法；
- 對比压缩前後的传輸体积，估算全站节省的量級；
- 检查配置中是否包含图片、字体、视频等已压缩格式，能排除就排除；
- 確認 CDN 與源站的压缩策略不冲突，缓存能正确区分；
- 把结论和修改记錄寫進运维文档，方便下次迁移时對照。
传輸压缩属于投入很小、收益相對稳定的一類優化。它不會直接带来收錄或排名上的變化，但會让頁面更轻、抓取更省力，属于站点运营里那種「做完了平时想不起来，出問题时才發現關键」的基础項。每隔一段時間顺手查一遍，比等到带宽告警或用戶投诉再去翻配置要轻松得多。