【问题标题】:Why do PerformanceResourceTiming interface values differ from browser values?为什么 PerformanceResourceTiming 接口值与浏览器值不同?
【发布时间】:2015-12-04 23:24:30
【问题描述】:

我编写了一个在域上运行并从其他各种域(第三方资源)获取图像的脚本。

我正在尝试使用 window.performance.getEntriesByType('resource') 对事物进行一般健康检查。看来,由于这些资源位于其他域上,因此响应需要在响应标头中设置 Timing-Allow-Origin 才能通过 window.performance.getEntriesByType() 获取计时数据。

这是真的吗?

此外,当我运行我的脚本时,Chrome 浏览器确实返回有用的信息。事实上,如果我能以编程方式获取这些数据,我就可以使用它。但是Chrome显示的数据和window.performance.getEntriesByType()返回的数据不同。

我附上了一个屏幕截图,它显示了 Chrome 加载资源的有用时间细分。由于性能条目对象的数据不匹配。

例如,查看右侧时序图中的 DNS Lookup 时间,然后查看性能条目对象中的 domainLookupStart 和 domainLookupEnd 值。这些值不匹配。

为什么会出现差异?如何获取 Chrome 的数据?如何从性能条目对象中获取 Chrome 显示的内容?

谢谢!

【问题讨论】:

    标签: javascript google-chrome network-programming resource-timing-api


    【解决方案1】:

    您现在可能已经想通了,但我有一个类似的问题并找到了这个。

    PerformanceResourceTiming 对象中最详细的字段对于未设置 Timing-Allow-Origin 标头 as per the spec 的跨域资源报告为零:

    connectStart 必须返回零,除非时间允许检查算法 通过。

    对于其他字段也是如此,例如 DNS 查找字段。

    至于为什么开发者控制台即使不能通过编程方式访问也能看到这些信息,只是Chrome的一个功能可以让你看到这些信息。隐藏它更多的是一种礼貌,而不是一种安全功能;规范规定了可以通过 Resource Timing API 共享的内容,但浏览器仍然可以访问这些信息,并且可能决定以其他方式与用户共享,正如您所见。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2017-10-14
      • 2012-03-25
      • 2019-12-13
      • 1970-01-01
      • 1970-01-01
      • 2021-11-06
      • 2015-12-30
      • 2018-02-21
      相关资源
      最近更新 更多