HTML本身不压缩，真正起效的是传输层的Content-Encoding: br或gzip响应头；验证需查Chrome DevTools Network中index.html的Response Headers是否含该字段，并对比Size与Content体积。
HTML 本身不“压缩”，真正起效的是传输层的 Content-Encoding: br 或 Content-Encoding: gzip 响应头；本地删空格、去注释（如用 html-minifier-terser）在现代部署中收益极低，除非你卡在没开服务端压缩的老旧环境里。
怎么验证 Brotli/Gzip 是否真生效
别看构建后文件大小，那只是幻觉。打开 Chrome DevTools → Network → 刷新页面 → 找到 index.html 请求 → 查看 Response Headers：
- 必须有
Content-Encoding: br（Brotli）或Content-Encoding: gzip（Gzip） - 对比 “Size” 列（传输体积）和 “Content” 列（解压后体积）：若 Size 接近 Content，说明根本没压缩
- 如果看到
Vary: Accept-Encoding，说明服务端正确区分了编码版本，CDN 缓存才不会错乱
Nginx 配置 Brotli 要避开三个硬坑
Brotli 不是装个模块就省 20% 带宽——默认配置下，它可能比 Gzip 还慢、还大。关键参数必须手动调：
-
brotli on;必须配，但光开这个没用 -
brotli_comp_level 5;：HTML/JS/CSS 推荐值，-q 4～6是黄金区间；7+压缩耗时翻倍，边缘节点扛不住 -
brotli_window 256k;（即lgwin 18）：窗口太小（如lgwin 16）识别不了跨区块重复模板，压缩率掉 8–12% -
brotli_types text/html text/css application/javascript application/json image/svg+xml;：严禁加text/plain或通配符，否则可能对二进制响应误压 -
brotli_min_length 256;：小于 256 字节的响应（比如空 JSON、304）跳过压缩，避免负优化
Gzip 作为降级方案不能只写 gzip on
很多 Nginx 配置只开 gzip on，结果 Brotli 失败时直接裸传 HTML。必须显式声明降级逻辑：
立即学习“前端免费学习笔记（深入）”；
-
gzip_vary on;：和brotli_vary on配合，确保 CDN 缓存不同编码版本 -
gzip_comp_level 6;：Gzip 级别别设太高，6是吞吐与压缩率平衡点；9在高并发下会拖慢首字节时间 -
gzip_types和brotli_types必须严格一致，否则同一资源可能一个路径返回 gzip、另一个返回 br，缓存雪崩 - 检查
gzip_disable "msie6";这类旧规则——IE6 已死，留着反而干扰现代浏览器协商
预压缩 .br 文件比动态压缩更稳
动态压缩依赖 CPU 实时计算，弱网首屏容易卡在压缩环节。对静态 HTML，优先走预压缩：
- 构建后执行：
brotli -q 5 -k ./dist/index.html，生成index.html.br - Nginx 加
brotli_static on;，自动匹配并返回.br文件 -
-k参数保留原始 mtime，让 ETag 和缓存校验不翻车 - 注意：预压缩文件必须和源文件同目录、同名 +
.br后缀，Nginx 不会帮你找上级路径
最常被忽略的一点：Brotli 对小文件（brotli_min_length 和 brotli_window 的组合是否合理，直接决定你看到的是“省了 15%”还是“多花了 20ms 首字节延迟”。
