必须同时进行HTML压缩和Gzip/Brotli传输压缩才有效：HTML压缩在构建时删注释、空格等减少字符数，Gzip/Brotli在传输时编码响应体；单独使用任一方式均无法达到最佳带宽节省效果。
HTML压缩和传输效率不是一回事，但必须一起用才有效。单独做HTML压缩，文件体积变小了，但浏览器收到的还是未压缩的原始字节；不压缩HTML只开Gzip，服务器照样要传一堆空格和注释，浪费带宽。
HTML压缩是文本级瘦身
它直接改HTML源码：删注释、去换行、合并空格、简化属性（比如class="header active" → class=header active）。本质是减少字符数，让index.html从 120KB 变成 85KB。
- 适用场景：构建阶段（CI/CD）、静态站点生成、上线前打包
- 常见工具：
html-minifier、purgecss（配合）、Webpack 的HtmlWebpackPlugin插件 - 注意点：
minifyJS:true和minifyCSS:true会尝试压缩内联脚本和样式，但对外部引用无效；若页面含动态模板语法（如{{ variable }}），需关闭removeComments或自定义忽略规则，否则可能误删 - 风险：过度压缩可能破坏某些依赖空白或换行的CSS布局（比如
inline-block元素间的空格），上线前务必在真实环境验证渲染
Gzip/Brotli是传输层编码
它不碰HTML内容，而是在HTTP响应发出前，用算法把整个响应体（包括HTML、CSS、JS）编码成更短的二进制流。浏览器收到后自动解码，对开发者透明。
- 生效条件：响应头必须包含
Content-Encoding: gzip或br，且客户端支持（现代浏览器全支持） - 配置位置：
nginx用gzip on;，Apache用mod_deflate，Node.js（Express）用compression中间件 - 关键参数：
gzip_min_length 1024（避免压缩太小的响应）、gzip_types text/html text/css application/javascript（明确指定HTML类型） - 性能影响：CPU占用轻微，但节省的带宽远超开销；Brotli比Gzip压缩率高15–20%，但需要HTTPS且服务端支持（Nginx 1.11.6+）
为什么必须两者都做？
只做HTML压缩，120KB → 85KB，省35KB；再叠加Gzip，85KB → 约22KB（实测典型HTML压缩率75%+）；如果跳过HTML压缩直接Gzip，120KB → 约30KB——多传了8KB，对首屏加载就是几十毫秒差距。
立即学习“前端免费学习笔记（深入）”；
- 线上验证方法：Chrome DevTools → Network → 找HTML请求 → 看
Size列（实际传输大小）和Content列（解压后大小），二者差值越大，说明传输压缩越有效 - 容易被忽略的点：
Content-Encoding头只对HTTP响应体起作用，HTML里写的<meta http-equiv="Content-Encoding" content="gzip">完全无效，纯属误导 - 动态HTML（PHP/JSP）也能用Gzip，但HTML压缩通常得在输出前用ob_start() + 自定义回调处理，不如静态文件方便；此时更应优先确保Gzip开启
真正卡顿的从来不是“要不要做”，而是“哪一步漏了”。HTML压缩漏了，白压JS/CSS；Gzip没开，压缩了也白搭。检查Content-Encoding 响应头和Size/Content 对比，两步缺一不可。
