如何解决Chrome 和 Web Vitals 上的不同 TTFB 值
我注意到 Chrome 网络选项卡中的 TTBF 值与 WebVitals 记录的不同。理想情况下，它应该是完全相同的值，但有时会在某些情况下看到高达 2-3 秒的巨大差异。
我正在使用 Next.js 并使用 reportWebVitals 来记录各自的性能指标。
这是一个 sample repo、app url 和屏幕截图供参考。
使用 performance.timing.responseStart - performance.timing.requestStart 返回比依赖 WebVitals TTFB 值更合适的值。
知道可能出了什么问题吗？是 WebVitals 上的一个错误，我不应该使用它或我最终在使用/记录值时出错？
解决方法
reportWebVitals（以及底层库 web-vitals）提供的数字在网络性能社区中通常被认为是正确的 TTFB（尽管公平地说，不同工具的实现存在一些差异）。
我相信 DevTools 将较小的数字“等待 (TTFB)”标记为向用户提供的“等待”是什么的非正式提示，因为它通常是 TTFB 时间的大部分。
但是，从以用户为中心的角度来看，第一个字节的时间应该真正包括从用户开始导航到页面到服务器响应该页面的第一个字节的所有时间——这将包括用于 DNS 解析、连接协商、重定向（如果有）等的时间。DevTools 确实在该屏幕截图中至少包含了一些关于额外时间的信息，只是在表面上的 TTFB 编号上方分成不同的时间段（参见“排队”，“停止”和“请求已发送”条目）。
通常，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-vitals uses for TTFB .
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。