- From: Jatinder Mann <jmann@microsoft.com>
- Date: Wed, 1 May 2013 18:20:17 +0000
- To: "'arvind@google.com'" <arvind@google.com>, "'public-web-perf@w3.org'" <public-web-perf@w3.org>
- Message-ID: <52b3bca7969948ccad408da60783c1c8@BLUPR03MB065.namprd03.prod.outlook.com>
I ran the same scenario in IE10 and got the following numbers, where navigationStart != fetchStart and navigationStart < redirectStart. Looks like Chrome and IE are behaving interoperably, but different from the navigationStart definition of "If there is no previous document, this attribute must return the same value as fetchStart". I recommend we update the Navigation Timing L1 definition of this attribute to reflect what browser vendors have implemented. navigationStart : 1367431805059, unloadEventStart : 1367431805059, unloadEventEnd : 1367431805059, redirectStart : 1367431805070, redirectEnd : 1367431806175, fetchStart : 1367431806175, domainLookupStart : 1367431806175, domainLookupEnd : 1367431806175, connectStart : 1367431806175, connectEnd : 1367431806175 domComplete : 1367431808769, domContentLoadedEventEnd : 1367431808675, domContentLoadedEventStart : 1367431808675, domInteractive : 1367431808675, domLoading : 1367431806872, loadEventEnd : 1367431808822, loadEventStart : 1367431808822, responseEnd : 1367431807018, responseStart : 1367431806872 Thanks, Jatinder From: Arvind Jain [mailto:arvind@google.com] Sent: Wednesday, May 1, 2013 10:23 AM To: Jatinder Mann Cc: public-web-perf Subject: Re: navigationStart in NavigationTiming I opened http://en.wikipedia.org link from http://www.wikipedia.org in Chrome using right click->open in new tab option and here is what I got: 1. connectEnd: 1367368521147 2. connectStart: 1367368521147 3. domComplete: 1367368522013 4. domContentLoadedEventEnd: 1367368521818 5. domContentLoadedEventStart: 1367368521818 6. domInteractive: 1367368521818 7. domLoading: 1367368521244 8. domainLookupEnd: 1367368521147 9. domainLookupStart: 1367368521147 10. fetchStart: 1367368521147 11. loadEventEnd: 1367368522016 12. loadEventStart: 1367368522013 13. navigationStart: 1367368521062 14. redirectEnd: 1367368521147 15. redirectStart: 1367368521062 16. requestStart: 1367368521149 17. responseEnd: 1367368521231 18. responseStart: 1367368521230 19. secureConnectionStart: 0 20. unloadEventEnd: 0 21. unloadEventStart: 0 As you can see, navigationStart != fetchStart and includes the redirect time, and redirect timings are not zeroed out. Arvind On Wed, May 1, 2013 at 9:54 AM, Arvind Jain <arvind@google.com<mailto:arvind@google.com>> wrote: Why are redirect timings zeroed out for this same origin redirect? On May 1, 2013 9:27 AM, "Jatinder Mann" <jmann@microsoft.com<mailto:jmann@microsoft.com>> wrote: Can you submit a test case? In this example, redirectStart and redirectEnd have been zero'd out. An example where they aren't zero'd out might be more helpful. Thanks, Jatinder From: Arvind Jain [mailto:arvind@google.com<mailto:arvind@google.com>] Sent: Tuesday, April 30, 2013 7:08 PM To: public-web-perf Subject: navigationStart in NavigationTiming I've a question about the definition of navigationStart in the specification (http://www.w3.org/TR/navigation-timing/#dom-performancetiming-navigationstart) It says: This attribute must return the time immediately after the user agent finishes prompting to unload<http://www.w3.org/TR/html5/browsers.html#prompt-to-unload-a-document> the previous document. If there is no previous document, this attribute must return the same value as fetchStart<http://www.w3.org/TR/navigation-timing/#dom-performancetiming-fetchstart>. The second part of this statement seems odd to me. In case the document in question has redirects (e.g. same origin redirects), the value of navigationStart will be very different if there was a previous document that had to be unloaded vs. not. The difference doesn't make sense. This line was added on Oct 14. 2010. There is one discussion a day before that http://lists.w3.org/Archives/Public/public-web-perf/2010Oct/0024.html which seems to have better text for this but the spec has something else. I think this inconsistency happened as we revised the definition of navigationStart, and we forgot to update the second part of the definition. I checked Chrome and it does the right thing - I load http://en.wikipedia.org/ in a new tab and it has a same origin redirect. navigationStart is not equal to fetchStart in this case, and in fact occurs before redirectStart which in my opinion is correct behavior. How do we fix this? Arvind
Received on Wednesday, 1 May 2013 18:21:10 UTC