首屏重排瓶颈源于html解析阶段的结构问题。冗余嵌套、非法嵌套和深层wrapper导致dom树构建错误，触发整棵子树重排；6层嵌套比扁平结构重排耗时高2.3倍；display: contents可消除无意义wrapper，但需注意兼容性与可访问性；骨架屏必须服务端直出且同构，避免js动态插入引发hydration闪动。
首屏重排瓶颈不是等页面动起来才出现的，它在HTML解析阶段就已埋下——结构冗余、非法嵌套、深层wrapper，会让浏览器在构建DOM树时就生成错误祖先链，后续哪怕只改一个display值，也会触发整棵子树重排。
HTML嵌套过深直接拉高重排成本
浏览器计算offsetTop或响应resize事件时，必须沿祖先链逐层向上检查布局上下文。每多一层无语义<div>，就多一次继承链推导和样式重新匹配。
<ul>
<li>实测：6层嵌套的列表项比扁平结构（<code><li>直挂<ul></ul>）在滚动中重排耗时高2.3倍
<div><section><div><article><p>这类“安全但无用”的嵌套，在DevTools Layers面板里会显出多个碎片化合成层
</p>
<li>React/Vue SSR默认输出的<code>data-v-xxx wrapper若未剥离，会强制浏览器为每个wrapper创建独立渲染子树非法嵌套会在解析阶段自动修正并放大重排范围
浏览器不会报错，但会默默拆解、补全、重排DOM——这个过程本身就会生成额外节点、打断样式继承、延长祖先链。
-
<p></p> <div>hello</div>→ 被修正为<p></p> <div>hello</div> <p></p>，空<p></p>节点可能让参与重排 -
<ol><p>Item</p></ol>→ 列表序号重置、焦点顺序错乱、CSScounter-reset失效 <table><tr><td>未包<code><tbody> → 浏览器插入匿名表格对象，破坏<code>table-layout: fixed列宽锁定用
display: contents消除无意义wrapper这是目前最轻量的结构降级手段，能让指定元素从渲染树中“消失”，其子元素直接受父容器的flex/grid控制，不新增布局上下文。
- 适用场景：
<div class="card"><div class="card__body">...</div></div>中.card__body可设display: contents - 注意兼容性：
display: contents在IE中完全不支持，Safari需15.4+，使用前需检查Caniuse数据 - 不能用于替换表单控件容器（如
<label></label>内含<input>），否则会破坏可访问性树
骨架HTML必须同构且禁止JS动态插入
所谓“骨架屏”如果靠JS在
DOMContentLoaded后插入一堆<div class="skeleton">，等于把白屏期从TTFB后挪到JS执行后——FCP没提前，重排反而更多。 <ul> <li>正确写法：服务端直出<code><div data-skeleton="true" class="item"></div>，配合内联[data-skeleton="true"] { background: #f0f0f0; }- 适用场景：
- 图片占位必须用
<img src="data:image/svg+xml,%3Csvg">，避免HTTP请求打断流式解析 - 禁止在骨架节点里写
v-if或{% if %}，否则SSR与CSR DOM结构不一致，hydration时直接替换节点，造成视觉闪动
真正卡住首屏的，从来不是JS执行慢，而是HTML结构在解析那一刻就让浏览器多走了三步路。删掉一层<div>、修正一个<code><ol></ol>里的<p></p>、把display: flex容器的子项wrapper换成display: contents——这些改动不改一行业务逻辑，却能让重排扩散范围缩小一个数量级。
