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"> 不仅增加字节数，更延长 DOM 解析与 layout 计算时间。语义化不是“锦上添花”，而是让浏览器更快识别渲染区块。
- 用
<main>替代<div id="main">，天然无样式开销，且被解析器优先识别为内容主体 - 导航栏从 3 层
div套娃改为单层<nav>+display: flex，减少节点数与重排成本 - 警惕框架生成冗余 wrapper：Vue 的
<div v-if>、React 的<></>若未设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>、CTA 按钮、LCP 图片容器的字体、颜色、尺寸、max-width - 禁用
@import—— 它在<style>块里仍会阻塞并发起新请求 - 用
critters或penthouse工具自动提取，别手写；提取后务必验证：<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 接口异步获取 - 广告脚本必须沙箱化：
<iframe sandbox="allow-scripts" src="about:blank">，滚动接近时再动态赋值src，防止阻塞主文档解析
最难的不是知道该删什么，而是敢删掉那些“看起来没坏”的嵌套、模板占位符和历史遗留内联块——它们不报错，却持续抬高首屏字节水位线。
