Chrome 与 Web Vitals 上的不同 TTFB 值

Different TTFB value on Chrome vs Web Vitals

我注意到 Chrome 网络选项卡中的 TTBF 值与 WebVitals 记录的不同。理想情况下,它应该是完全相同的值,但有时在某些情况下会出现高达 2-3 秒的巨大差异。

我正在使用 Next.js 并使用 reportWebVitals 来记录各自的性能指标。

这里有一个sample repo, app url和截图供参考。

使用 performance.timing.responseStart - performance.timing.requestStart 返回的值比依赖 WebVitals TTFB 值更合适。

知道可能出了什么问题吗?这是 WebVitals 上的一个错误,我不应该使用它或在 consuming/logging 值中出现错误?

reportWebVitals(和底层库web-vitals)提供的数字通常被认为是网络性能社区中正确的 TTFB(尽管公平地说,在不同工具的实现上存在一些差异).

我相信 DevTools 将较小的数字标记为“等待 (TTFB)”,作为对用户的非正式提示,“等待”是什么来为其提供上下文,因为它通常是 TTFB 时间的绝大部分。

但是,从以用户为中心的角度来看,第一个字节的时间实际上应该包括从用户开始导航到页面到服务器响应该页面的第一个字节的所有时间--这将包括用于 DNS 解析、连接协商、重定向(如果有)等的时间。DevTools 确实在该屏幕截图中至少包含了一些关于该额外时间的信息,只是在表面上的 TTFB 编号之上分成不同的时间段(请参阅“排队” 、“已停止”和“已发送请求”条目)。

一般是Resource Timing spec can be used as the source of truth for talking about web performance. It places time 0 as the start of navigation:

Throughout this work, all time values are measured in milliseconds since the start of navigation of the document [HR-TIME-2]. For example, the start of navigation of the document occurs at time 0.

然后defines responseStart作为

The time immediately after the user agent's HTTP parser receives the first byte of the response

所以 performance.timing.responseStart - performance.timing.navigationStart 本身就是浏览器对 TTFB 的度量(或者 performance.getEntriesByType('navigation')[0].responseStart 在较新的 Navigation Timing Level 2 API 中),这就是数字 web-vitals uses for TTFB 还有。