Re: [NavigationTiming2] Comments and questions about the Navigation Timing 2 draft

What about adding work on a document that defines best practices for page analysis. It will not be a standard per se but will be good guidance to Web site owner on how to monitor and optimize their Web pages. I am convinced that such a document would be highly appreciate by the development community.

// Alois

From: Ilya Grigorik <igrigorik@google.com<mailto:igrigorik@google.com>>
Date: Thursday, October 11, 2012 7:15 PM
To: "McCall, Mike" <mmccall@akamai.com<mailto:mmccall@akamai.com>>
Cc: Alois Reitbauer <alois.reitbauer@compuware.com<mailto:alois.reitbauer@compuware.com>>, "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Subject: Re: [NavigationTiming2] Comments and questions about the Navigation Timing 2 draft
Resent-From: Alois Reitbauer <alois.reitbauer@dynatrace.com<mailto:alois.reitbauer@dynatrace.com>>, "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Resent-Date: Thursday, October 11, 2012 7:16 PM

re: why do we want this value?

First of all, I agree that the "first paint" is a highly contextual metric - for one page, that may mean that the user can start reading the content, for another it may mean an empty pixel on the screen. Having said, this is no different from TTFB: one site can flush a segment which can tip off the parser to start scheduling all the critical resources, and another site can ship a segment of entirely useless data. Same argument applies for DCL and others.

Having said that, I do think it is a useful metric and one that can enable site owners to better optimize their resource loading: removing blocking scripts, re-ordering CSS / JS, etc. There is a world of a difference, when it comes to UX, between a page that paints the content to the screen 0.5s in, and progressively fills in the content over next 3 seconds, and a page that displays a blank screen for 3.5s and then flushes the entire page to the screen.

WebPageTest has been experimenting with "Visual Speed Index", which tries to address the larger problem of quantifying the visual performance of a page: https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index. However, it's definitely much more complex, and I don't think we're 100% happy with how its defined either (yet).. I don't think we need to go that far in NavTiming.

TL;DR: In my opinion, time to first paint is definitely more than a "feel good" metric. In fact, it is something we want to highlight to site owners and developers and get them thinking about.

ig


On Thu, Oct 11, 2012 at 8:19 AM, McCall, Mike <mmccall@akamai.com<mailto:mmccall@akamai.com>> wrote:

On 10/11/12 4:05 AM, "Reitbauer, Alois" <Alois.Reitbauer@compuware.com<mailto:Alois.Reitbauer@compuware.com>>
wrote:

>Navigation Start and Clock Sync:
>
>You should not use the clock time of a machine to sync with your server
>clock directly.

I agree that it's not wise to rely on a client's clock being in sync with
the server's, but for the purposes of post-mortem analysis, not having a
timestamp when a Navigation Timing measurement was taken is worse than a
slightly (or perhaps in the odd case, wholly) incorrect one. I would
imagine that one of the primary use cases of Navigation Timing is to
collect and beacon the data back to a central server for analysis.  Being
able to correlate, however roughly, when the server interacted with the
client is a good thing in my opinion.


>First Paint/Pixel:
>
>There was already a lot of discussion about this. My question is what does
>this value tell you?

I am actually rather intrigued by the amount of discussion this has
caused, and thank Boris, Ilya, and you for enlightening me on the subject.
 As Ilya pointed out, I fall into the large category of people who
consider firstPaint to be when "the user sees something".  It's true that
hardware capabilities may stand in the way of getting an exact value of
this, but at least understanding when the user agent /told/ the hardware
to start painting is a good start.  We can work on instrumenting hardware
in NavTiming 3. :)

>This is highly specific to the actual page. I
>personally work a lot with ResponseStart (First Byte Time - kind of),
>DocumentContentLoaded (all html is there) and DomComplete (all dom
>elements loaded). This combination tells me a lot of the lifecycle of the
>page.

This is true, and this level of insight into the document's lifecycle is
amazing.  However, understanding when the user saw something gives an even
clearer picture of the document's lifecycle, since there are many things
that may slow down or interrupt the processing of the DOM throughout the
domLoading->domInteractive->domContentLoaded->domComplete chain.  In
addition, many front-end optimization techniques actively try to improve
the time to a user "seeing something", and being able to quantify that for
real users is valuable.

>Caching Information:
>
>This would in fact be cool information. The reason this was dropped was
>because of privacy reasons. However calculating ResponseStart -
>RequestStart should do the trick.

I suppose I understand the privacy concern from a Resource Timing
perspective, but I don't necessarily understand it here, especially since
it can be inferred.  Can someone explain?

Mike



The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Austria whose registered office is at 1120 Wien, Wagenseilgasse 14, Austria