HTML压缩本身不提升传输效率，真正起效的是服务端Gzip/Brotli压缩；本地精简仅减少源码体积，若服务端未启用响应压缩，浏览器仍下载完整明文；需确保Content-Type正确、配置匹配MIME类型并验证Content-Encoding响应头。
HTML压缩本身不负责传输效率，真正影响传输效率的是服务端是否启用 Gzip 或 Brotli 压缩。单纯精简 HTML 代码（比如删空格、注释）只能减小原始文件体积，对网络传输耗时影响有限；若服务端未开启响应体压缩，浏览器收到的仍是未压缩的字节流。
为什么本地压缩完还是加载慢
常见错误现象是：用 html-minifier 把 index.html 从 120KB 压到 85KB，但实际加载时间没变——因为浏览器仍需下载全部 85KB 明文，而服务端没启用 Gzip，无法进一步压缩到 ~20KB。
- 本地压缩只解决“源码冗余”，属于构建阶段优化
- 传输压缩由 Web 服务器在响应前动态编码，属于运行时优化
- 两者必须配合：先文本压缩，再传输压缩，效果叠加
- 检查方式：打开 Chrome DevTools → Network → 点开 HTML 请求 → 查看
Content-Encoding响应头是否为gzip或br
nginx 配置 Gzip 最简生效步骤
多数卡顿源于配置不全或 MIME 类型遗漏，导致 HTML 文件被跳过压缩。
- 确认启用了
gzip on;，且未被gzip off;覆盖 - 必须显式包含
text/html：在gzip_types中加上它，例如：gzip_types text/html text/css application/javascript application/json; - 避免设置过低的
gzip_min_length（如 10），默认 20 字节足够；设为 0 反而可能触发异常 - 不要盲目开启
gzip_vary on;，除非你明确需要代理缓存兼容，它会增加响应头体积 - 重启 nginx 后，用
curl -H "Accept-Encoding: gzip" -I http://localhost/index.html检查返回头是否含Content-Encoding: gzip
Express 中 compression 中间件常见失效点
使用 compression() 但 HTML 未被压缩，往往不是中间件没装，而是顺序或条件问题。
立即学习“前端免费学习笔记（深入）”；
- 必须在
app.use(compression())之前注册静态资源中间件（如express.static），否则静态 HTML 不走 compression 流程 - 默认只压缩大于 1KB 的响应；若你的 HTML 压缩后小于该阈值，需手动设
threshold: 0 - 确保未提前调用
res.end()或res.send()，否则中间件链中断，压缩逻辑不会执行 - 如果用了
res.sendFile()，需确认文件路径正确且 MIME 类型能被自动识别为text/html；否则 compression 不触发
Brotli 在 Nginx 中启用但不生效怎么办
Brotli 比 Gzip 压缩率高，但依赖模块编译和客户端支持，容易误判“已启用”实则未命中。
- Nginx 必须从源码编译并启用
--with-http_brotli_module，官方预编译包默认不含 - 配置中需同时写
brotli on;和brotli_types text/html ...;，漏掉后者 HTML 就不压缩 - 客户端必须发送
Accept-Encoding: br，Chrome/Edge 新版本默认发，但旧版 iOS Safari 不支持 - 建议保留 Gzip 降级：
add_header Vary Accept-Encoding;，避免 CDN 缓存混淆 - 验证方式：用
curl -H "Accept-Encoding: br" -I http://yoursite.com/index.html，看响应头是否含Content-Encoding: br
最容易被忽略的是：Gzip/Brotli 是按响应体内容类型（Content-Type）触发的，而不是按文件扩展名。如果你的 HTML 是由后端模板引擎输出，却设置了 Content-Type: text/plain，那再怎么配 gzip_types 都无效。
