Re: Updates to Navigation Timing errata

We should check what the implementations are doing (when they pre-resolve
or pre-connect) and report here. Our intention with the spec was to report
the user perceived latency, and therefore report time it took in the
critical path for various operations. The spec is not very clear on this,
and I'll edit it to make things more clear.

Boris, with this being our intention, does the illustration still concern
you?

Mike, independently, we should tackle the issue you mention (for next
version) - on how to report actual times for the DNS and TCP operations in
case of a pre-resolve/pre-connect.

Arvind


On Tue, May 14, 2013 at 10:36 AM, McCall, Mike <mmccall@akamai.com> wrote:

>
> On 5/14/13 1:13 PM, "Arvind Jain" <arvind@google.com> wrote:
>
> >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.
>
> I don't like the idea of treating a pre-resolve as a cache hit.  Having a
> domainLookupStart/End == fetchStart in a pre-resolve makes it useless as a
> metric as browsers become more aggressive about pre-resolving hostnames.
> If you're a site owner and interested in your DNS provider's real-world
> performance, having the browser effectively zero it out for a pre-resolve
> means you're missing out on hostname resolutions that occurred for your
> site as a user was navigating to it.  I'd want to know about this stuff
> irrespective of whether or not it was perceived by the user.  The same
> goes for TCP connections.
>
> Mike
>
>