Chrome DevTools中通过Elements面板右键节点→“Show DOM properties”查看node.depth值，超6层即需重构，因低端安卓机实测FCP延迟显著上升；可用控制台脚本批量定位深度≥6的节点。
Chrome DevTools 里怎么看嵌套深度是否超标
别靠缩进数层数，直接看真实 DOM 树。打开 Chrome DevTools → Elements 面板 → 右键任意节点 → Show DOM properties → 查 node.depth 值。超过 6 就该动手重构——这不是建议，是低端安卓机实测的 FCP 延迟拐点。
更高效的方式是在控制台运行：
Array.from(document.querySelectorAll('*')).filter(el => el.parentElement && el.parentElement.depth >= 6)它能一次性列出所有父级深度 ≥6 的节点，重点盯 div 堆叠、SSR 框架外层 wrapper、table 单元格里的 div。
node.depth 统计的是从 document 开始的父级链长度（不含 document 自身），所以 <main><section><article><p></p></article></section></main> 这种结构，p 的 depth 是 5，刚好卡在临界线内。
用语义化标签替代 div 嵌套时的硬性边界
不是“能换就换”，而是必须守住 W3C 语义边界和 DOM 合法性。比如：
立即学习“前端免费学习笔记（深入）”；
-
<main></main>必须唯一，且只能是的直接子元素；写成<section><main>…</main></section>会让部分 Chromium 版本降级为普通div，Lighthouse 直接报错 -
<nav></nav>不是所有导航链接的容器，仅用于主导航链路；页脚友情链接、文章末“相关阅读”该用<div role="navigation"> 或裸 <code><ul></ul> -
<p></p>内禁止嵌套<div>，浏览器会自动拆成 <code><p></p> <div></div> <p></p>，多出空节点、切碎文本流、干扰 FCP <table> 单元格里再套 <code><div> 是重排高危区，表格布局算法本就重，嵌套后极易触发同步 layout <h3>Flex/Grid 替代浮动/inline-block 的实际陷阱</h3> <p>用了 Flex 或 Grid 不等于性能自动提升，关键在职责是否清晰：</p> <ul> <li>三列等宽布局，别写 <code><div class="row"> <div class="col">A</div> <div class="col">B</div> <div class="col">C</div> </div>，直接用<main style="display: grid; grid-template-columns: 1fr 1fr 1fr;">…</main>- Grid 容器里再套 Flex 微调，通常说明模块切分不清；要么把子项样式抽到 Grid Item 上，要么把整块逻辑提成独立组件
- 未显式定义
grid-template-rows时，每行高度为auto，可能触发多次重排；关键区域建议写死，比如grid-template-rows: 100px auto 80px -
display: contents能“隐形”父容器，但 IE 全系不支持，且会剥离可访问性树节点，屏幕阅读器无法读取
哪些深层嵌套根本没法靠 CSS 优化绕过去
有些结构问题，CSS 再怎么写都救不了，必须动 HTML：
-
<div class="card"><div class="card__body"><div class="card__content">…</div></div></div>这类纯装饰性包裹，用<slot></slot>+contain: layout替代，透传内容，不增节点 - SSR 框架输出的
data-reactroot外层、组件库默认开启的 wrapper 层，得在构建阶段用插件剥离或配置关闭 - 第三方 widget（如评论框、广告位）带来的深层嵌套，封装进
shadowRoot可隔离样式与事件，但不能降低整体渲染树深度——得在 shadow 内部也执行深度控制 -
<ul><li><div><p>…</p></div></li></ul>这种写法，浏览器会把div提到li外，生成冗余节点；应直接用<li><p>…</p></li>，p在li内完全合法
真正难的不是识别哪几层该删，而是判断哪一层承载了真实语义、哪一层只是被 CSS 惯性拖着走。一旦开始用 node.depth 当尺子量，很多“看起来合理”的嵌套，其实连存在理由都没有。
