Chrome - 开发者工具时间轴和性能计时API中事件时间的区别

Question

我试图在控制台中获取例如loadEventEnd时间。您可以通过性能计时2 API或性能计时API来实现。我通过进行以下计算得到相同的结果：

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

但是在开发工具中的Timeline选项卡中，我得到了结果510毫秒。 在这张图片中显示了差异：

这个问题也发生在其他网站上：在控制台中，我总是比时间轴选项卡中的时间短。 有人能解释一下这种差异吗？ 哪一个时间是真实的？

- Everettss

---

不幸的是，由于某种原因，我的Chrome 58.0.3029.96（64位）安装没有时间轴选项卡，因此我无法提供任何实际研究。然而，我的直觉是控制台和时间轴之间的差异来自于启动JavaScript所需的短暂延迟。在您的示例中，差异为30ms-您是否查看了时间轴选项卡是否在30ms左右发生了任何事情？ - Dragomok

@Dragomok 你说得对。时间轴中在 26 毫秒时出现了 navigationStart 事件。因此，如果从 loadEventEnd 减去 navigationStart，你就会得到 484 毫秒。问题在于，时间轴是在 navigationStart 之前记录的，这与 navigation-timing-api 不同。 - Everettss

@Dragomok 在版本58中，时间轴现在位于性能选项卡中。 - Everettss

Answer 1

正如评论中的@Dragomok所建议的：

navigation-timing-api从navigationStart事件开始记录。性能选项卡时间轴在navigationStart事件之前“一段时间”开始记录，这就是为什么performance.getEntriesByType("navigation")[0].loadEventEnd给出的值比时间轴中的loadEventEnd小。

如果您计算时间轴loadEventEnd - navigationStart，您将得到与navigation-timing-api中相同的值。

下面是证明图片：

- Everettss