我注意到 Chrome 网络选项卡中的 TTBF 值与 WebVitals 记录的不同。理想情况下，它应该是完全相同的值，但有时在某些情况下会出现 2-3 秒的巨大差异。
我正在使用 Next.js 并使用reportWebVitals来记录各自的性能指标。
这是一个示例 repo、应用程序 url和屏幕截图以供参考。
使用performance.timing.responseStart - performance.timing.requestStart返回比依赖 WebVitals TTFB 值更合适的值。
知道可能出了什么问题吗？是否是 WebVitals 上的错误，我不应该使用它，或者在我最终使用/记录值时出错？
由reportWebVitals（和底层库web-vitals）提供的数字通常被认为是 Web 性能社区中正确的 TTFB（尽管公平地说，跨工具的实现存在一些差异）。
我相信 DevTools 将较小的数字标记为“等待 (TTFB)”，作为向用户提供“等待”是什么意思的非正式提示，因为它通常是 TTFB 时间的大部分。
但是，从以用户为中心的角度来看，第一个字节的时间应该真正包括从用户开始导航到页面到服务器响应该页面的第一个字节的所有时间——这将包括时间DNS 解析、连接协商、重定向（如果有的话）等。DevTools 确实在该屏幕截图中至少包含了一些关于额外时间的信息，只是在表面上的 TTFB 编号上方分为不同的时期（参见“排队”、“停滞”、和“请求发送”条目）。
通常，Resource Timing 规范可以用作谈论 Web 性能的事实来源。它将时间 0 作为导航的开始：
在整个工作中，所有时间值都以自文档导航开始 [ HR-TIME-2 ] 起以毫秒为单位进行测量。例如，文档的导航开始发生在时间 0。
用户代理的 HTTP 解析器收到响应的第一个字节后的时间
因此performance.timing.responseStart - performance.timing.navigationStart，它本身就是浏览器对 TTFB 的度量（或performance.getEntriesByType('navigation')[0].responseStart在更新的 Navigation Timing Level 2 API 中），这也是web-vitals TTFB 使用的数字。