适用读者：要给静态资源"再快一点"的人。
前置：S14-J02。
实测环境：Vite 5.4.21 / gzip 1.12（2026-11-05）。
覆盖旧文：394(257) 396(356) = 613 点。
覆盖扩展：E-S14-009（gzip_static 原理）。
上一篇：S14-J02 · 打包分析：找出最大的 JS
下一篇：S14-J04 · SPA 首屏。

---

1. 一句话结论

gzip 是"每次请求现压"（耗 CPU），gzip_static 是"部署时预压好、请求时直接发"（零 CPU）。两者压缩结果几乎一样，差别在服务器开销。

实测（vendor 65,849 B）：

压缩级别	体积	相对原始
无	65,849 B	100%
gzip -1	29,126 B	44.2%
gzip -6	25,913 B	39.3%
gzip -9	25,886 B	39.3%

两个结论：

观察	结论
-1 与 -9 差 11%	压缩级别有收益，但边际递减
-6 与 -9 几乎一样	用 -6 就够（省 CPU）

---

2. 三种部署方式（E-S14-009）

方式	CPU 成本	首次请求
不压缩	0	慢
动态 gzip（nginx gzip on）	每次请求压缩	慢（第一次）
gzip_static	0（部署时压好）	快

nginx 配置：

gzip_static on;          # 直接发 .gz 文件（需编译进模块）
gzip on;                 # 没有 .gz 时动态压缩
gzip_min_length 1k;
gzip_types text/css application/javascript application/json;

"为什么要同时开两个"：gzip_static 找不到 .gz 时回退到动态压缩——双保险。

---

3. 构建期生成 .gz（Vite 侧）

# 实测：构建后手动预压缩
gzip -9 -c dist/assets/vendor-*.js > dist/assets/vendor-*.js.gz
# 预压缩文件: 25,886 B

方式	说明
vite-plugin-compression	构建时自动生成 .gz/.br
部署脚本里 find dist -name '*.js' -exec gzip -6 {} \;	简单可控
CI 里做	与构建解耦

Brotli 的取舍：br 比 gzip 再小 10–20%，但IE/老浏览器不支持（现代浏览器都支持，需 HTTPS 才有意义）。

---

4. CDN 的两个真实前提

前提	说明
文件名带 hash	否则 CDN 缓存会拿到旧文件（A01）
回源策略	CDN 缓存失效/预热要配好

"CDN 快在哪"：就近节点 + 静态资源长缓存——不是"压缩"，压缩是 J03 前半段的事。

判据："用户分布跨地区吗？" 跨 → CDN 值得；单地区小流量 → 意义有限。

---

5. 五个误区

误区	真相
"压缩级别越高越好"	-6 与 -9 几乎一样（实测）
"动态 gzip 和 gzip_static 一样"	前者耗 CPU
"CDN 能替代压缩"	是两件事（缓存 vs 压缩）
"文件名不用 hash 也行"	CDN/浏览器会缓存旧版本
"Brotli 一定更好"	需 HTTPS + 现代浏览器

---

6. 自检

1. gzip 与 gzip_static 的差别？
2. 实测里 -1 与 -9 差多少？该用哪个？
3. gzip_static 找不到 .gz 会怎样？
4. CDN 生效的两个前提？
5. Brotli 的两个限制？

---

7. 下一篇

S14-J04 · SPA 首屏为什么慢

压缩讲完，下一篇把首屏时间拆成三段，看每一段能优化什么。

---

本篇属于系列《S14 · 前端与可视化》。旧文来源：A-394/396；扩展点 E-S14-009。压缩比为实测。