结论先行：生产环境该压缩、开发环境该格式化，这两件事根本不冲突；但 HTML 压缩对首屏的影响极小，通常只有几毫秒，首屏慢基本跟它没关系——真该优化的是阻塞渲染的 CSS/JS 和 LCP 图片。
HTML 压缩到底能省多少体积？会影响首屏吗？
结论：HTML 压缩省的是传输体积，不是渲染路径，对首屏的贡献一般在 10ms 以内。
HTML 压缩主要做四件事：删注释、折叠空白、去可选引号和闭合标签、顺带压缩内联的 CSS/JS。一段正常排版的 HTML，纯压缩能省 5%~15% 的原始体积；但服务端基本都会开 gzip 或 Brotli（br），压缩算法本身已经吃掉了重复空白，所以净收益通常只剩 1%~5%。一个 gzip 后 8KB 的页面，压完可能 7.6KB，在 10Mbps 网络下省不到 1ms。
首屏时间真正由这几件事决定：TTFB、阻塞渲染的 CSS、同步执行的 JS、LCP 图片和字体加载，这些是几百毫秒量级。所以别指望靠压缩 HTML 救首屏，把它当成"顺手做掉"的正确实践就行。
什么情况下压缩 HTML 的收益才值得专门做？
结论：HTML 超过 50KB，或者含大量注释、内联 SVG、重复属性时，收益才从"聊胜于无"变成"值得做"。
典型场景：活动页里注释掉的旧代码、内联 SVG 图标路径、长 data-* 属性、服务端注入的内联 JSON（如 window.__INITIAL_STATE__）。这类页面压掉 20%~40% 很常见，再套 Brotli 还能比 gzip 小 15%~20%。
反过来，普通内容页 HTML 只有 15~30KB，且已开 Brotli，压不压都行，别为它引入额外构建复杂度。
生产环境压缩 HTML 具体怎么配？
结论：构建链自带压缩的不用管，没带的加插件或走 CLI。
html-webpack-plugin 5.x 在 production 模式下 minify 默认开启，不用额外配置。Vite 的 build.minify 只管 JS/CSS，HTML 要另加插件（如 vite-plugin-html-minifier-terser）或走命令行：
npx html-minifier-terser \
--collapse-whitespace --conservative-collapse \
--remove-comments --remove-redundant-attributes \
--minify-css true --minify-js true \
index.html -o index.min.html
关键参数是 --conservative-collapse：折叠空白时保留一个空格，避免行内元素之间的空格被删掉。服务端记得回 Content-Encoding: br（优先）或 gzip，Brotli 静态预压缩用质量 11，动态压缩用 5~6。
压缩 HTML 有哪些坑？
结论：坑集中在空白敏感和内联模板上，上线前必须做视觉回归。
一是行内元素、display:inline-block 之间的空格被删会导致元素贴在一起，靠 conservativeCollapse 兜住。二是模板占位符（Vue 的 {{ }}、Jinja 的 {% %}）会被当普通文本处理，要用 ignoreCustomFragments 保护。三是 removeAttributeQuotes 遇到含空格或特殊字符的属性值会出事，值里有空格就别开。四是 removeOptionalTags 会让基于原始字符串的测试断言和正则直接失败，虽然浏览器解析后的 DOM 没问题。
开发环境要不要格式化？
结论：要。可读性是开发产物，压缩是构建产物，两者不该互相妥协。
仓库里存格式化后的 HTML，用 Prettier 加 .editorconfig 统一风格；压缩只发生在构建阶段，产物不进仓库——否则 git diff 完全没法 review。线上排查问题时用 source map，或者本地对压缩结果跑一次反向美化再对着看。
总结一句：HTML 压缩该做，但它是"顺手正确"，不是"首屏解药"；把精力放在关键 CSS 内联、JS 延迟、图片优化上，收益是它的几十倍。
