很多站长一上来就开 gzip，以为万事大吉，其实 gzip 只压缩文本，图片、视频、字体这些大块头它管不着。如果页面里塞满没优化的高清图，gzip 开了也白搭。先看两个硬指标：Content-Encoding: gzip 是否真返回了，以及 Content-Length 有没有明显变小。用 curl -I -H "Accept-Encoding: gzip" https://你的域名/ 就能看到。
一、先确认 gzip 到底有没有生效
Nginx 默认只对 text/html 压缩，其他类型需要手动加。检查配置里有没有这几行：
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;
gzip_min_length 1k;
gzip_comp_level 5;
gzip_vary on;改完执行 nginx -t 然后 nginx -s reload。如果 gzip_types 漏了 js、css，那这些文件就没压缩，页面自然快不起来。另外 gzip_vary on 不加的话，CDN 或代理可能缓存错版本，导致部分用户拿到未压缩内容。
二、图片、视频、字体是真正的拖油瓶
gzip 对 JPEG、PNG、MP4、WOFF2 基本无效，因为这些格式本身已经压缩过，再压反而浪费 CPU。一个首页如果放了 5 张 2MB 的图，gzip 把 HTML 从 50KB 压到 10KB，用户感知几乎为零。正确做法是：图片用 WebP 或 AVIF，配合 srcset 按屏幕宽度加载；视频用 HLS 或先传 CDN；字体只保留实际用到的字重和字符集。可以用 du -sh /path/to/static/* 看哪个目录最大，优先处理。
三、TTFB 高和 gzip 无关，查后端和网络
gzip 只影响传输阶段，如果服务器响应本身要 2 秒，压缩后还是 2 秒。用 curl -w "%{time_starttransfer}n" -o /dev/null -s https://你的域名/ 看 TTFB。超过 500ms 就要查 PHP-FPM 进程数、数据库慢查询、上游超时。Nginx 反代场景下，proxy_read_timeout 设太小会导致重试，反而更慢。另外 DNS 解析、TLS 握手、CDN 回源这些环节，gzip 都帮不上忙。
四、压缩级别和缓存策略别踩坑
gzip_comp_level 开到 9 并不划算，CPU 飙高但体积只比 5 小几个百分点。建议 4-6 之间。更关键的是静态资源缓存：给 CSS、JS、图片加 expires 30d; 和 add_header Cache-Control "public, immutable";，让浏览器别再重复下载。如果每次访问都重新拉一遍，gzip 省的那点流量根本不够看。最后用 Lighthouse 或 WebPageTest 跑一遍，看 Content Download 和 Waiting (TTFB) 哪个占大头，再对症下药。
