问题标签 [navigation-timing-api]

例如，我在google 开发人员上找到了一个示例，该示例解释了如何使用导航计时 api 来测量 dom 就绪时间。问题是结果值与 chrome 开发人员工具中显示的值有很大不同。可能是什么错误？

所以，在这里我们可以看到 DCL-event 大约需要 590 毫秒，页面完成时间大约是 594 毫秒（对不起，我没有足够的声誉来发布图像，请你打开开发者工具）。但是......从导航计时 api 捕获的值完全不同（这里应该是谷歌文章的链接）。

这就是他们获得此值的方式：

我想测量 Facebook、youtube 等外部网站的性能页面负载。我发现导航时间是实现这一点的工具。但问题是它只在我的网站上完成。否则我可以在打开 Facebook 页面时执行导航计时 api 吗？

我正在尝试为 AngularJS (1.5.x) 实现一个拦截器，它可以测量每个 api 调用并将每个调用的持续时间发送到 Google Analytics。

我从一个虚拟实现开始，只使用new Date().getTime()：

乍一看，它看起来不错，但比较在 Chrome 的 Networks 选项卡中收集的请求的持续时间，我注意到在我的代码中收集的请求总是比 Chrome 收集的要高（有时很多！）。

我想到的另一个想法是使用User Navigation API，所以我将代码更改为：

.. 但我再次收到与Chrome收集的结果不同的结果，甚至与使用new Date().getTime()

我究竟做错了什么？我该怎么做才对？也许是资源计时 API？AngularJS 确实强加了一点。

我无法使用用户导航 API 方法 -window.performacne.getEntries()查找我的请求持续时间，因为我无法识别特定请求。每个请求的参数在那里不可用，我有很多相同的 API 调用，但参数不同。

我应该装饰 AngularJS 使用的原生 XHR 请求吗？

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

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

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

我一直在使用导航计时 api来收集有关我的网站性能的实际用户数据。基本上，每次用户访问该站点时，我都会将此数据发送回服务器并将其存储在数据库中。

现在我分析了这些数据，我发现domainLookupStart即使没有发生重定向，它也异常高。平均而言，超过 3 个月的数据，它高达 ~400 毫秒。这弥补了我“第一个字节的时间”的大部分内容。

我想知道是否有人对浏览器触发 domainLookupStart 导航计时事件之前发生的工作有更好的理解。我能做些什么来缩短这个时间吗？

我试图了解Navigation Timing API。当我看下面的例子时：

在上述情况下，如果我只是打开浏览器并运行这 3 行，我会得到一个非零数字。如果实际上没有导航，我希望它为 0，所以看起来我不明白它是如何工作的。

如果我想知道加载 DOM 需要多长时间，我将如何使用这个 API。如果我导航到一个页面然后执行：

我要得到的这个数字是多少？这是最后加载的页面吗？

Chrome 的 Lighthouse 工具和 WebPageTest 提供“交互时间”（TTI）指标。

Google 提供了 TTI 的最小定义：

交互时间被定义为布局稳定、关键网络字体可见并且主线程足以处理用户输入的时间点。

请注意，此指标处于早期阶段，可能会发生变化。

WebPageTest将它们分为“首次交互时间”和“持续交互时间”：

是时候进行一致的交互式计算了

• 开始在第一个内容绘制或加载的 DOM 内容中的较大者处寻找 TTI
• 查找第一个交互窗口，其中有 5 秒的连续时间段完全包含在交互窗口中，并且不超过 2 个进行中的请求
• TTI 是从步骤 2 开始的交互式窗口或搜索起点，以较晚者为准

第一次交互式计算

• 开始在第一个内容绘制或加载的 DOM 内容中的较大者处寻找 TTI
• 查找第一个交互式窗口，其中有 5 秒的连续时间段完全包含在交互式窗口中，无论进行中的请求数量如何
• TTI 是从第 2 步开始的交互式窗口的起点或搜索起点，以较晚者为准

我想在客户端计算 WebPageTest 的两个不同 TTI 指标并将它们发送回 API（用于RUM目的）。

当前的 JavaScript API 是否可以进行这样的计算？如果是这样，怎么做？

更新：

我还没有找到令人满意的客户端解决方案，但我找到了更深入的 TTI 定义。

我正在使用 Navigation Timing API 收集数据。

具体来说，这四个指标：

我经常发现redirectTime + lookupDomainTime + connectTime > firstPaintTime。如果 Chrome 的第一次绘制指标是从 navigationStart 计算的，那么这意味着第一次绘制发生在任何 HTML 下载之前。这似乎是不可能的。

如果 firstPaintTime 不是从 计算的window.performance.timing.navigationStart，它是从什么点计算的？

我正在尝试使用计时 API 测量页面加载性能。首先，我将下面的代码包含在我的 html 文档的正文中，以检查我是否正确获取了所有属性。

输出如下

导航开始：1538169000862
responseStart：1538169000862
responseEnd：1538169000862
domComplete：1538169001831
loadEventStart：1538169001831 LoadEventEnd：0

我想知道为什么 LoadEventEnd 为零？是因为页面还在加载吗？那么捕捉这些指标的最佳时间是什么时候？

编辑：--引入超时后，我能够捕获 LoadEvendEnd 时间。但是，当我转到下一页时，许多属性现在为零。

导航开始：1538172249035 responseStart：1538172249035 responseEnd：1538172249035 domComplete：0 loadEventStart：0 LoadEventEnd：0

据我了解，此导航位于框架内。

window.performance.timing目前我在一个window.addEventListener('load', function () {...})函数中读取值。但是在 safari 中，有些值loadEventEnd仍然设置为0.

如何以window.performance.timing基于事件的最佳方式延迟我的呼叫，直到定义此值和其他值？