如何使用PerformanceNavigationTiming API跟踪Web Workers和跨源iframe的任务时长

可以从PerformanceNavigationTiming API拿到可用于跨上下文计算的时间戳，以下是两种可落地的实现方案：

方案1：相对时间转绝对时间戳（完全兼容现有逻辑） #

所有支持PerformanceNavigationTiming的执行上下文（主页面、Web Worker、同源/跨源iframe）都原生暴露performance.timeOrigin属性，该属性返回当前上下文时间原点对应的UNIX绝对时间戳（毫秒级）。只需要将PerformanceNavigationTiming返回的相对时间值和performance.timeOrigin相加，即可得到和旧版PerformanceTiming完全对齐的绝对时间戳，原有事件上报、耗时计算逻辑不需要做任何修改。

代码示例：

// 各上下文（主页面/Worker/iframe）通用的导航时间绝对值计算方法
const getAbsoluteNavigationTiming = () => {
  const [navigationEntry] = performance.getEntriesByType('navigation')
  return {
    // 等价于旧API的 window.performance.timing.responseStart
    responseStart: navigationEntry.responseStart + performance.timeOrigin,
    domComplete: navigationEntry.domComplete + performance.timeOrigin
    // 其余导航事件字段均可按相同规则转换
  }
}

// 事件上报逻辑和原有实现完全一致
const metricEvents = [
  { name: 'appStart', time: getAbsoluteNavigationTiming().responseStart }
]
metricEvents.push({ name: 'interactive', time: new Date().getTime() })

注意事项 #

• 跨源iframe可以在自身上下文内完成绝对时间的计算，再将结果发送给主站的中心事件库，不需要主站跨域读取iframe的性能数据，无跨域限制。
• 低版本浏览器如果不支持performance.timeOrigin，可以用Date.now() - performance.now()做降级计算，结果和原生属性精度一致。

方案2：基于相对时间的跨上下文计算（更规范的新API适配方案） #

如果不需要兼容旧的绝对时间戳逻辑，可以采用更符合新API设计的实现方式，精度更高且不受本地系统时间修改影响：

• 各上下文上报事件时，同时携带自身的performance.timeOrigin和事件的相对时间（performance.now()的返回值或者PerformanceNavigationTiming的原生字段值）
• 中心事件库聚合时，统一通过「相对时间 + 所属上下文timeOrigin」的方式计算全局统一时间，再做差值计算耗时
• 该方案使用的DOMHighResTimeStamp为微秒级精度，远高于Date.now()的毫秒级精度，适合对指标精度要求高的场景。

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