跳转卡顿主因是跳转前JS执行阻塞或跳转后组件渲染开销大，而非跳转指令本身慢；需用Performance面板定位长任务、优化异步时机、控制组件加载及缓存策略。
跳转时白屏超过 300ms 就该怀疑 window.location.href 触发时机
很多卡顿实际不是跳转慢，而是跳转前 JS 还在执行重绘或未完成的 Promise。比如在点击事件里先调用 fetch 获取数据，再立刻赋值 window.location.href = '/next'，但浏览器可能因渲染线程被阻塞而延迟导航。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用 Chrome DevTools 的 Performance 面板录制点击到新页面
DOMContentLoaded的全过程，重点看「Main」线程是否在跳转前有长任务（>50ms） - 确保跳转逻辑不依赖未 resolve 的异步操作；若必须等数据，改用
history.pushState()+ 后续location.replace()控制时机 - 避免在
onclick中连续触发多次window.location.href（比如防抖没加或重复绑定），这类错误常导致跳转被浏览器忽略或排队延迟
SPA 路由跳转卡顿大概率是组件卸载/挂载开销过大
Vue Router 或 React Router 的 router.push() 看似瞬时，但若目标页面组件里有未清理的 setInterval、大型 useEffect 初始化、或同步 DOM 操作（如 document.querySelector().offsetHeight），就会拖慢页面切换。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 在目标组件
mounted（Vue）或useEffect（React）开头打时间戳，结尾再打一次，确认耗时是否异常（>100ms 需警惕） - 检查是否在组件内直接操作了大量 DOM 节点，尤其是用了
innerHTML插入未预编译的 HTML 字符串 - 对含图表、富文本编辑器等重型子组件，考虑用
v-if或React.memo延迟加载，或用import()动态导入
Service Worker 缓存策略不当会放大跳转延迟
如果注册了 Service Worker 且使用了 cache-first 或 stale-while-revalidate 策略，但缓存键没排除 URL 参数（如 /page?id=123），就可能每次跳转都触发冗余 fetch 和 cache.match，反而比直接网络请求更慢。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 在 SW 的
fetch事件监听器中加console.debug，确认每次跳转是否真的命中缓存（查看 Network 面板的 Size 列是否显示from ServiceWorker） - 检查
caches.open()的缓存名是否带时间戳或哈希，避免旧缓存长期不更新导致匹配逻辑变重 - 对纯 HTML 页面跳转，优先用
network-first策略，除非明确需要离线支持
移动端 WebView 中 location.replace() 比 href 更易卡顿
在 iOS WKWebView 或某些 Android WebView 中，location.replace() 会清空当前 history entry，但部分版本实现会强制同步刷新渲染树，导致视觉卡顿；而 location.href 虽保留历史，但调度更轻量。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 在混合 App 场景下，优先用
window.location.href = url，仅当明确需禁用返回按钮时才用replace() - 若必须用
replace()，可在跳转前加requestIdleCallback(() => location.replace(url))让出主线程空闲周期 - 避免在
beforeunload里调用任何跳转逻辑——该事件本身已处于页面卸载临界点，极易引发 UI 冻结
