html布局性能瓶颈主要源于dom树过深（≥6层）、语义化缺失及布局引擎误用；深度每增1层，样式计算与重排耗时线性上升，首屏延迟增加20–50ms，需通过chrome devtools检查node.depth并重构嵌套结构。
HTML布局性能瓶颈，八成出在DOM树本身——不是JS慢，也不是CSS写得差，而是你写的第4个
开始，浏览器已经在悄悄掉帧了。
DOM树深度超6层会显著拖慢样式计算
浏览器计算每个元素最终样式时，要向上遍历所有祖先节点匹配选择器。深度每+1，getComputedStyle()耗时就线性增加；实测从深度4升到8，平均耗时翻倍；到12时，低端安卓机单次计算卡顿超80ms。
- 用Chrome DevTools → Elements面板右键任意节点 → “Show DOM properties”，看
node.depth值，≥6就要重构 - 避免
body > div > div > div > .item这类强路径选择器；改用.item .title靠类名直取 -
querySelectorAll('.item')查100个节点时，DOM深度每+1，总耗时+12%左右 - 深层DOM下改一个
.list高度，实际会触发整棵子树重排，不只是它自己
嵌套过深直接拉高首屏延迟20–50ms
浏览器解析HTML是同步构建DOM树的过程，每多一层
，就多一次节点创建、样式计算和布局重排。5层以上嵌套在低端设备上已可导致首屏延迟20–50ms。
- 检查构建后HTML（不是源码），用Elements面板看真实DOM层级——Vue/React组件可能默认包了无意义
div - 能用
<header></header>、<nav></nav>、<section></section>的地方，别用<div class="header"> <li>React中启用<code>（Fragment）；Vue中用v-for的:key直出子项，跳过父容器 - 慎用
display: contents：虽不参与盒模型，但剥离可访问性树节点，且IE全系不支持 -
<main></main>应且仅应出现一次；重复使用会触发Lighthouse的document-multiple-main-elements告警 -
<section></section>必须有标题（<h2></h2>–<h6></h6>），否则语义退化为普通容器，不是<div>的高级替代品 <li> <code><aside></aside>不等于“右边那栏”，而是与当前上下文相关但非核心的补充信息；纯广告位建议用<div role="banner">或直接省略 <li> <code><nav></nav>嵌套<nav></nav>是反模式；页脚链接组建议放在<footer></footer>内用<ul></ul>组织 - Flex适合一维线性排列（导航栏、表单控件）；Grid适合二维布局（卡片流、仪表盘）
- Grid必须显式定义
grid-template-rows，否则隐式轨道（auto高度）可能触发多次重排 - 三列等宽老写法需3层嵌套，新写法：
<main style="display: grid; grid-template-columns: 1fr 1fr 1fr;"><section>A</section><section>B</section><section>C</section></main> - 不要为了“视觉上像表格”而用
<table>做布局——仅当数据具备行列语义时才用 <p>真正卡顿的从来不是某行代码，而是结构里那些看不见的父子关系。DOM深度、语义有效性、布局引擎选型，三者叠加才构成真实瓶颈。重构时盯着<code>node.depth和Elements面板的真实树，比读一百篇教程都管用。
语义化标签不是“换名字”，是改渲染契约
把<div class="main">换成<code><main></main>，改变的不只是class名，而是浏览器默认样式继承规则、屏幕阅读器导航层级、搜索引擎对主次内容的判定依据。
现代布局引擎能砍掉3层嵌套，但用错反而更卡
Flex/Grid不是“用了就快”，而是用对了才快。误用会放大性能代价，比如在flex容器里再套grid微调，通常说明模块职责没切分清。
