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

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

Received on Thursday, 11 October 2012 15:19:51 UTC