html体积超50kb（未压缩）即结构失控，拖慢首屏；gzip后超15kb需重构，因嵌套混乱、语义缺失致压缩率低，实测原始体积已达80–100kb，删空格仅省3–5kb，须精简嵌套、语义化标签、内联关键css≤14kb、移除非首屏内容并沙箱化广告。
HTML 文件体积超过 50KB（未压缩）就不是“还能凑合”，而是结构已失控——它直接拖慢首屏时间，且 gzip 压缩对此类结构性冗余收效甚微。
为什么 gzip 后仍超 15KB 的 HTML 必须重构
gzip 对重复文本压缩率高，但对嵌套混乱、语义缺失、空容器堆叠的 HTML 效果差。实测表明：gzip 后 index.html 超 15KB，往往意味着原始体积已达 80–100KB。此时光靠 html-minifier 删空格和注释，最多省 3–5KB，治标不治本。
- 用浏览器 DevTools → Network 面板查看响应体大小，确认是原始体积问题，而非传输层未启用 Brotli
- 检查构建产物中是否混入开发期残留：
<!-- TODO: 权限校验 -->、console.log模板占位符、未剔除的v-iffallback 空div - 运行
npx html-validate src/**/*.html，重点看element-permitted-content报错——比如p里嵌了div，浏览器会静默修正，但 JS 拿不到预期 DOM 结构
删嵌套比删空格更有效：语义标签与布局方式的选择
一层无意义的 <div class="wrapper"><div class="inner"><div class="content"> 不仅增加<a style="color:#f60; text-decoration:underline;" title="字节" href="https://m.php.cn/zt/16298.html" target="_blank">字节</a>数，更延长 DOM 解析与 layout 计算时间。语义化不是“锦上添花”，而是让浏览器更快识别渲染区块。<ul><li>用 <code><main></main> 替代 <div id="main">，天然无样式开销，且被解析器优先识别为内容主体<li>导航栏从 3 层 <code>div 套娃改为单层 <nav></nav> + display: flex，减少节点数与重排成本
<div v-if>、React 的 <code>> 若未设 key，可能插入空 div；Vite 中 vite-plugin-html 注入变量若写成 %VITE_API_BASE% 而非 __VITE_API_BASE__，会导致字符串残留污染结构内联关键 CSS 的硬性体积红线是 14KB，不是 2KB
业内常说“内联 CSS ≤ 2KB”，那是针对 HTTP/1.1 和小窗口 TCP 初始拥塞的旧经验。现代网络下，真正瓶颈是是否突破 TCP 初始拥塞窗口（约 14KB）。超了就会触发额外 RTT，反而更慢。
- 只提取影响首屏渲染的规则：
body、<h1></h1>、CTA 按钮、LCP 图片容器的字体、颜色、尺寸、max-width - 禁用
@import—— 它在<style></style>块里仍会阻塞并发起新请求 - 用
critters或penthouse工具自动提取，别手写；提取后务必验证：<style></style>块在响应体中未突破 14KB - 若接近或超限，切回
<link rel="preload" as="style" href="critical.css">+media="print"异步加载方案
非首屏内容必须移出初始 HTML
页脚、评论区、相关推荐这些模块，出现在初始 HTML 里，只会拖慢 TTFB 和 DOM 构建，且无法缓存。它们不该是“先下载再隐藏”，而应是“按需注入”。
- 改用
fetch()在 DOMContentLoaded 后加载，或 SSR 场景下通过占位符 + hydration 注入 - 避免把大量 JSON 数据拼进
data-属性：<div data-products='[{"id":1},...]'> —— 改为独立 API 接口异步获取<li>广告脚本必须沙箱化：<code><iframe sandbox="allow-scripts" src="about:blank"></iframe>，滚动接近时再动态赋值src，防止阻塞主文档解析
最难的不是知道该删什么，而是敢删掉那些“看起来没坏”的嵌套、模板占位符和历史遗留内联块——它们不报错，却持续抬高首屏字节水位线。
