Chrome 与 Web Vitals 上的 TTFB 值不同

Question

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

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

这是一个示例存储库、应用程序 URL和屏幕截图供参考。

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

知道可能出了什么问题吗？这是 WebVitals 上的一个错误，我不应该使用它，或者在消费/记录值时犯错误？

Answer 1

reportWebVitals在 Web 性能社区中，（以及底层库）提供的数字web-vitals通常被认为是正确的 TTFB（尽管公平地说，不同工具的实现存在一些差异）。

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

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

一般来说，资源计时规范可以用作谈论 Web 性能的事实来源。它将时间 0 作为导航的开始：

在整个工作中，所有时间值均以自文档导航开始以来的毫秒为单位 [ HR-TIME-2 ]。例如，文档导航的开始发生在时间 0。

然后定义responseStart为

用户代理的 HTTP 解析器收到响应的第一个字节之后的时间

因此performance.timing.responseStart - performance.timing.navigationStart，它本身就是浏览器对 TTFB 的度量（或在较新的导航计时级别 2 API 中），这也是TTFB 使用的performance.getEntriesByType('navigation')[0].responseStart数字。web-vitals