Chrome - devtools时间线中的事件时间和性能计时API之间的差异答案

【问题标题】：Chrome - Difference between event time in devtools timeline and performance timing APIChrome - devtools时间线中的事件时间和性能计时API之间的差异
【发布时间】：2017-04-30 19:16:10
【问题描述】：

我正在尝试在控制台中获取例如loadEventEnd 时间。您可以通过performance timing 2 API 或performance timing API 进行操作。通过这样的计算，我得到了相同的结果：

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 选项卡中，我得到结果 510 ms。差异如图所示：

此问题发生在其他站点上：在控制台中，我总是比在时间轴选项卡中获得更短的时间。有人可以解释这种区别吗？哪一次是真实的？

【问题讨论】：

不幸的是，由于某种原因，我安装的 Chrome 58.0.3029.96（64 位）没有时间轴选项卡，所以我无法提供任何实际研究。但是，我的预感是控制台和时间线之间的区别来自为新选项卡启动 JavaScript 所需的短暂延迟。在您的示例中，差异为 30 毫秒 - 您是否查看过 30 毫秒标记附近的时间线选项卡中是否发生任何事情？
@Dragomok 你是对的。在时间线的 26 毫秒处出现 navigationStart 事件。因此，如果您从 loadEventEnd navigationStart 中减去，您将得到 484 毫秒。问题是时间线是在navigationStart 之前记录的，这与navigation-timing-api 不同。
@Dragomok 版本 58 时间线现在位于“性能”选项卡中。

标签： javascript performance google-chrome navigation-timing-api

【解决方案1】：

正如@Dragomok 在评论中建议的那样：

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

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

以下是图片证明：

【讨论】：