问题标签 [navigation-timing-api]

我目前正在我们的项目中实现性能测量功能，它使用自定义元素 v1。

NavigationTimingAPI提供了对不同导航类型（导航、重新加载、浏览器后退/前进）的非常详细的测量：

是否也可以为异步调用提供相同的（或类似的详细信息）？或者是否还有其他我不知道的 API？

也就是说，当页面完全加载并且某些用户交互或事件触发服务器定位资源上的 POST 或 GET 时。

到目前为止，我发现的唯一一件事是使用performance.mark().

我在这里错过了什么重要的东西吗？

在通过Navigation Timing API的responseStart时间减去requestStart时间来计算服务器响应时间时，在IE11上多次接近0，这与服务器端的数据不匹配。这发生在带有 iframe 的页面上，这是一个已知问题还是有解决方法？

在 Chrome 上，结果更接近服务器端时间，但在 IE11 上不是

domLoading时间表示浏览器处理文档的最开始时间。

但是 domLoading 属性已从 Timing API 中删除：performance.getEntriesByType("navigation")[0].domLoading == undefined

我从 2015 年 9 月 17 日找到了一个动机：

该domLoading属性已弃用，可能会在本规范的未来版本中删除。由于现有用户代理中创建 Document 对象的时间不同，domLoading 返回的值是特定于实现的，不应在有意义的 metrics 中使用。

MDN都没有告诉使用什么来代替。我觉得很奇怪，我没有发现任何关于这个的问题。responseEnd 和 domInteractive 是我能看到的时间上最近的属性，但它们相差太大。

如果没有在处理文档时使用此属性，我无法知道文档交互、加载或完成内容需要多长时间。

是否有任何正确的参考来衡量和比较，我错过了或可以改用？

我在 w3c.github.io 上发现了这个新的时间线，表明没有 dom 的开始可以测量。

让我们通过来自www.w3.org的注释进行介绍，其中包括两个比较重要的链接。

PerformanceTiming 接口在[NAVIGATION-TIMING]中定义，现在被认为已过时。支持使用 PerformanceTiming 接口中的名称以保持向后兼容，但没有计划将来将此功能扩展到 [NAVIGATION-TIMING-2]（或其他接口）中定义的 PerformanceNavigationTiming 接口中的名称。

我已经制作了一个函数来获取应该向后和向前兼容的导航时间，因为我们正处于转换到级别 2 的中间时代。所以这个从事件名称中获取时间的函数在 Chrome 中有效，但在 Firefox 中无效：

说明：当没有“导航”条目时，这会退回到基于Unix 纪元时间（自 1970 年以来以毫秒为单位）的已弃用方式进行导航计时（lev1），而新方式（lev2）是自当前以来的HR 时间（以毫秒为单位）文档导航开始加载，这与始终具有 HR 时间格式的用户计时一起很有用。

我们如何才能在所有情况下获得函数返回 HR 时间？

当我看到一个超过 10 位数字且没有句点的数字时，我知道这是从已弃用的 Navigation Timing 级别 1 获得的时间。所有其他测试用例都给出小数点数字，这意味着它是 HR 时间，精度更高。最大的问题是它们有不同的时间渊源。

我经历了混乱、试错和沮丧的搜索（MDN 尚未更新到第 2 级）来确认并声明：

• 导航计时级别 1 使用unix 纪元时间，其余...
• 导航计时级别 2 使用HR 时间
• 用户计时级别 1 使用HR 时间
• 用户计时级别 2 使用HR 时间
• 在 Chrome 和 Firefox 中也performance.now()有HR 时间。

如何将unix 纪元时间转换为HR 时间？

解决了 。：

代码在 Amadan 的帮助下得到纠正。
请参阅接受的答案中的评论。

在使用旧的时序lev1的performance.timeOrigin情况下会减少。 如果浏览器没有它，则通过减少自 timeOrigin 以来的时间来近似 timeOrigin，从(new Date().getTime())自 Unix Epoch的时间到导致timeOrigin 自 Unix Epoch 的时间。显然这是定义，尽管链接有点模糊。我通过测试确认，我相信答案。希望 w3c 对 timeOrigin 的定义比性能测量开始时间的高分辨率时间戳更好。
performance.now()

函数返回值表示自时间原点以来经过的时间。

在大多数情况下它可能是微不足道的，但它执行的测量时间t被performance.now()删除以近似同时执行。

我在我的 Raspberry Pi 上测量t到几乎 10 微秒，它在各种循环大小下相当稳定。t但是我的联想在测试更大的循环尺寸时没有那么精确地四舍五入并缩短时间。

在最后一行代码中注释掉了另一种解决方案。
已弃用performance.timing.navigationStart：

表示自 UNIX 纪元以来的时刻（以毫秒为单位），即在卸载提示在同一浏览上下文中的上一个文档上终止之后。如果没有之前的文档，这个值会和 PerformanceTiming.fetchStart 一样

因此，要检查当前文档（忽略任何以前的文档），然后使用已弃用的performance.timing.fetchStart：

表示自 UNIX 纪元以来的时刻，以毫秒为单位，浏览器已准备好使用 HTTP 请求获取文档。这个时刻是在检查任何应用程序缓存之前。

如果它是浏览器唯一理解的属性，那么使用不推荐使用的属性当然是正确的。当“导航”未定义在getEntriesByType具有良好浏览器支持的情况下使用。

快速检查在此之前通过此行相互确认return：

结果在我的 Chrome 中看起来像这样

1560807558225.1611
1560807558225
1560807558241

我的登录屏幕中有一个动画，它应该在单击登录按钮时向下滑动按钮并同时向上滑动电子邮件和密码输入框，我的持续时间为 2000 毫秒，但位置会立即改变的平滑滑动。

动画在一个功能组件中，因此在我单击以反转它之前阻止动画恢复，所以我使用 useState() 来保持位置。（以前在我使用 useState() 之前，当我更改文本时输入框，动画将重置回原始位置）

这里是动画

我有 2 个调用动画的按钮 onPress() 并有 2 个改变位置的视图，位置改变得很好，但我不会逐渐滑出，只是立即改变

谢谢

我们有一个生产监控系统，它提供 W3C 标准所指示的 Web 导航和资源计时统计信息。下面给出了统计数据的示例参考：

https://developer.mozilla.org/en-US/docs/Web/Performance/Navigation_and_resource_timings

在我们网站的生产监控过程中，我们发现文档卸载 (unloadEventEnd) 统计数据在接近第一个字节时间 (responseStart) 的一侧较高。所以，我得到了一个澄清：

如果由于任何可能的原因导致文档卸载需要更长的时间 - 是否会导致其当前的 API/Ajax 或 Https 请求被延迟，总结返回响应的第一个字节所花费的总时间，因此显示第一个字节的时间值更高（ responseStart) 指标？

我们正在使用Boomerang检测页面，包括来自Navigation Timing Level 2的大部分时间线数据。大多数情况下，这一切都很好，但是对于我们正在检测的一小部分请求，我们得到的时间戳似乎是无序的，当我们减去无序的时间戳时会导致负的持续时间值。

例如，查看我们几个小时的数据，在大约 1000 万次点击中，我看到：

• 56 个时间戳responseEnd早于的实例responseStart（例如responseEnd= 1619456473999，responseStart= 1619456479419）
• 时间戳unloadEventEnd早于的 17 个实例unloadEventStart（例如unloadEventEnd= 1619457675970，unloadEventStart= 1619457682839）
• 时间戳domComplete早于的 7 个实例domLoading（例如domComplete= 1619399859821，domLoading= 1619399860472）

我在各种各样的浏览器中都看到了这一点，其中许多是旧的，但有些是较新的（Firefox 88、Safari 13.1.2）。

基本上，我试图弄清楚这是否是每个人都会发生的事情，并且只是真实浏览器中导航计时的世界状态（在这种情况下我应该忽略它），或者它更有可能是什么我们的仪器有问题（在这种情况下，我需要弄清楚它是什么并修复它）。

感谢您对自己的体验提出任何建议或反馈！

----斯科特。

我正在尝试获取加载页面所需的时间，但我不确定运行此脚本的正确方法。

我以为我可以这样做：

但是它总是返回 0；

如果我之后在控制台中运行它，它工作正常。在窗口加载事件之后我可以使用另一个事件吗？这个函数的正确用法是什么？

编辑：似乎使用 setTimeout 将其添加为页面完全加载后运行的第一件事。工作代码是：