- From: McCall, Mike <mmccall@akamai.com>
- Date: Thu, 11 Oct 2012 11:19:10 -0400
- To: "Reitbauer, Alois" <Alois.Reitbauer@compuware.com>
- CC: "public-web-perf@w3.org" <public-web-perf@w3.org>
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