html嵌套过深会拖慢首屏渲染，dom节点深度超6层易截断，5层即需警惕；语义化标签因浏览器优化而提速；display:contents慎用，存在兼容性与可访问性问题；脚本应按用途合理放置并加defer/async属性。
浏览器解析 HTML 是单线程、自上而下的流式过程，结构写得不干净，首屏就卡在第 3 层 <div> 里出不来——这不是 JS 慢，是 HTML 本身拖住了整个渲染链。
<h3>怎么判断嵌套是否过深</h3>
<p>不是看写了几个 <code><div>，而是看实际 DOM 节点深度。Chrome DevTools → Elements 面板右键任意节点 → <strong>Show DOM properties</strong>，查 <code>nodeDepth 值：
- 超过 6 层：移动端或弱网下极易截断，
<main></main>或<article></article>可能根本没进 DOM 树 - 5 层就该警惕：实测低端机首屏延迟增加 20–50ms
- 表格内嵌套特别危险：
<td> 里再套 <code><div> 会触发额外重排，比同级 flex 容器多一次布局计算 <h3>语义化标签真能提速吗</h3> <p>能，但不是因为“SEO 友好”这种虚的——现代浏览器对 <code><header></header>、<nav></nav>、<section></section>的解析路径做了专门优化，它们创建的节点更轻、样式计算更快、CSS 选择器匹配也更高效。- 用
<section></section>替代<div class="section">，DOM 节点数不变，但浏览器跳过部分样式继承检查 <li> <code><main></main>必须紧贴开头，不能被广告、埋点脚本、导航栏挡在后面 - 避免混用：比如
<article></article>里又套一层<div class="article-content">，语义标签本身已具备内容容器语义，再包一层纯属冗余 <h3>为什么 <code>display: contents要慎用它确实能“消灭”父容器的盒模型，减少嵌套层级感，但副作用明显：
- IE 完全不支持，哪怕加了 polyfill 也无法还原可访问性树（
role和aria-属性失效） - DevTools 里节点还在，但渲染树中消失，调试时容易误判结构
- 当父元素有 transition 或 transform 时，子元素可能意外失活或动画错位
- 真正该做的是删掉那层父
<div>，而不是用 CSS 把它“藏起来” <h3> <code><script></script>放哪儿最不影响解析不是“放
前就行”，而是看脚本用途：- 操作 DOM 的逻辑（如初始化轮播图）：必须加
defer，且放在里——SSR 场景下，defer比async更稳，确保 DOM 就绪后再执行 - 第三方统计、埋点：用
async，但得确认它不依赖window.$或其他全局变量 - 绝对不要把未加属性的
<script src="vendor.js"></script>放在顶部，这是白屏第一大元凶 - 内联小脚本（如数据打点）可以放
开头，但体积别超 1KB，否则阻塞解析
最难的从来不是写对某一行代码，而是决定要不要保留那个“看起来很整齐”的
<div class="wrapper"> ——它不报错，但会让首屏慢 30ms、让屏幕阅读器多绕两圈、让爬虫漏掉关键区块。</div> - 操作 DOM 的逻辑（如初始化轮播图）：必须加
- IE 完全不支持，哪怕加了 polyfill 也无法还原可访问性树（
- 用
