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

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> wrote:

>
> On 10/11/12 4:05 AM, "Reitbauer, Alois" <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
>
>
>