服务端压缩是提升网页加载速度最直接有效的方式之一，核心逻辑是在数据离开服务器前压缩，减少传输体积；gzip兼容性好，brotli压缩率更高（比gzip小15%–20%），需https；nginx中需配置gzip on、min_length、comp_level、types及vary，且仅对文本类资源启用，避免重复压缩图片等已压缩文件。
服务端压缩是提升网页加载速度最直接有效的方式之一，核心逻辑是：在数据离开服务器前就把它“压小”，让网络传输更快、客户端解压几乎无感。现代浏览器全部支持，关键是正确启用和配置。
选对算法和启用时机
Gzip 是兼容性最好、部署最简单的选择，Brotli 压缩率更高（通常比 Gzip 再小 15%–20%），但需 HTTPS 环境且部分旧客户端支持有限。生产环境建议优先配 Gzip，再视情况叠加 Brotli。
- 服务器只对支持压缩的请求响应压缩内容：客户端请求头带 Accept-Encoding: gzip 或 br，服务端才返回压缩体
- 静态资源（如 .js、.css、.html）由 Web 服务器（Nginx/Apache）自动压缩；动态接口（如 API 返回的 JSON）同样可被压缩，只要响应 MIME 类型在配置列表中
- 已压缩文件（如 .jpg、.png、.webp、.mp4）不参与 Gzip/Brotli 压缩——重复压缩无效，还浪费 CPU
Nginx 中关键压缩配置项
在 http 块中配置，不是 server 或 location：
- gzip on; —— 必须开启，否则所有其他 gzip 指令无效
- gzip_min_length 1000; —— 只压缩大于 1KB 的响应，避免小文件压缩后反而因压缩头开销变大
- gzip_comp_level 6; —— 推荐设为 6，平衡压缩率与 CPU 消耗；设 9 虽更小但 CPU 占用明显升高，日常没必要
- gzip_types text/plain text/css application/javascript application/json application/xml+rss image/svg+xml; —— 显式列出要压缩的类型；text/html 默认必压，不用写
- gzip_vary on; —— 让响应头带上 Vary: Accept-Encoding，确保 CDN 或代理缓存能区分压缩/未压缩版本，避免错发
验证是否生效
别只信配置，要用真实请求确认：
- 用 curl 测试：curl -H "Accept-Encoding: gzip" -I https://yoursite.com/app.js，看响应头是否有 Content-Encoding: gzip
- 浏览器开发者工具 → Network → 刷页面 → 点开任意 JS/CSS 文件 → 查看 Response Headers 和 Size 栏（对比 “transferred” 和 “resource” 大小）
- 注意：如果用了 CDN，需确认 CDN 是否透传了 Accept-Encoding，或自身也开启了压缩（如 Cloudflare 的“Auto Minify”不等于 Gzip，需单独开启“Brotli”或“Gzip”）
配合缓存效果翻倍
压缩和缓存不是二选一，而是叠加生效：
- 先压缩再缓存：Nginx 对首次请求压缩一次，结果存入 proxy_cache 或浏览器缓存，后续请求直接返回压缩后的内容，省去重复压缩开销
- 对静态资源设置 long-term cache（如 max-age=31536000），配合文件哈希命名，让压缩后的资源长期复用
- API 响应可设较短缓存（如 max-age=60），但依然值得压缩——哪怕每分钟压一次，也比每次都传 200KB 强
