RE: Updates to Navigation Timing errata

Hmmm...while this may be true for the overall page composition/loading process, for any given resource, the steps will occur in this deterministic order, with a DNS resolution step preceding an attempt to establish a TCP, etc. It's interesting that the UA may do speculative lookups but it doesn't change the sequence of steps required for an object to be requested and a response returned via HTTP. It's safe to say that a DNS resolution step will always precede the TCP step etc, even if these steps are performed out of order or speculatively.

Even 'speculative preconnects' require a DNS resolution step (which may be local, from the system cache or even /etc/hosts). 

If the UA performs speculative lookups for objects not retrieved, say on mouseover(), do these time segments show up in our results, even if the object is never requested? IMHO, they should.



-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 
Sent: Tuesday, May 14, 2013 9:52 AM
Subject: Re: Updates to Navigation Timing errata

On 5/14/13 10:49 AM, Philippe Le Hegaret wrote:
> It includes two errata, one regarding the navgiationStart attribute, 
> and one regarding the illustration in 5.1 Processing Model.

I hate sounding like a broken record, but this is still assuming a model in which "TCP" comes after "DNS" and "DNS" comes after "Prompt for Unload".

In actual browsers, "DNS" can happen when the user hovers over the link that they will click to leave the page (before "Prompt for unload") and "TCP" can start before "DNS" completes due to speculative preconnects....

As a result, a browser implementing this specification right now has the choice of either not following the spec or reporting numbers that don't reflect what it actually did.  In practice I believe at least Gecko ends up doing a mix of the two depending on where people remembered to put in random max() or min() calls; I can't speak to other browsers.


Received on Tuesday, 14 May 2013 17:13:49 UTC