W3C home > Mailing lists > Public > public-web-perf@w3.org > December 2012

Re: Proposed new test for Navigation Timing: Monolitic Clock

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 13 Dec 2012 18:29:42 -0500
Message-ID: <50CA64E6.2020800@mit.edu>
To: Philippe Le Hegaret <plh@w3.org>
CC: public-web-perf@w3.org
On 12/13/12 5:25 PM, Philippe Le Hegaret wrote:
> Correct. I'm simply waiting for Jatinder to confirm that I need to
> remove it. I'll ask him for domainLookupStart and DNS prefetchers as
> well.

Thanks!

One other note here.  The spec currently says:

   fetchStart must return the time immediately before the user agent
   starts checking any relevant application caches.

At least in Gecko right now, we'll kick off a DNS lookup, and if that 
returns quickly enough a TCP connection before we start looking at 
caches.  So I believe in Gecko it's actually possible for not only 
domainLookupStart to come before fetchStart, but for connectStart to 
come before fetchStart, at least as fetchStart is currently defined in 
the spec.  I have no faith that what we actually do for fetchStart is 
what the spec says; I suspect we set it much earlier, when we start 
actually doing things for the fetch.

In general, the wording in the spec seems to assume that the UA serially 
does things like application caches, DNS, connection attempts, etc 
whereas UAs are likely to parallelize all that stuff (for example, doing 
a speculative preconnect to a cached but stale DNS entry while at the 
same time doing a DNS lookup to verify that the entry is still valid; 
that's a scenario in which connectStart can come before domainLookupEnd)....

> It may well be that, at the end, not much is left in the test to make it
> interesting enough...

That's possible.  I'm more worried about whether the spec is making 
assumptions about ordering that just aren't true anymore....

-Boris
Received on Thursday, 13 December 2012 23:30:11 UTC

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