嵌套深度超6层会明显拖慢首屏渲染，chrome devtools中右键dom节点查看depth值可验证；实测低端安卓机fcp延迟易超200ms，ssr/ssg场景尤甚；应以等语义标签替代冗余div嵌套，压低节点总数。
嵌套深度超6层会明显拖慢首屏渲染
Chrome DevTools 里右键任意 DOM 节点 → Show DOM properties，就能看到 depth 值。实测在低端安卓机上，平均嵌套深度超过 6 层时，FCP 延迟很容易突破 200ms；SSR/SSG 输出的 HTML 尤其容易踩这个坑。
用 <section></section>、<main></main>、<article></article> 替代三层以上的 <div class="wrapper"><div class="content"><div class="inner">，语义标签不增加解析成本，还能压低 DOM 节点总数——移动端稳定底线是 <code> 个节点。
<ul><li>避免在 <code><table> 单元格里嵌套 <code><div> 再套 <code><div>：表格样式计算本就重，嵌套后极易触发同步 Layout
<li>Next.js/Nuxt 生成的 HTML 若含 <code>data-reactroot 或 _next 标记，需检查其父容器是否无意中加深了嵌套层级
<div class=""> —— 它们照样进 DOM 树，占解析时间
<h3>script 放错位置会让整个关键渲染路径卡死</h3>
<p>不是 JS 体积大才阻塞，而是 <code><script></script> 默认同步加载，浏览器必须暂停 HTML 解析、下载并执行完才能继续。哪怕只有 1KB 的 vendor.js，只要它写在 - 非关键脚本（统计、错误监控、第三方 SDK）必须加
defer：保证执行顺序，又不阻塞 HTML 流式解析 - 纯交互逻辑（如按钮绑定）可用
async，但注意它不保序，且可能在DOMContentLoaded前运行；若操作 DOM，大概率报Cannot read property 'addEventListener' of null - 真要操作首屏 DOM 的脚本（比如初始化轮播、表单校验），放
里，别信“DOMContentLoaded比load快”的模糊说法——实测晚 100ms 加载，LCP 就晚 100ms
内联资源过大反而延长 TTFB 和 DOM 构建起点
为“首屏直出”把 CSS 或初始化数据塞进 <style></style> 或 <script type="application/json"></script>，结果 HTML 体积飙到 50KB+，这不仅拉高 TTFB（服务器响应头发出时间），还会让浏览器解析器卡在文本扫描阶段，DOM 构建起点被迫延后。
查响应头 Content-Length，HTML 体超 15KB 时重点检查内联资源。尤其注意：<meta charset="utf-8"> 必须出现在前 1024 字节内，否则浏览器可能先按 latin1 解析一部分再重载，导致闪动或乱码——这不是玄学，是规范强制要求。
DOM 节点数和结构扁平化比压缩 HTML 字符更影响解析速度
一个 2000 行的 HTML 文件，即使 gzip 后只有 80KB，也可能导致解析耗时翻倍，尤其在低端安卓设备上。浏览器解析 HTML 是线性扫描 + 构建树的过程，节点数和嵌套深度直接影响 V8 解析器工作量。
- 慎用
innerHTML = '<div></div>'拼接长模板：V8 解析 HTML 字符串比创建元素慢 3–5 倍 - 图片不用
<img src="placeholder.jpg">占位再 JS 替换，改用loading="lazy"+ 合理的srcset - 嵌套超过 6 层的
<div> 容易触发浏览器重排压力，优先考虑用 <code>flex或grid扁平化结构真正卡性能的，往往不是你写的
document.querySelector，而是你写的第一个<script></script>标签，以及它前面那堆没剪干净的<div>。</div>
