HTML臃肿与否取决于DOM节点数超1500、嵌套深度超8层、head中未加async/defer的script阻塞解析三类真实指标，而非文件大小。
HTML 本身不是瓶颈，但写法直接决定首屏时间、内存占用和可维护性。轻量化不是删代码，而是让每个字节都承担明确职责。
怎么判断 HTML 是否“臃肿”？看这三处真实指标
别只盯着文件大小。真正影响渲染效率的是 DOM 节点数、嵌套深度和解析阻塞点：
-
document.querySelectorAll('*').length超过 1500 个节点，大概率触发重排开销上升 - 任意元素的
parentNode链路深度 > 8 层，Chrome DevTools 的 “Layers” 面板会标红提示渲染压力 -
<head>里出现未加async或defer的<script>，就会阻塞 HTML 解析，首屏时间直接多出 200ms+
哪些标签最常被滥用？优先清理这四类
它们不报错，但悄悄拖慢解析、增加内存、干扰语义化：
- 纯装饰用的
<div>：比如<div class="wrapper"><div class="inner">...</div></div>—— 改用 CSScontainer或display: contents - 冗余的
<span>包裹文本：如<span class="title">Hello</span>→ 直接给<h1>或<p>加 class - 无意义的
<section>/<article>：没配aria-labelledby或标题，对屏幕阅读器和搜索引擎无效，仅增加 DOM 节点 - 空
<div></div>或注释占位符：构建后残留的<!-- TODO: add banner -->，会被 parser 当作文本节点处理
内联 vs 外链：关键 CSS 到底该放哪？
内联不是万能解药，它只适用于真正影响首屏布局的那部分样式（通常 ≤ 2KB）：
立即学习“前端免费学习笔记（深入）”；
- 内联太多 → HTML 文件体积暴涨，HTTP/2 下反而比外链慢（失去复用+缓存）
- 内联太少 → 关键 CSS 请求延迟，LCP（最大内容绘制）推迟 300ms~1s
- 实操建议：
<style>块只放body、header、首屏card的尺寸/颜色/定位规则；其余全走<link rel="stylesheet" href="main.css"> - 验证方式：在 Lighthouse 的 “Eliminate render-blocking resources” 报告里，确认只有 1 个内联
<style>和 1 个外链 CSS 被标记为关键资源
压缩 HTML 时最容易翻车的三个地方
自动化工具（如 html-minifier）默认配置可能破坏功能或可访问性：
- 删掉
<pre>内的换行和空格 → 代码块显示错乱；需配置collapseWhitespace: false并保留<pre>、<textarea> - 移除
<img>的alt属性（哪怕为空）→ 可访问性失败；必须设removeOptionalTags: false+ 手动校验 - 合并相邻
<script>标签 → 若其中一个是模块脚本（type="module"），合并后会触发语法错误；应按type分组压缩
轻量化的终点不是“最小”，而是“刚好”。DOM 节点数、网络字节、CSSOM 构建耗时，这三个数字必须同步盯住——改一处，测三处。否则优化就只是自我安慰。
