我一直在使用PerformanceObserver来衡量网络请求的时间。尽管看起来确实可行，但是我发现了一些问题：
如果网络请求被服务器重定向（基本上服务器将响应标头返回为Location: "same-origin-different-url"），则资源计时仅包括从发出请求到服务器发送响应代码302的时间。因此，重定向的URL被跳过，并且在performance.getEntriesByType('resource')返回的所有资源条目中也找不到它。另外，还要注意，redirectStart和redirectEnd属性不包括重定向的URL时间，因为它被重定向到相同的来源more info。那么，有什么方法可以计算重定向URL的时间？
某些网络请求需要一些时间来进行DNS查找，我可以在Chrome->网络->计时窗口中观察这些DNS查找时间。但是，PerformanceObserver观察到的相同请求始终在domainLookupStart和domainLookupEnd上返回0。因此，计时与Chrome Network计时工具不匹配。有什么想法吗？
如果有人遇到这些问题并找到了解决方法，我将不胜感激。
答案 0 :(得分：1)
仔细阅读了documentation后，我发现响应标头必须包含Timing-Allow-Origin标头。否则，这些属性将返回0。使用Charles代理添加此标头后，我没有看到任何问题。
跨源资源必须作为PerformanceResourceTiming对象包含在性能时间轴中。如果资源的定时允许检查算法失败，则其PerformanceResourceTiming对象的这些属性必须设置为零：redirectStart，redirectEnd，domainLookupStart，domainLookupEnd，connectStart，connectEnd，requestStart ，responseStart，secureConnectionStart，transferSize，encodedBodySize和decodedBodySize。
Timing-Allow-Origin 的“ Timing-Allow-Origin ”（Timing-Allow-Origin） HTTP响应标头字段可用于传达一个策略，该策略指示允许查看由于以下原因而原为零的属性值的起源跨域限制。标头的值由以下ABNF [RFC5234]表示（使用列表扩展[RFC7230]）：