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

A couple of comments:

Navigation Start and Clock Sync:

You should not use the clock time of a machine to sync with your server
clock directly. Having worked a lot with clock time in distributed systems
I know this rarely works. You would rather use explicit clock
synchronization. Otherwise you will go wrong in many cases.

First Paint/Pixel:

There was already a lot of discussion about this. My question is what does
this value tell you? It might be just a white screen being shown. Define
when a page is visually done is a long discussion in Web performance.
While there are different approaches there is no perfect solution to this.
It always depends on what needs to be shown to the user so he perceives
the page as complete. 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.

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.

// Alois



On 10/9/12 9:22 PM, "McCall, Mike" <mmccall@akamai.com> wrote:

>Hi web-perf,
>
>I just wanted to give some feedback on the Navigation Timing 2 draft.
>After reading the spec, it appears that a big change has been made to the
>interface and how it reports timestamps.  In particular, it looks like
>navigationStart will always be 0.000, and everything will be reported as a
>delta from that time.  If this is in fact, correct, then I am concerned
>that by not having an absolute timestamp available, it will be difficult
>to correlate Navigation Timing measurements with backend logs, which can
>be useful for postmortem debugging.  Perhaps an additional attribute could
>be added, 'navigationStartTimeStamp' for example, which would contain the
>epoch time of navigationStart.  To be clear, I don't think we need an
>epoch timestamp for every attribute, but knowing the timestamp from which
>the measurements are based would be useful.
>
>Also, I noticed that the concept of first paint/pixel is omitted in this
>draft.  While IE supports it with a vendor prefix, and Chrome exposes it
>through their window.chrome.loadTimes() object (not sure if other browsers
>expose it), it would be good if it were included as part of the official
>spec so there was a browser-independent place to gather this data.  Some
>3rd-party testing vendors including webpagetest.org, report some concept
>of the time the browser began rendering the page, and I think it would be
>valuable here too.
>
>Finally, based only on the spec, it seems difficult to determine whether
>or not the document was retrieved from cache or not.  Is it possible to
>determine that a document was not downloaded from the server, but
>retrieved from cache, via the Navigation Timing API?  If not, would a
>'fetchType' attribute be useful here?
>
>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 08:05:48 UTC