删掉无用嵌套比任何优化更直接有效，因每增100个dom节点解析拖慢20–40ms，五层嵌套常致百毫秒卡顿，需删除js忽略、css未匹配、无障碍不依赖的“死容器”，并用语义化标签替代无意义div包裹，清除模板残留与空注释，验证dom深度是否真实下降。
删掉没用的嵌套比加任何优化都更直接有效
DOM节点每增加100个，HTML解析平均拖慢20–40ms；五层
嵌套是百毫秒级卡顿最常见的根源。这不是理论推演，而是Chrome DevTools中Performance面板可直接观测到的Layout阶段耗时跳变。
真正要动手删的，不是“看起来多余”的标签，而是被JS忽略、CSS未匹配、无障碍不依赖的死容器：
- 右键可疑→ “Break on subtree modifications”，交互触发后没断点？说明它从不参与动态更新，可删
- 在Elements面板Ctrl+F搜
div[class]，逐个点开检查：对应CSS文件里有没有.wrapper或.inner规则？没有就整行删- CMS/低代码导出页重点查
<div data-id="xxx">和<code><div id="block-123">——只要没JS通过<code>document.getElementById("block-123")引用，全删用语义化标签替代无意义
包裹浏览器对
<header></header>、<nav></nav>、<main></main>等语义标签有轻量预判解析路径，而一堆同级<div>会让解析器反复回溯确认层级关系，增加解析时间。<p>替换不是改名游戏，而是改解析逻辑：</p> <ul><li><code><div class="main-header"> → 改为<code><header class="main-header"></header>，类名保留用于样式，标签本身承担结构语义<div class="nav-list"> → 改为<code><nav class="nav-list"></nav>，避免写成<nav><div> <ul>这种非法嵌套<li> <code><section></section>必须按内容逻辑切分（如“用户评价”“功能列表”），不是为了加margin-top硬拆清除模板残留与空注释块
注释本身不渲染，但浏览器仍需逐字读取、跳过。千行注释≈多花3–8ms解析时间；更危险的是模板语法残留（如
{{header}}），它们虽不报错，却干扰DOM构建顺序，尤其在SSR场景下易引发隐性阻塞。实操建议：
- 删净所有
<!--#include file="xxx"-->、<!-- template: header -->这类服务端包含标记 - 移除
<!-- START NAV -->/<!-- END NAV -->这类区块注释——除非你真用构建工具做条件注入，否则纯属噪音 - 把大列表HTML拆成独立文件（如
/data/list-1.html），用fetch()+insertAdjacentHTML动态插入，首次只留占位<ul id="list-root"></ul>
验证DOM深度是否真降下来了
别只看源码缩进——要测真实渲染树深度。很多“扁平化”操作后，JS引用没断、框架注入的wrapper还在，depth值根本没变。
Chrome DevTools里两步验证：
- Elements面板右键任意节点 → “Show DOM properties”，查看
depth值；超过6就要重构 - Performance面板录制一次页面加载，重点观察Layout阶段耗时是否随深度降低明显下降
- 运行
getComputedStyle(el)测速：在深度>6的节点上调用，耗时可能翻倍；压平后应显著回落
最常被忽略的是：某些框架注入的空wrapper（如SSR生成的
data-reactroot父容器）虽不显式渲染，但仍计入depth，必须识别并剔除。 - 在Elements面板Ctrl+F搜
