dom嵌套超6层会显著延迟fcp，因解析器需逐层创建节点、计算样式并回溯布局，移动端可推迟200ms以上；深度≥7时应重构为语义化标签以缩短css匹配路径。
DOM嵌套超过6层为什么会让FCP明显延迟
浏览器解析HTML是自上而下流式构建DOM树，每多一层嵌套，就多一次节点创建、样式计算和布局回溯。尤其在移动端，<div>
<div><div><div><p></p></div></div></div>这类结构会让首次内容绘制（FCP）推迟200ms以上——不是因为JS慢，而是解析器卡在层层嵌套的节点展开上。
<ul>
<li>用<code>devtools → Elements → 右键节点 → “Show DOM properties”查nodeType和depth，深度≥7就要重构
<section></section>、<article></article>本身不增加渲染开销，还能缩短CSS选择器匹配路径（比如把.wrapper .inner .content p简化为main p）<div>最危险：<code><td><div><span>text</span></div></td>会触发额外重排，直接用td设样式更稳
script放在head里到底卡在哪一步
一个没加defer的<script src="app.js"></script>放在里，浏览器会立刻暂停HTML解析，等JS下载、解析、执行完才继续。此时连都没生成，用户看到的就是白屏——不是JS执行慢，是它根本没让DOM树长出来。
- 统计/埋点类脚本一律加
defer：保证顺序执行，且不阻塞解析 - 纯交互逻辑（如
document.addEventListener('click', ...)）可用async，但必须包在DOMContentLoaded里，否则document.querySelector可能返回null - 真要操作DOM的脚本（比如初始化轮播图），放
底部比放里加defer快100ms左右，实测首屏时间更可控
内联CSS超50行就是性能红灯
大段<style></style>直接塞进HTML，不仅拉高TTFB（首字节时间），还会让HTML解析器卡在文本扫描阶段——它得逐字符读完所有CSS规则，才能继续构建DOM。单个<style></style>块超过50行，基本等于给首屏渲染加了减速带。
- 用
curl -I https://yoursite.com看Content-Length，HTML体＞15KB时，先检查内联资源占比 - 关键CSS（如字体、标题、首屏按钮样式）提取成critical CSS内联，其余全外链；工具推荐
critters或penthouse - 别信“内联一切CSS更快”，实测中HTML从12KB涨到52KB后，3G网络下首屏延迟反而增加400ms
preload用错比不用还拖慢加载
preload是提示浏览器“这个资源马上要用”，但它不改变执行时机。如果预加载了一个实际要等交互才用的字体，或者preload了还没在HTML里出现的main.css，浏览器会提前占带宽，挤掉真正该优先加载的资源。
- 只对首屏必现资源用
preload：比如<link rel="preload" href="https://www.php.cn/link/3f9f2cdee51032cc59172d9554ea5b6a" as="font" crossorigin> -
as="style"必须配真实href，且对应文件得在后续<link rel="stylesheet">中再次声明，否则样式不会生效 - 避免对
prefetch滥用：它适合预取下一页资源，但对首屏无意义，还可能干扰HTTP/2优先级调度
defer的script、一段没拆分的内联CSS、或者三层嵌套的<div class="row"><div class="col"><div class="item"></div></div></div>——这些地方改起来不难，但容易被当成“无关紧要的结构细节”跳过。
