- From: Arvind Jain <arvind@google.com>
- Date: Wed, 1 May 2013 10:23:01 -0700
- To: Jatinder Mann <jmann@microsoft.com>
- Cc: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAOYaDdONvNYt0FoDAaAYL5_TE-5u6-f-d8bBsTJSzvLfnOqmAw@mail.gmail.com>
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> wrote: > Why are redirect timings zeroed out for this same origin redirect? > On May 1, 2013 9:27 AM, "Jatinder Mann" <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] >> *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 17:23:29 UTC