PerformanceNavigationTiming返回异常值，浏览器扩展API是否存在问题？

你遇到的这个异常数据，核心问题是时间戳逻辑矛盾：导航后期的loadEventEnd（1618111ms）和早期的domContentLoadedEventStart（91ms）完全脱节，导致duration异常超大，这大概率不是API的普遍bug，而是特定场景下的计时偏差或数据捕获问题，具体分析如下：

可能的原因 #

• 页面后台挂起后恢复：浏览器会暂停后台页面的计时器，当用户重新激活页面时，计时器继续运行，但Performance API的部分时间戳是基于页面初始加载时的真实时间，而后期事件（如loadEventEnd）是基于恢复后的时间，导致时间线断层。比如用户打开页面后切到后台几小时再回来，domContentLoaded是刚加载时的几十ms，而load事件（或后续资源加载）在恢复后触发，最终duration被计算为loadEventEnd - startTime，就会出现几十分钟的离谱值。
• 浏览器重载场景的计时bug：你的数据中type: "reload"，部分浏览器在处理页面重载时，可能出现NavigationTiming条目时间戳未正确重置的情况，导致新旧导航的时间数据混在一起，出现逻辑矛盾的时间点。
• 扩展注入时机的影响：作为浏览器扩展，若content script是在页面加载完成后才注入，通过buffered: true获取历史导航条目时，可能拿到不完整的、被浏览器状态变更篡改的数据，尤其是页面经历过挂起/恢复的情况。

解决方案 #

• 添加数据校验逻辑：上报前对数据做合理性检查，过滤异常值：
  • 校验时间戳顺序：比如domContentLoadedEventStart > fetchStart、domComplete > domContentLoadedEventEnd等，不符合导航流程的数据直接丢弃
  • 设置duration阈值：比如超过10分钟（600000ms）的标记为异常，不纳入统计
• 提前扩展注入时机：在扩展manifest中配置content script的run_at: "document_start"，让PerformanceObserver在页面加载初期就开始监听，避免依赖buffered获取可能有问题的历史数据
• 结合页面可见性判断：用Page Visibility API监听页面的visibilitychange事件，标记那些曾经进入后台的页面数据，后续统计时可以单独处理或过滤

内容的提问来源于stack exchange，提问作者Andrea11