RE: Updates to Navigation Timing errata

A way extend this would be to keep track of DNS requests independently of nav timing. They could store when they were looked up (how long ago), how long they took to resolve, etc. Then, when Nav timing builds its metrics, it looks at which DNS entry it used to make the TCP request. It adds the data from the actual resolution for the host in DNS, even though it could have been seconds or minutes previous to the TCP connection and indicates that it was pulled from cache and how long it's been in cache.

A fresh link with nothing in the DNS cache would show in nav timing:
--looked up 0ms ago and 23ms to resolve the DNS.

A link to the same host clicked 7.2seconds later would show in nav timing:
--looked up 7200ms ago and 23ms to resolve the DNS.

The hoverover-to-fetch-dns would show some low millisecond's ago rate indicating that it was successfully prefetching items before a user actually had a chance to click. A bunch of 0 ago's would mean prefetching DNS isn't working.

Aaron


From: Arvind Jain [mailto:arvind@google.com]
Sent: Tuesday, May 14, 2013 10:14 AM
To: Boris Zbarsky
Cc: public-web-perf
Subject: Re: Updates to Navigation Timing errata

How should such cases be handled?

The DNS resolution, TCP connect, root page download (via prefetch hint) and entire page download (via prerender hint) can all start before actual user navigation and finish before or after navigationStart. In such cases, what should be the values for the different timing attributes in these cases?

Taking the example of DNS resolution, with a pre-resolve, the spec seems to state that domainLookupStart would be the time when the pre-resolve is actually started. But I think it makes more sense to talk in context of user navigation - a pre-resolve should be treated like a cache hit, so if a pre-resolve finished before navigationStart, we should report domainLookupStart and End == fetchStart.

What is your preference?

Arvind

On Tue, May 14, 2013 at 9:51 AM, Boris Zbarsky <bzbarsky@mit.edu<mailto:bzbarsky@mit.edu>> wrote:
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.

-Boris