蜘蛛抓取一个地址，拿到的不是一行标题和一段正文，而是完整的响应体加上头部信息。页面越大，单次抓取占用的时间、带宽和服务器出口资源就越多。压缩不能提升内容质量，但它是成本最低的一类传输优化，而且常常被配了一半之后就再没人管。
先确认压缩覆盖了哪些请求
很多站点的压缩配置是从主站 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 和带宽之间需要平衡，动态压缩级别调得过高，在高并发抓取时反而会拖慢响应。静态资源更适合在构建阶段预压缩，动态页面交给服务器按负载决定。
另外，压缩解决的是传输体积，不解决内容质量。一个结构混乱、正文稀薄的页面，压得再小也仍然是低价值页面。把压缩当作基础设施的一部分，做完之后回到内容和结构本身，才是更合理的顺序。
小结
响应压缩属于一次配置、长期受益的事情，但前提是配置真的在生效。定期抽查几个代表性地址，确认压缩覆盖范围、阈值和预压缩文件都还在正确状态，比一次性配完再也不看要可靠得多。