嵌套深度超6层会明显拖慢首屏渲染，Chrome DevTools中右键DOM节点查看depth值可验证；实测低端安卓机FCP延迟易超200ms，SSR/SSG场景尤甚；应以<section><main><article>等语义标签替代冗余div嵌套，压低节点总数。
嵌套深度超6层会明显拖慢首屏渲染
Chrome DevTools 里右键任意 DOM 节点 → Show DOM properties，就能看到 depth 值。实测在低端安卓机上，平均嵌套深度超过 6 层时，FCP 延迟很容易突破 200ms；SSR/SSG 输出的 HTML 尤其容易踩这个坑。
用 <section>、<main>、<article> 替代三层以上的 <div class="wrapper"><div class="content"><div class="inner">，语义标签不增加解析成本，还能压低 DOM 节点总数——移动端稳定底线是 个节点。
- 避免在
<table>单元格里嵌套<div>再套<div>：表格样式计算本就重，嵌套后极易触发同步 Layout - Next.js/Nuxt 生成的 HTML 若含
data-reactroot或_next标记，需检查其父容器是否无意中加深了嵌套层级 - 服务端渲染时，别让模板引擎自动补一堆空
<div class="">—— 它们照样进 DOM 树，占解析时间
script 放错位置会让整个关键渲染路径卡死
不是 JS 体积大才阻塞，而是 <script> 默认同步加载，浏览器必须暂停 HTML 解析、下载并执行完才能继续。哪怕只有 1KB 的 vendor.js，只要它写在 <head> 里，首屏白屏就可能发生。
- 非关键脚本（统计、错误监控、第三方 SDK）必须加
defer：保证执行顺序，又不阻塞 HTML 流式解析 - 纯交互逻辑（如按钮绑定）可用
async，但注意它不保序，且可能在DOMContentLoaded前运行；若操作 DOM，大概率报Cannot read property 'addEventListener' of null - 真要操作首屏 DOM 的脚本（比如初始化轮播、表单校验），放
<head>里，别信“DOMContentLoaded比load快”的模糊说法——实测晚 100ms 加载，LCP 就晚 100ms
内联资源过大反而延长 TTFB 和 DOM 构建起点
为“首屏直出”把 CSS 或初始化数据塞进 <style> 或 <script type="application/json">，结果 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>容易触发浏览器重排压力，优先考虑用flex或grid扁平化结构
真正卡性能的，往往不是你写的 document.querySelector，而是你写的第一个 <script> 标签，以及它前面那堆没剪干净的 <div>。
