不是白干，但Size没变说明服务端压缩未启用或配置不全：DevTools中Size列只反映实际传输字节数，需响应头含Content-Encoding: gzip或br才生效；本地HTML压缩若未配Nginx gzip_types text/html等，压缩结果不会被传输压缩。
HTML精简后Network面板Size没变，是不是白干了？
不是白干，但你看到的“没变”恰恰说明关键环节没配对。DevTools里Size列显示的是**实际传输字节数**，它只认Content-Encoding: gzip或Content-Encoding: br响应头。本地用html-minifier-terser把文件从120KB压到85KB，若Nginx没启用Brotli或Gzip，那这85KB就是原样发出去的——Size当然还是85KB。
常见卡点：
-
gzip on开了，但漏配gzip_types text/html，HTML被跳过压缩 - 误信
<meta http-equiv="Content-Encoding" content="gzip">能生效（完全无效，浏览器忽略） - CDN（如Cloudflare）开了Auto Minify，但没勾选HTML，或缓存未刷新
哪些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，还容易毁模板字符串或source map。
立即学习“前端免费学习笔记（深入）”；
精简HTML结构时最容易踩的坑
语义化标签（<header>、<main>）不是精简目标，嵌套过深的<div>才是。重点砍三类东西，但每类都有边界：
- 删
<pre>和<textarea>内换行：它们依赖原始空白，压缩后内容错位 - 盲目扁平化DOM：比如把
<div class="card"><div><p>文字</p></div></div>直接改成<p>文字</p>，但CSS里写了.card > div > p就挂了 - 内联大段
<style>或<script>：gzip后超过~14KB会跨TCP包，反而增加TTFB - 删掉
<meta charset="UTF-8">或<meta name="viewport">：解析会fallback到默认编码，乱码风险拉满
构建阶段 vs 服务端压缩，该选哪条路？
构建阶段压缩（Webpack/Vite插件、html-webpack-plugin、vite-plugin-html）适合静态生成场景，输出即压缩；服务端动态压缩（Nginx/Apache + Gzip/Brotli）适合动态HTML，但CPU开销真实存在。
实操建议：
- 静态站（Hugo/Astro）：直接开
minify配置，Hugo用[minify]，Astro设output: "static" - 动态PHP/Node.js：优先配好Brotli（比Gzip高15–20%压缩率），再补
mini_html()这类轻量预处理，别碰JS/CSS内联 - CDN层（Cloudflare）：打开Auto Minify并勾选HTML，但注意它不处理
<script>内模板字符串，别依赖它做JS压缩
真正卡首屏的从来不是HTML体积本身，而是它触发的阻塞链：一个没配async的<script src="x.js">，比多10KB空格更致命。
