HTML压缩本身不提升传输效率，必须与Gzip/Brotli等传输层压缩配合才有效；单独minify仅减小磁盘体积，若响应头无Content-Encoding: gzip或br，则Network面板中Size不会变化。
HTML 本身不是音视频，不能像 MP3 那样靠心理声学模型丢频段；所谓“HTML 在低带宽下的极致压缩”，本质是两件事：一是减小原始 HTML 字节数（文本级压缩），二是确保它被高效编码传输（传输级压缩）。单独做前者几乎无效，后者才是决定性环节。
为什么 html-minifier 压完 Size 没变？
因为浏览器 DevTools 的 Size 列显示的是实际发出去的字节数，它只认 Content-Encoding 响应头。你本地用 html-minifier-terser 把 index.html 从 120KB 压到 85KB，但若服务器没开 Brotli 或 Gzip，那这 85KB 就是原样发出去的——Size 还是 85KB，不是“更小了”，只是没被二次压缩。
常见错误现象：
- 本地构建后文件体积下降，线上
Network面板里Size和Content几乎相等 - Nginx 配了
gzip on，但漏了gzip_types text/html，导致 HTML 被跳过压缩 - 误信
<meta http-equiv="Content-Encoding" content="gzip">能起作用（完全无效）
哪些 HTML 压缩操作真影响传输体积？
只有在服务端压缩未启用或弱效时，以下操作才有可测量收益：
立即学习“前端免费学习笔记（深入）”；
-
removeComments: true：注释是纯冗余字节，删一个<!-- foo -->就少 11 字节 -
collapseWhitespace: true：但要确认没破坏display: inline-block元素间的间隙（可通过font-size: 0或注释消除空白修复） - 省略布尔属性值：
required="required"→required，HTML5 合法且省字符 - 移除冗余
type：<script type="text/javascript">→<script>
不推荐：
-
minifyJS: true或minifyCSS: true：HTML 压缩器调用的是简易封装，不如terser/cssnano真正走 AST，还容易毁模板字符串或 source map - 对动态 SSR 输出硬套
html-minifier：PHP/Node.js SSR 应优先保证输出流压缩（如ob_gzhandler），而非预处理 HTML 字符串
Nginx 配 Brotli + Gzip fallback 的实操要点
Brotli 比 Gzip 多压 15–20%，但它不是简单“开个开关”就能用。关键配置差异：
- Brotli 必须 HTTPS，且 Nginx ≥ 1.11.6；Safari 11+、Chrome 60+ 支持，旧安卓 WebView 可能不认
br - 别同时开
gzip on和brotli on：浏览器按Accept-Encoding顺序选，但服务器若都响应，可能错乱；应设gzip off，仅brotli on，再配gzip on作降级 -
brotli_comp_level 6是平衡点（1–11），11压得狠但 CPU 升高，静态 HTML 可用；动态内容建议 ≤ 4 - 必须显式声明类型：
brotli_types text/html text/css application/javascript，text/html不在默认列表里
验证是否生效：
- Chrome DevTools →
Network→ 找 HTML 请求 → 看Response Headers里有没有Content-Encoding: br或gzip - 对比
Size（传输体积）和Content（解压后体积）：差值越大，压缩越有效 - 用
curl -I -H "Accept-Encoding: br" https://yoursite.com/index.html直接测，排除浏览器缓存干扰
真正卡住 HTML 加载的，从来不是多几个空格，而是 Content-Encoding 缺失、同步脚本阻塞解析、或首屏 HTML 里混了未压缩的内联 JSON/JS。压缩只是基建，不是银弹；上线前务必用真实弱网环境（如 Chrome 的 Slow 3G）跑一遍 Lighthouse，看 TTFB 和 FCP 是否真有改善。
