W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2013

RE: navigationStart in NavigationTiming

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:35 UTC