传输压缩是站点运营里成本最低的优化之一：服务器开一个开关，HTML、CSS、JS 的体积通常能降一半以上，访客加载更快，蜘蛛抓取同样的页面也能省下带宽和时间。但现实中经常出现两种情况，一是根本没开，二是看起来开了却没生效，或者压错了对象。这篇就把自查的步骤和常见坑捋一遍。
先确认压缩到底有没有生效
不要只在服务器配置文件里看到 gzip on 就放心。用 curl 检查最直接：带上 Accept-Encoding 请求头，看返回头里有没有 content-encoding: gzip 或 br。浏览器开发者工具的 Network 面板同样能看到每条请求的响应头，注意对比“资源大小”和“传输大小”两列，后者才是真正跑在网线上的数据量。
如果某个 CSS 文件资源大小 300KB，传输大小也是 300KB，基本可以判断压缩没起效，或者响应头被中间层丢掉了。反过来，如果传输大小只有几十 KB，说明压缩在正常工作。
哪些类型值得压，哪些别碰
- 值得压：HTML、CSS、JavaScript、JSON、XML、SVG、纯文本。这些是文本，压缩比通常很高。
- 不要压：JPEG、PNG、WebP、GIF、MP4、MP3、WOFF2 等本身已压缩过的格式。再压一遍几乎不会变小，反而浪费 CPU。
- 谨慎处理：字体文件、已经是 gzip 或 zip 的归档包。重复压缩有时体积还会微增。
gzip 和 Brotli 的关系
Brotli 在文本类资源上通常比 gzip 再小一成到两成，现代浏览器普遍支持。常见做法是优先返回 br，客户端不支持时回退 gzip。开启前先确认服务器或 CDN 是否支持，避免为了新格式把老访问者挡在门外。
如果是静态预压缩，源文件更新后记得重新生成 .br 和 .gz 文件，否则客户端拿到的还是旧版本内容。这一点和缓存刷新是同一个道理，很容易被忽略。
容易踩的几个坑
- 只压了首页：检查的是首页，静态资源却走 CDN 或另一台机器，那边没开。要按域名、按目录逐个确认。
- 双压缩：源站和 CDN 都开了动态压缩，文件被压了两层。一般让其中一层负责即可。
- 压缩了小文件：1KB 以下的响应压缩后可能更大，还多耗资源，可以按大小阈值跳过。
- 动态压缩压垮 CPU：高并发下每次请求都现压，CPU 会明显上升。静态资源建议预压缩，动态页面配合缓存使用。
- 误压二进制文件：下载包、图片、视频被压缩后，客户端解出来可能打不开，要按 MIME 类型设白名单。
一份可执行的自查清单
- 用 curl 或浏览器网络面板确认 HTML、CSS、JS 都带 content-encoding。
- 对比压缩前后的传输大小，确认压缩比在合理范围。
- 确认图片、视频、字体等已排除在压缩名单之外。
- 确认 CDN 与源站没有重复压缩。
- 确认预压缩文件与源文件版本一致。
- 观察 CPU 占用与响应时间，确认动态压缩没有带来明显负担。
压缩是省带宽、省时间的手段，不是排名手段。压好了不会自动带来排名，压坏了却可能让页面变慢或下载损坏。
传输压缩不是配一次就永远不用管的项目。换服务器、上 CDN、改配置、调缓存策略，每一个动作都可能让压缩悄悄失效。把它放进上线检查表，配合抓取日志和性能数据一起看，问题通常能早一步发现。