DOM深度超6层导致路由切换卡顿，主因是浏览器重建DOM时需反复遍历祖先链进行样式计算、布局定位和事件委托，而非JS执行慢。
DOM深度超6层会让路由切换变卡
不是JS执行慢，而是浏览器在每次路由切换后重建/更新DOM时，要反复遍历祖先链做样式计算、布局定位和事件委托。实测平均嵌套深度从4升到8，getComputedStyle()耗时翻倍；深度达12时，低端安卓机单次样式查询卡顿超80ms。
常见错误现象：body > div > div > div > .page-content > .list > .item 这类结构在Vue Router或React Router切换后动态插入内容时，会触发整棵子树重排——改一个.list高度，实际要重算所有.item及其子节点。
- 用Chrome DevTools → Elements面板右键任意节点 → Show DOM properties，看
depth值，超过6就要拆 - SPA中路由出口（如
<router-view>或<Outlet>）的父容器别再套三层<div class="wrapper">，直接用<main>或<section> - 服务端渲染（SSR）输出的HTML最容易藏深层嵌套，Next.js里检查是否因
data-reactroot外又包了冗余<div id="root">
BrowserHistory切换慢，不全是JS的问题
BrowserHistory平均切换耗时32.6ms（测试数据），比HashHistory慢4.3ms，但真正拖住首屏的是它触发的同步样式计算和DOM重建——尤其当目标容器本身嵌套过深时，applyTx状态更新阶段会放大延迟。
关键瓶颈不在pushState()调用，而在后续框架把新组件挂载进一个深度为9的<div>树里：浏览器必须为每个新增节点向上遍历9层匹配CSS选择器，同时还要重排整条路径上的所有块级元素。
立即学习“前端免费学习笔记（深入）”；
- 避免在
beforeRouteEnter或useEffect里同步调用document.querySelector('.deep-nested .item')，先缓存父容器引用再查子节点 - 路由组件顶层用
<section class="route-page">替代<div class="container"><div class="row"><div class="col"> - 如果用
MemoryHistory测试发现切换快很多（15.8ms），那基本能锁定是DOM结构或BrowserHistory监听链与深层树耦合导致的性能衰减
内联脚本位置不当会让路由切换白屏
哪怕只有一行<script>console.log('init')</script>放在<head>里，也会阻塞HTML解析。路由切换后若新页面仍沿用旧模板，这个同步脚本就会卡住整个DOM构建流程——此时你看到的“卡顿”，其实是白屏等待JS执行完才继续解析后续HTML。
更隐蔽的情况：SSR生成的HTML里内联了初始化数据<script type="application/json" id="ssr-data">{...}</script>，体积超10KB后，浏览器解析器会在文本扫描阶段明显减速，DOM构建起点被迫延后。
- 所有
<script>标签必须移到</body>前，含内联逻辑 - SSR注入的数据尽量压缩+序列化，别直接
JSON.stringify(store.state)扔进去 - 用
defer而非async加载路由相关JS，确保执行顺序不破坏组件挂载流
移动端WebView里DOM深度影响比桌面端更致命
桌面Chrome对深层DOM有一定优化缓冲，但Android WebView（尤其Chrome 90以下）和iOS Safari会严格按深度逐层递归计算样式。一个深度为10的列表页，在路由切换后插入50个<li>，主线程可能连续触发300ms以上的Layout任务，直接掉帧。
这不是代码写得不够“现代”，而是引擎层面的固有约束：JavaScript访问element.offsetHeight或getBoundingClientRect()时，必须同步触发完整布局计算，而路径越长，桥接开销越大——深度10比深度3慢3.7倍，且无法靠节流规避。
- 高频操作前务必缓存节点引用：
const list = document.querySelector('.route-list');，而不是每次循环都document.querySelector() - 折叠面板、动态表格这类常展开/收起的模块，用
display: none隐藏整块，别只设visibility: hidden——后者仍保留布局计算 - 超过100项的列表，强制走虚拟滚动或
<canvas>渲染，别依赖原生DOM批量插入
