页面卸载性能虽非performance api直接指标，但通过unloadeventstart与unloadeventend差值（>100ms表明阻塞）、navigationstart - unloadeventend间隔（>50ms提示衔接卡顿），结合type字段判断跳转类型，并用performanceobserver捕获卸载前long task，可精准分析跳转效率。
页面卸载性能本身不是 Performance API 直接暴露的指标，但它是影响跳转流畅度的关键隐性环节。真正要监测的，是前页卸载是否及时、是否阻塞了后续页面的启动。核心在于分析 navigation timing 中与 unload 相关的时间戳，并结合跳转类型和运行时行为交叉判断。
读取 unload 时间戳并验证有效性
通过 performance.getEntriesByType('navigation') 获取当前页导航记录，从中提取 unloadEventStart 和 unloadEventEnd：
- 先确认
unloadEventStart > 0：说明浏览器确实执行了 unload 流程（非跨域、非 back_forward 复用场景） - 计算差值
unloadEventEnd - unloadEventStart：正常应为几毫秒；若持续 >100ms，表明前页存在同步脚本、未释放资源（如 WebSocket、定时器）、或未清理的事件监听器 - 注意：该字段仅在前后页同源时有效；跨域跳转中值恒为 0，此时需转向 long task 分析
评估跳转衔接是否顺畅
卸载完成到新页启动之间的空档，直接影响用户感知的“卡顿感”：
- 计算
navigationStart - unloadEventEnd：理想值应 ≤50ms - 若该间隔明显偏大（如 >100ms），常见原因包括主线程被长任务占用、事件队列积压、或前页 unload 回调中执行了耗时操作
- 配合
type字段判断跳转类型：navigate必触发完整 unload；back_forward可能跳过 unload，此时该差值无意义，应关注 restore 时的 paint 指标
捕获卸载前的长任务作为佐证
卸载阻塞往往源于跳转前最后一段 JS 执行卡顿，PerformanceObserver 可实时捕获：
- 注册监听
longtask类型条目，在页面卸载前（如 beforeunload 或 unload 阶段）检查是否有持续 >50ms 的长任务 - 重点排查跳转前触发的异步回调、未 await 的 Promise、或循环渲染逻辑
- 搭配控制台警告（如
[Deprecation] unload event listener was registered but not removed）可快速定位未清理的监听器
确保数据上报不丢失
卸载阶段是数据采集的“临界窗口”，必须保证上报可靠：
- 使用
navigator.sendBeacon()在beforeunload或pagehide中发送性能数据，避免因页面销毁导致 XHR 失败 - 优先上报关键字段：unloadEventStart、unloadEventEnd、navigationStart、type，以及最近一次 long task 的 duration 和 startTime
- 避免在 unload 回调中执行复杂计算或 DOM 操作，防止进一步拖慢卸载流程
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
