Javascript Chrome-devtools timeline中的事件时间与性能计时API之间的差异

例如，我试图在控制台中获取

loadEventEnd

时间。你可以做这件事。 通过这样的计算，我得到了相同的结果：

performance.getEntriesByType("navigation")[0].loadEventEnd
// 483.915
chrome.loadTimes().finishLoadTime * 1000 - chrome.loadTimes().startLoadTime * 1000 
// 484
performance.timing.loadEventEnd - performance.timing.navigationStart
// 484

但在devtools的Timeline选项卡中，我得到了结果510ms。 差异如图所示：

这个问题发生在其他站点上：在控制台中，我得到的时间总是比在时间线选项卡中得到的时间短。 有人能解释这种差异吗？

---

哪一次是真实的？

正如@Dragomok在评论中所说：

导航计时api

在

navigationStart

事件上开始记录。性能选项卡时间线开始记录

navigationStart

事件之前的“某个时间”，这就是

性能的原因。getEntriesByType（“导航”）[0]。loadEventEnd

给出的值小于时间线中的

loadEventEnd

如果您计算timeline

loadEventEnd-navigationStart

，您将获得与

导航计时api

中相同的值

以下是图片中的证据：

---

不幸的是，由于某些原因，我安装的Chrome 58.0.3029.96（64位）没有时间线选项卡，因此我无法提供任何实际的研究。然而，我的直觉是，console和Timeline之间的区别来自为新选项卡启动JavaScript所需的短暂延迟。在您的示例中，差异是30毫秒-您是否查看了时间线选项卡中30毫秒标记附近是否发生了任何事情？@Dragomok您是对的。时间轴中的26毫秒出现

navigationStart

事件。因此，如果从

loadEventEnd

navigationStart

中减去，您将得到484毫秒。问题是时间线记录在

navigationStart

之前，这与版本58中的

导航计时api

@Dragomok不同。时间线现在位于性能选项卡中。