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

On 10/11/12 5:19 PM, "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.

[Alois] You could also use the NavTiming 1 values for this :-). Maybe the
first timestamp could also be represented as an absolute value.


>
>
>>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. :)

[Alois] Ok, so a discussion about other useful lifecycle metrics that are
more related to the end user make sense. I think there is more than first
paint then, however.

>
>>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.

[Alois] I think the value of this "something" should be verified across a
huge number of pages. I know that tools try to optimize this, but what if
it is a blank screen. What I saw people doing is defining which parts of
the document have to be loaded so that the page can be considered
"visible" for the user.

>
>>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?

[Alois] Would be worth another discussion. I think this is about other
JavaScript from widgets that could also figure out if you have been to a
site before.

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

Received on Thursday, 11 October 2012 18:44:58 UTC