HTML压缩本身不减小传输体积，真正起效的是服务端启用Gzip或Brotli压缩；若响应头无Content-Encoding: br或gzip，DevTools中Size即为实际传输字节数，本地minify无效。
HTML 压缩本身不减小传输体积，真正起效的是服务端启用的 Gzip 或 Brotli 压缩；本地用 html-minifier-terser 把文件从 120KB 压到 85KB，若响应头没 Content-Encoding: br，Network 面板里的 Size 就还是 85KB。
为什么 Network 面板里 Size 没变
浏览器 DevTools 的 Size 列显示的是“实际发出去的字节数”，它只认响应头里的 Content-Encoding。你构建时压缩了 HTML，但服务器没配压缩模块，或漏了 gzip_types text/html，HTML 就是裸体发出去的——压缩后的 85KB 就是传输体积。
常见误操作：
- 在
<meta http-equiv="Content-Encoding" content="gzip">上浪费时间（完全无效） - Nginx 开了
gzip on，但没加text/html到gzip_types - 本地用
html-minifier-terser --minify-js，结果毁掉模板字符串或 source map，而 JS 本该由terser单独处理
哪些压缩选项真影响传输体积
只有当服务端压缩未启用、或压缩率极低时，以下 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，容易出错 - 对 SSR 动态输出硬套
html-minifier：PHP/Node.js 应优先走输出流压缩（如ob_gzhandler），而非预处理字符串
组件化 HTML 的体积陷阱与绕过方式
一个含 5 个 <my-card> 的页面 HTML 从 8KB 涨到 120KB，问题不在标签本身，而在组织方式：
- 每个组件都 copy-paste 了相同的
<style>和初始化<script> - SVG 图标用 base64 写死在 HTML 里，单个占 4KB，复用 5 次就是 20KB
- 第三方库被多个
<script src>重复加载，且没统一 CDN 版本 -
<template id="card-tpl">每个组件都复制一份，而不是运行时克隆一次
真正有效的控制点：
- 所有公共样式必须外链：
<link rel="stylesheet" href="/shared.css">，禁内联<style> - 组件脚本统一由一个
<script type="module">加载，用import拆分逻辑 - 图标全部改用
<svg>外链或系统字体图标，禁用 base64 - 用
importmap或 Webpackexternals确保 lit/react 只加载一次 - 模板 ID 必须唯一，JS 运行时只克隆一次，不要在 HTML 中重复写
<template>
验证是否真生效的三个硬指标
别信“构建后体积变小”，要看真实网络行为：
- 打开 DevTools → Network → 刷一次页面 → 找到
index.html→ 看 Response Headers 里有没有Content-Encoding: br或gzip - 对比同一请求的
Size和Content：如果两者接近（比如 85KB / 84.9KB），说明没压缩；如果Size显著小于Content（比如 85KB / 22KB），说明压缩生效 - 用
curl -H "Accept-Encoding: br" -I https://yoursite.com/index.html直接查响应头，排除浏览器缓存干扰
最常被忽略的一点：HTML 压缩和组件拆分是两件事。你可以在 html-webpack-plugin 里配好 minify，但如果不先解决内联和重复问题，压缩只是给臃肿包打薄薄一层马赛克。
