蜘蛛抓取一個地址，拿到的不是一行标题和一段正文，而是完整的响應体加上头部信息。頁面越大，單次抓取占用的時間、带宽和服務器出口资源就越多。压缩不能提升内容质量，但它是成本最低的一類传輸優化，而且常常被配了一半之後就再没人管。
先確認压缩覆盖了哪些請求
很多站点的压缩配置是從主站 HTML 開始的，配好之後就不再检查。等到图片、脚本、样式、字体、接口 JSON 陆續加上，压缩規則還停留在最初那一條。结果是首頁响應体积正常，列表頁和内頁却在裸传。
需要覆盖的通常包括：
- HTML 文档，尤其是正文較長的詳情頁與列表頁；
- JS、CSS 等文本類型的静態资源；
- JSON、XML、SVG、站点地图和 RSS 這類文本响應；
- 体积較大的纯文本接口返回。
反過来，图片、视频、音频、压缩包、字体這些本身已经是压缩格式的资源，不需要再走一遍文本压缩，重复處理只會白耗 CPU。
几種常见的配置偏差
只寫了一種压缩方式
只開 Gzip 而不開 Brotli，通常還能用，但文本资源的体积會比開 Brotli 大一些。反過来，只開 Brotli 而客戶端不支持时没有回退，部分抓取工具可能拿到未压缩内容。比較稳妥的做法是两者都開，由服務端或 CDN 按請求头协商。
压缩阈值設定不当
压缩本身有開销，太小的响應压完可能比以前更大。把阈值設定在几百字节到 1KB 附近比較常见。但阈值也不能设得太高，否則稍長一点的片段就被漏掉了。
预压缩文件與動態压缩打架
如果服務器已经為静態文件生成了 .gz 或 .br 版本，又同时開着動態压缩，可能出現重复压缩或版本過期的情况。构建产物更新後，记得同步刷新预压缩文件，否則抓取端拿到的可能是舊内容。
传輸方式與長度声明不一致
压缩之後响應長度會變化。如果头部仍声明原来的長度，或者干脆缺失長度信息，抓取端在讀取时可能出現等待或截断。這块通常交给服務器和 CDN 處理，但要確認没有中間层把它改坏。
一份简單的自查清單
- 抽取首頁、栏目頁、詳情頁、列表頁各一到两個地址，確認响應头里带有压缩标识。
- 對照静態资源目錄，確認脚本、样式、JSON、SVG 都在压缩范围内。
- 检查压缩阈值，避免小响應被無意义压缩，也避免大响應被跳過。
- 確認预压缩文件與源文件同步更新，没有残留舊版本。
- 查看服務器與 CDN 的 CPU 占用，判断動態压缩是否带来明顯负担。
- 對比開啟前後的响應体大小，確認收益是真實的。
怎么驗證
命令行工具是最直接的驗證方式。用 curl 带上压缩协商參數請求目标地址，然後查看响應头里的内容编碼字段，再對比压缩前後的字节數。對同一地址连續請求两次，一次声明支持压缩，一次不声明，两次的体积差就是压缩带来的收益。
如果响應头里没有内容编碼字段，而响應体又明顯偏大，先排查压缩模块是否加载、規則是否命中了這個路径，再去看 CDN 侧是否把头部改寫了。
几個需要留意的邊界
压缩不是越激進越好。CPU 和带宽之間需要平衡，動態压缩級別調得過高，在高並發抓取时反而會拖慢响應。静態资源更适合在构建阶段预压缩，動態頁面交给服務器按负载决定。
另外，压缩解决的是传輸体积，不解决内容质量。一個结构混乱、正文稀薄的頁面，压得再小也仍然是低價值頁面。把压缩当作基础设施的一部分，做完之後回到内容和结构本身，才是更合理的顺序。
小结
响應压缩属于一次配置、長期受益的事情，但前提是配置真的在生效。定期抽查几個代表性地址，確認压缩覆盖范围、阈值和预压缩文件都還在正确狀態，比一次性配完再也不看要可靠得多。