Hi, We're seeing infrequent cases where NavigationTiming timestamps such as requestStart and responseStart are happening prior to navigationStart. Here's one example: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/602.2.14 (KHTML, like Gecko) Version/10.0.1 Safari/602.2.14 navigation.type 0 // navigation redirectStart 0 redirectEnd 0 requestStart 1486654516288 // incorrect: before navigationStart responseStart 1486654516819 // incorrect: before navigationStart navigationStart 1486654517415 fetchStart 1486654517415 domainLookupStart 1486654517415 domainLookupEnd 1486654517415 connectStart 1486654517415 connectEnd 1486654517415 domLoading 1486654518045 responseEnd 1486654518085 domInteractive 1486654518312 domContentLoadedEventStart 1486654518312 domContentLoadedEventEnd 1486654518316 domComplete 1486654518596 loadEventStart 1486654518599 Here's a second example: Mozilla/5.0 (iPhone; CPU iPhone OS 10_2_1 like Mac OS X) AppleWebKit/602.4.6 (KHTML, like Gecko) Version/10.0 Mobile/14D27 Safari/602.1 navigation.type 0 // navigation redirectStart 0 redirectEnd 0 requestStart 1486647959659 // incorrect: before navigationStart navigationStart 1486647959737 fetchStart 1486647959737 domainLookupStart 1486647959737 domainLookupEnd 1486647959737 connectStart 1486647959737 connectEnd 1486647959737 responseStart 1486647959828 responseEnd 1486647959969 domLoading 1486647959971 domInteractive 1486647962594 domContentLoadedEventStart 1486647962710 domContentLoadedEventEnd 1486647962985 domComplete 1486647967189 loadEventStart 1486647967192 This doesn't happen frequently -- in one data set I'm looking at, it's 3 beacons out of 254,357.
Hi, We are seeing this in infrequent cases as well. We have also seen cases where responseEnd happens prior to responseStart and navigationStart, sometimes on the order of several seconds. Has there been any progress on this? Best, Brad