html嵌套过深是首屏卡顿主因，5层以上嵌套可致延迟20–50ms；应优先用语义化标签、fragment、flex/grid替代冗余div，慎用lazy加载首屏图片，并删除无意义dom节点。
HTML布局本身不执行逻辑，但结构写法直接决定浏览器解析速度、DOM树构建开销和首屏渲染延迟——多数“卡顿”问题，根源不在JS或CSS，而在你写的第3个<div>里。
<h3>为什么嵌套超过4层就该警惕</h3>
<p>浏览器解析HTML是自上而下同步构建DOM树的，每多一层<code><div>，就多一次节点创建、样式计算和布局重排。实测显示：5层以上嵌套在低端安卓机上可导致首屏延迟20–50ms。常见诱因包括BEM类名强绑定、组件框架默认包裹（如Vue单文件组件未启用<code><template></template>根节点扁平化）、为兼容老CSS硬加wrapper。
- 检查构建后HTML，用浏览器开发者工具的Elements面板看真实DOM层级，不是源码层级
- 能用
<header></header>、<nav></nav>、<section></section>的地方，别用<div class="header"> <li>React/Vue中开启<code>Fragment（>）或v-for的:key直出子元素，跳过无意义父容器 - 慎用
display: contents：它虽让父元素不参与盒模型，但会剥离可访问性树节点，且IE全系不支持 -
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>做布局——仅当数据具备行列语义时才用 <h3>loading="lazy"不是万能开关，首屏图片必须绕开它</h3> <p><code>loading="lazy"确实能减少三屏外图片的请求数，但滥用会直接拉垮LCP（最大内容绘制）。浏览器对首屏图片的加载优先级有严格策略，加了lazy等于主动降级。- 首屏可见区域内的
<img>必须去掉loading属性，或显式设为loading="eager" - 所有带
loading="lazy"的图片，必须同时声明width和height属性，否则会引发CLS（累积布局偏移） -
<iframe></iframe>也支持loading="lazy"，但仅当其内容非首屏关键路径时才启用 - 服务端渲染场景下，动态拼接HTML字符串时容易漏掉这些属性，建议用模板引擎预置校验规则
defer/async不是脚本的终点，而是HTML解析阻塞的起点
浏览器遇到
<script></script>标签默认暂停HTML解析，直到下载并执行完毕。这个停顿常让首屏文字“等JS等半天”。defer和async只是缓解，不是根治。-
async适用于完全独立的脚本（如统计埋点），执行时机不可控，可能打断DOM构建 -
defer保证按顺序执行且不阻塞解析，但仍在DOMContentLoaded前完成——若脚本含大量DOM操作，仍可能拖慢首屏渲染 - 真正零阻塞的做法：把非关键JS放在
- 首屏可见区域内的
Flex/Grid替代浮动/inline-block时的关键取舍
传统浮动布局依赖“父清子浮”，必然引入额外<div class="row">；而现代布局引擎允许父级直接定义关系，子项无需包裹。但误用会放大性能代价。
<ul>
<li>
<code>flex适合一维线性排列（导航栏、表单控件），避免在flex容器内再套grid微调——这通常说明模块职责没切分清
