优先选html-minifier-terser：它支持更激进的JS/CSS内联压缩，带宽≤3Mbps时体积节省更显著，但需接受构建时间延长0.5–1秒和CPU开销增加15–20%；而html-minifier仅适合CPU吃紧、带宽≥5Mbps或需兼容老构建链路的场景。
选 html-minifier 还是 html-minifier-terser？看压缩后体积和 CPU 开销
如果你的服务器带宽紧张（比如恒创科技轻量服务器仅配 1–5 Mbps），HTML 文件每减少 1KB，每月百万次访问就能省下约 1 GB 流量。但压缩本身要消耗 CPU，低配服务器（如 2核4G）上用错工具反而拖慢响应。
常见错误现象：html-minifier 默认不压缩内联 <script> 和 <style>，导致实际体积只降 10%；而 html-minifier-terser 内置更激进的 JS/CSS 压缩逻辑，但会多占 15–20% CPU 时间。
-
html-minifier更适合：带宽中等（≥5 Mbps）、CPU 资源吃紧、需兼容老构建链路（如 gulp-htmlmin） -
html-minifier-terser更适合：带宽 ≤3 Mbps、静态页为主、能接受构建时间延长 0.5–1 秒 - 必须启用
collapseWhitespace: true和removeComments: true，否则体积节省不足 5% - 慎用
minifyJS: true：若 HTML 中含大量第三方统计脚本（如百度统计），压缩可能破坏其执行逻辑
gzip_static on 配合预压缩，避免每次请求都跑压缩逻辑
NGINX 的 gzip_static on 不是“自动压缩”，而是直接返回同名的 .gz 文件。这对低带宽服务器极关键——它把压缩从运行时移到构建时，彻底卸载 CPU 压力。
使用场景：你用 Webpack/Vite 构建静态站，或 CI 流程中生成 index.html.gz，而非靠 NGINX 实时压缩。
立即学习“前端免费学习笔记（深入）”；
- 必须提前生成
.gz文件，且文件名严格匹配（index.html→index.html.gz），NGINX 不会自动创建 -
gzip_static on优先级高于gzip on，若两者共存，未命中 .gz 文件才回落到实时压缩 - 搭配
gzip_vary on，防止 CDN 缓存错乱（尤其在有代理层时） - 注意：部分轻量服务器默认禁用
gzip_static模块，需确认nginx -V 2>&1 | grep -o with-http-gzip-static-module
避免 html-minifier 的 removeScriptTypeAttributes 导致现代 JS 加载失败
很多教程推荐开启 removeScriptTypeAttributes: true 来删掉 <script type="module"> 中的 type，但这会让浏览器把 ES Module 当作 classic script 执行，直接报错。
这个问题在低带宽场景下更隐蔽：HTML 体积是小了几十字节，但 JS 执行失败导致页面白屏，用户反复刷新反而推高总流量。
- 只对
<script>（无type）或type="text/javascript"安全启用该选项 - ES Module、JSX、TSX 输出的 HTML 必须保留
type="module"或type="importmap" - 检查构建产物中是否混用多种
type：一个页面里既有type="module"又有type="text/javascript"，就别动这个开关 - 替代方案：用
removeRedundantAttributes删掉重复的language、charset等无效属性，更安全
CDN 边缘压缩与本地 html-minifier 的分工边界
如果你用了 Cloudflare、阿里云全站加速这类带边缘 HTML 压缩的 CDN，本地再跑 html-minifier 就是重复劳动，甚至因两次压缩导致注释残留或空格错位。
性能影响明显：一次 html-minifier 处理 1MB HTML 在 2核服务器上约耗 300ms CPU 时间，而 CDN 边缘压缩是毫秒级且不占你服务器资源。
- 先确认 CDN 是否开启 HTML 压缩（Cloudflare 是 Auto Minify → HTML；阿里云是“智能压缩”开关）
- 若已开启，本地只需做基础清理：
collapseWhitespace+removeComments，关掉所有 JS/CSS 相关选项 - 若 CDN 不支持（如部分轻量服务器自带的简单反向代理），才启用完整压缩链
- 永远不要依赖 CDN 压缩来替代
srcset和图片格式降级——它们解决的是不同层级的带宽浪费
真正卡住带宽节省效果的，往往不是工具没选对，而是没搞清压缩该在哪一层发生：构建时？运行时？还是 CDN 边缘？三者混用比不用更糟。
