HTML压缩不减小Network面板的Size，因其仅减少源码体积，而Size显示的是服务器启用gzip/brotli后的实际传输字节数；构建压缩与服务器压缩必须配合，缺一不可。
HTML压缩本身不减小Network面板里的Size
很多人运行html-minifier-terser后发现浏览器Network面板里HTML的Size没变，以为压缩失败——其实不是。HTML压缩只改源码体积，而Network面板显示的是「实际传输字节数」，它取决于服务器是否启用gzip或brotli。如果Nginx没开gzip on，哪怕你把HTML从120KB压到28KB，浏览器收到的仍是未压缩的120KB，响应头里也不会有Content-Encoding: gzip。
构建时压缩和服务器压缩必须配合使用
二者职责不同，缺一不可：
-
html-minifier-terser在构建阶段删空格、去注释、精简属性（比如把disabled="disabled"变成disabled），减少原始HTML体积，降低后续gzip压缩难度和CPU开销 -
gzip或brotli在响应时对已生成的HTML做流式压缩，真正减少网络传输量；实测显示，先minify再gzip，比单纯gzip平均多省30%~40%带宽 - Webpack项目中，
html-webpack-plugin的minify选项只作用于模板编译输出，不影响最终HTTP响应体——它不替代服务器压缩
容易被忽略的配置陷阱
几个高频翻车点：
-
removeScriptTypeAttributes: true会删掉<script type="module"></script>里的type，导致现代模块脚本无法执行；仅对type="text/javascript"安全 -
minifyJS: true对内联<script></script>启用Terser压缩，但若含ES2022+语法（如Promise.withResolvers()）或模板字符串中的${}，可能破坏逻辑——建议设为{ compress: false }或干脆关掉 - Nginx配置里漏写
gzip_types text/html;，默认只压text/plain，HTML会被跳过；Apache同理，mod_gzip_item_include mime ^text/.*必须显式包含text/html - 本地测试时用
file://打开HTML，永远看不到gzip效果——必须走HTTP服务（如npx serve或Nginx）
验证是否真生效的唯一方式
别看文件大小，直接查浏览器Network面板：
- 找到HTML请求，点开Headers标签页
- 确认Response Headers里有
Content-Encoding: gzip或br - 对比Size列的“transferred”值（实际传输量）和“resource”值（解压后体积），差值越大说明压缩越有效
- 顺手检查
Content-Type: text/html; charset=utf-8是否正确，charset缺失会导致gzip后中文乱码
压缩不是加个插件就完事的动作，它是构建链路和部署链路共同参与的协作过程。漏掉任一环，前面所有minify操作都只是在本地自我感动。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
