html嵌套超4层会显著拖慢首屏渲染，因浏览器流式解析时每层均增加dom创建、样式继承回溯和布局上下文生成开销，导致getcomputedstyle耗时非线性上升、移动端fcp延迟肉眼可感。
HTML嵌套深度超过4层会显著拖慢首屏渲染
浏览器解析HTML是流式自上而下进行的，每多一层嵌套，就要多一次DOM节点创建、样式继承回溯和布局上下文生成。深度超过4层后，getComputedStyle调用耗时开始非线性上升，移动端FCP（首次内容绘制）延迟肉眼可感。
常见冗余结构包括：<div><div><div><input></div></div></div>、SSR模板注入的<div class="page"><div class="main"><div class="container">...</div></div></div>、卡片组件里硬拆的card-inner → card-body → card-content。
- 用
<label class="input-group"></label>包裹<input>替代三层div - 检查Chrome DevTools → Elements面板右键节点 →
Show DOM properties，确认depth值 ≤ 4 - 语义标签如
<main></main>、<section></section>本身不增加开销，但能缩短CSS选择器匹配链
table-layout: fixed; 是表格渲染提速的关键开关
默认table-layout: auto会让浏览器扫描全部单元格内容才能确定列宽，50行×10列的表格可能卡顿100ms以上；设为fixed后，浏览器只读第一行或<col>定义，宽度秒定。
注意：这个CSS声明必须直接加在<table>元素上，不能靠继承；且需配合明确的列宽设定（<code>width或<col width="120">），否则行为退化回auto。
- 避免在
<td>里再套<code><div>——这会触发额外重排，抵消<code>fixed收益 - 纯数据展示才用
<table>；布局任务交给<code>display: grid或display: flex - 用
border-collapse: collapse减少边框绘制开销 -
display: grid用于页面级分区（header/main/aside/footer），配grid-template-areas -
display: flex用于组件内排列（按钮组、导航项、卡片列表），替代float或inline-block + margin - 图标+文字组合改用
display: inline-flex，而非<div> <div><svg></svg></div> <div>文本</div> </div> - 服务端渲染时，对非首屏模块做条件渲染，而不是全量输出+
display: none - 用
hidden属性替代display: none——它让浏览器跳过样式计算（但兼容性略差） - React/Vue中慎用
v-if/ngIf的反模式：先渲染再隐藏，不如初始就不挂载
用CSS Grid/Flex替代div堆叠，不是“更现代”，而是少建DOM节点
Grid和Flex本身不删DOM，但能让原本需要5个div实现的居中+等分+响应式栅格，压缩成1个容器+纯CSS控制。浏览器不用为中间层生成渲染对象，也不用反复计算浮动清除带来的边界影响。
典型误用是“Grid套Flex套Grid”——DOM没扁平，计算反而更重。真正压平结构，是把视觉层级交给gap、place-items、transform等CSS属性承担。
display: none节点虽不可见，但仍在DOM里吃性能
被display: none隐藏的节点不会进渲染树，但会参与DOM构建、样式计算和内存占用。在搜索页、列表页中大量存在时，会导致querySelector变慢、内存压力升高，甚至触发强制同步布局。
这不是“看不见就没事”，而是“看不见还在干活”。尤其当这些节点绑定了事件监听器或通过JS动态切换显示状态时，问题更隐蔽。
__body/__content、为兼容旧IE硬加的clearfix div——它们不报错，但每个都默默拖慢Layout阶段几十毫秒。
