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