先用devtools右键div设“break on subtree modifications”观察是否被js操作，再搜class查css匹配，无则整删；cms/低代码残留、空注释超三月未动也删；语义化替换如→，避免语义断裂；dom每增100节点拖慢解析20–40ms。
怎么判断哪些 DOM 节点真冗余
别靠猜，先在 Chrome DevTools 的 Elements 面板里右键某个 <div> →「Break on subtree modifications」，然后点按钮、滚动、切换 tab，看它是否被 JS 动态增删或样式依赖。如果全程没变化，再搜它的 class 名：<code>div[class="xxx"]，查 CSS 文件里有没有对应规则——没匹配就删整块，包括起始和结束标签。
特别注意 CMS 或低代码导出的残留：<div data-id="123">、<code><div class="block-wrapper"> 这类，只要没 JS 读取 <code>dataset、也没 CSS 用到那个 class，全删。空注释 <!-- old header --> 超过三个月没动过，也删。
删嵌套前先确认语义替代方案
不是所有 <div> 都能直接砍。比如 <code><div class="main-header"> 看似无意义，但若 CSS 里写了 <code>.main-header { margin-bottom: 2rem; }，删掉会破布局。正确做法是把标签换成 <header></header>，保留 class：<header class="main-header"></header>。
常见替换关系：
<div class="nav-list"> → <code><nav></nav><div class="card-body"> → <code><section></section>（内容独立可分块）或<article></article>（内容自包含）<div class="footer-ctn"> → <code><footer></footer>切记：不要写
<section><div> <h2>，<code><h2></h2>必须直接子级于<section></section>，否则语义断裂，解析器还得回溯确认层级。为什么删 100 个节点能省 20–40ms
DOM 解析是单线程顺序执行，每多一个节点，浏览器就得分配内存、建立引用、校验父/子关系。实测：节点数每增 100 个，平均拖慢 HTML 解析 20–40ms——这比加载一个小图标还慢。尤其当页面有
<table> 布局或大量 <code><div> 套娃时，首屏白屏时间就卡在这儿。<p>典型病灶：</p> <ul> <li>富文本编辑器粘贴后生成的空行：<code><div><br></div> <div><br></div>- SSR 模板里残留的
{{header}}、{% if user %}等未渲染占位符 - 整页列表硬塞进
index.html，光 HTML 就超 15KB，DOM 节点破千
这些不删，加再多 async 或 preload 都救不回来。
innerHTML 赋值后必须立刻 normalize()
用 el.innerHTML = htmlString 插入内容后，富文本操作常留下一堆空文本节点（换行、缩进、纯空白），它们不显示，但会让 el.childNodes.length 虚高，干扰遍历，甚至影响 textContent 提取精度。此时必须补一句：el.normalize()。
注意边界：
- 不能对字符串调用：
"<div></div>".normalize()无效 - 不能对未挂载元素调用：
const d = document.createElement('div'); d.normalize();什么也不做 - 要作用于已插入 DOM 的元素，或
template.content这类离线容器
它只合并相邻 Text 节点、移除空节点，不碰注释、不压缩空格、不改非文本子节点——安全，但得记得加。
