前端 PerformanceNavigationTiming 怎样计算首字节时间

页面打开慢时，先别把“首屏渲染慢”和“服务器迟迟不回首字节”混为一谈。导航级 TTFB（Time to First Byte）关注的是浏览器从本次导航开始，到收到文档响应第一个字节的时间。用 PerformanceNavigationTiming 计算时，核心公式是 entry.responseStart - entry.startTime；导航条目的 startTime 固定为 0，所以也可以直接读取 responseStart。

下面的示例只处理当前文档导航，不把资源请求、FCP 或 LCP 混进来。最后还会说明为什么 responseStart - requestStart 是另一个指标。

先确定导航计时对象和时间基准

PerformanceNavigationTiming 表示当前文档的一次导航记录，时间字段是相对本次导航起点的高精度时间戳，不是 Date.now() 那种 Unix 时间。常见字段可以这样理解：

• startTime：导航记录的起点，导航条目中为 0。
• fetchStart：浏览器准备开始获取文档的时刻。
• requestStart：浏览器准备向服务器发出请求的时刻。
• responseStart：浏览器收到响应首字节的时刻。
• loadEventEnd：页面 load 事件处理完成的时刻，与 TTFB 不是一回事。

用 responseStart 计算导航级 TTFB

如果脚本在页面已经产生导航条目后执行，可以从 performance.getEntriesByType("navigation") 取当前文档的条目。先判断数组是否为空，再判断 responseStart 是否已经是正数，避免把“没有条目”误报成 0 毫秒。

function readNavigationTTFB() {
  // 当前文档通常只有一个 navigation 条目，取不到时返回 null。
  const entries = performance.getEntriesByType("navigation");
  const entry = entries[0];
  if (!entry || entry.responseStart 

这个值可以直接作为一次导航样本。它的意义是“从导航起点到响应首字节”，其中可能包含 DNS、TCP、TLS、重定向和服务器等待等阶段。它不等于后端应用代码的纯执行时间。

用 PerformanceObserver 接住已经产生的导航条目

监控脚本经常不是最早执行的脚本。如果只监听未来事件，可能错过已经写入性能时间线的导航记录。PerformanceObserver 的 buffered: true 可以把观察器创建前已经记录的条目也交给回调。

function reportTTFB(entry) {
  // 只接受导航条目，且忽略尚未形成响应时间的记录。
  if (entry.entryType !== "navigation" || entry.responseStart  {
  // 一个回调可能带来多个条目，因此逐个交给处理函数。
  list.getEntries().forEach(reportTTFB);
});

// buffered 让晚启动的监控逻辑也能读取已有的 navigation 条目。
observer.observe({ type: "navigation", buffered: true });

如果监控只需要在页面初始化阶段取一次值，读取现有条目就足够；如果要统一接入性能采集管线，观察器更合适。使用完观察器后可以调用 observer.disconnect() 停止继续接收回调。

别把请求耗时和最终响应时间混成 TTFB

最容易混淆的是下面两个公式：

另外，使用 103 Early Hints 的站点可能先收到临时响应，因此 responseStart 不一定代表最终响应头。若浏览器支持并且你的问题是“最终响应何时开始”，应单独关注 finalResponseHeadersStart。不要为了让指标变小而替换公式，先把业务问题说清楚。

上线前的最小复盘清单

• 页面级 TTFB 使用 navigation 条目，不要从资源条目中随便挑一个请求。
• 所有相减字段来自同一条目，避免把相对时间和 Unix 时间相减。
• 条目不存在或 responseStart 未就绪时跳过样本，不写入 0 毫秒。
• 观察器晚启动时使用 buffered: true，需要停止监听时调用 disconnect()。
• 遇到 Early Hints，明确你要的是“首个字节”还是“最终响应头”。

归纳成一句话：导航级 TTFB 看 PerformanceNavigationTiming.responseStart 相对于 startTime 的差值；请求等待段才看 responseStart - requestStart。先选对时间边界，再谈性能优化。

相关问题

为什么不用旧的 performance.timing？

旧接口的时间戳是 Unix 时间且已被现代 Navigation Timing API 取代。新代码优先使用 PerformanceNavigationTiming 的高精度相对时间字段。

TTFB 高是不是一定说明后端慢？

不一定。DNS、连接建立、TLS、重定向、缓存路径和网络状况都可能影响导航级 TTFB，需要结合各阶段字段拆分判断。