Chrome DevTools中Size未变说明HTML压缩未生效，因真实传输体积取决于Content-Encoding响应头而非源码体积，需确保Nginx正确配置gzip或brotli并启用对应MIME类型。
Chrome DevTools 里 Size 没变，说明 HTML 压缩根本没生效
别盯着构建后 index.html 文件大小看——那只是磁盘体积。真实传输体积由 Content-Encoding 响应头决定。如果 Network 面板中请求的 Size 和 Content 几乎相等，就证明没压缩。
常见误操作包括：
- 用了
html-minifier-terser但 Nginx 漏配gzip on;或brotli on; - 写了
<meta http-equiv="Content-Encoding" content="gzip">—— 完全无效，浏览器不认这个 - 静态托管服务（如某些 Git Pages）默认关闭传输压缩，本地 minify 后上传，线上照样明文发
Nginx 开启 Brotli 必须调的三个参数
Brotli 不是装了模块、开了 brotli on; 就自动省带宽。默认配置下它可能比 Gzip 更慢、更大。
关键参数必须显式设：
立即学习“前端免费学习笔记（深入）”；
-
brotli_comp_level 5;：HTML/JS/CSS 的安全起点；4～6 是黄金区间；7+ 压缩耗时陡增，边缘节点容易卡住 -
brotli_min_length 1024;：避免压缩几十字节的响应，白耗 CPU -
brotli_types text/html text/css application/javascript application/json image/svg+xml;：必须手动列全，text/html不会自动继承
漏掉 brotli_min_length 或乱设 brotli_comp_level 11，会导致 TTFB 升高、首屏延迟上升，而体积只小 1%～2%。
为什么还得留着 gzip，哪怕只开 brotli
不是为了兼容老浏览器——Chrome 52+、Firefox 44+、Edge 15+、Safari 16.4+ 全支持 br。真正原因是企业内网代理、老旧 CDN 节点会 strip 掉 Content-Encoding: br 头，导致请求直接失败。
正确做法是：
- 关掉
gzip运行时压缩：gzip off; - 但保留
gzip_static on;，用于 fallback 场景（比如预生成的.gz文件） - 同时启用
brotli_static on;，搭配预压缩的.br文件，绕过运行时开销
这样客户端发 Accept-Encoding: br,gzip，服务端优先回 br；遇到 strip 行为，CDN 或代理可能降级到 gzip，而不是裸奔传明文。
哪些资源死都不能压，压了反而拖慢页面
传输层压缩不是“所有文本都该压”。压错类型 = 白耗 CPU + 增加延迟。
必须压的类型：
-
text/html、text/css、application/javascript -
application/json、image/svg+xml、text/plain
绝对禁压的类型：
-
.jpg、.png、.webp、.mp4、.pdf—— 它们本身已是高压缩格式，再套一层只会增大体积、拖慢响应 - PHP 动态输出需显式声明 MIME 类型：
application/x-httpd-php，否则location ~ \.php$返回的内容不会被gzip/brotli捕获
最容易被忽略的是 SVG：它本质是 XML 文本，必须进 brotli_types 列表，否则 CDN 可能按 image/svg+xml 直接透传，跳过压缩。
