RE: [Web Timing] WebKit's planned processing model

Having the times at which the document.readyState is rather useful in terms of tuning and optimizing site performance. It helps to surface the time delay between scripts marked deferred / interactive state and when the document is consider complete.

With respect to document.readyState, to gain access to the times of each onreadystatechange transition, a developer would have to register the callback to record the timestamp per transition. Making the timestamps readily available in the performance.timing object would free her from having to register these callbacks.

Also, having this type of timing information easily accessible in the Navigation Timing interface, there's consistency and reduced overhead to get access to the readystate change times. All in all there the  benefits are:

i.                     completeness in the navigation timeline

ii.                   simplicity with accessing the timing information

iii.                  prevention of instrumentation based overhead for having the developer to register for these events herself.

In terms of mitigating the information disclosure attack surface, perhaps the best way to prevent this type of attack is not to provide the information in cross-domain scenarios. Where transitioning from abc.com --> xyz.com the unloadEventStart and unloadEventEnd is zeroed. Again the most valuable timestamp is the unloadEventEnd, an attacker can infer the start as the navigationStart.

Best Regards,
Anderson Quach
IE Program Manager


From: tonyg@google.com [mailto:tonyg@google.com] On Behalf Of Tony Gentilcore
Sent: Thursday, July 29, 2010 9:59 AM
To: Zhiheng Wang
Cc: Anderson Quach; public-web-perf@w3.org
Subject: Re: [Web Timing] WebKit's planned processing model


On Thu, Jul 29, 2010 at 1:10 AM, Zhiheng Wang <zhihengw@google.com<mailto:zhihengw@google.com>> wrote:

On Sun, Jul 25, 2010 at 11:04 AM, Zhiheng Wang <zhihengw@google.com<mailto:zhihengw@google.com>> wrote:
Hi, Anderson,
   Please see comments inline.
On Fri, Jul 23, 2010 at 3:22 PM, Anderson Quach <aquach@microsoft.com<mailto:aquach@microsoft.com>> wrote:
Zhiheng and Tony, thanks for getting together to update the Web Timing working draft. Here's some feedback Nic & I have with the July 21st 2010 version [1].

It would be pretty interesting to include markers that relate to document.readyState [2]. This will help site developers further understand what's happening during the navigation as the page is loading, including states like loading, interactive, and complete.
    Since developers already have convenient access to document.readyState right now, including
it in WebTiming seems to be something redundant.

   To clarify, I agree that having these times available in window.performance.timing provides easier access. Exposing
redundant data just makes me wonder.

   After some homework, I might have to take it back though. The current spec<http://www.w3.org/TR/html5/dom.html#resource-metadata-management> requires document.readyState to
offer "loading" and "complete" only, which seem to be what Chrome and FF are following.

In WebKit, the "interactive" ready state just isn't implemented yet (but it will be). Here's the definition of "interactive":
http://dev.w3.org/html5/spec/Overview.html#the-end

 IE have additional state values<http://msdn.microsoft.com/en-us/library/ms534359(VS.85).aspx>.
So here are some thoughts to share:
   * unintialized/loading - not much value to WebTiming IMHO.
   * interactive - this should be an interesting POI during a page load
   * loaded/complete - I am not sure exactly what is the difference in between. WebTiming already has onloadStart/onloadEnd
     so how much added value they have?

cheers,
Zhiheng




The suggested markers are:

*         domLoading

*         domInteractive

*         domContentLoaded

*         domComplete

In section 4.2 of the Web Timing draft [1]:

unloadEventEnd is defined as the timestamps which relates to the unloading of the last document. As the marker is named, you may have meant to be defined as the time immediately when the unload event of the previous document is complete.
   unloadEventEnd is meant for the time when the unloading document cleanup steps [1] are completed for
the browsing context of the previous navigation and its descendants browsing context. The unload event of the root
browsing context is fired before these steps.

  [1] http://www.w3.org/TR/html5/history.html#unloading-document-cleanup-steps


A suggestion, how about  complementing unloadEventEnd with unloadEventStart.
  This is something we should have further discussion over. As we discuss, exposing both
Start and End of the unload process reveals some information on the previous page's unload
event handling. Combining with the referrer, it causes some privacy concern.

  This is a topic of the ongoing security review of the draft here. What are the thoughts from others?

redirectEnd for clarity, the recommendation here is to be more explicit about the time maker for the last redirected navigation. E.g. If the last navigation is a redirection, this attribute must return the number of milliseconds between midnight of January 1, 1970 (UTC) and the time when the last redirected navigation ends.
   Here is the current definition:
  "If the last navigation is a redirection, this attribute must return the number of milliseconds between midnight of January 1, 1970 (UTC) and the
time when the last navigation ends. If the last navigation is not a redirect, this attribute must return zero."
   It looks the same to me?



Within the NavigationInfo interface, to be consistent, the suggestion here is to use the lower case type, rather than the capitalized Type. This may have been a typo.
   Right, I've changed it to navigation.type.


The code sample for NavigationInfo has a few code snippet errors.

var t = performance.timing;
if (t.timing.navigationEnd > 0) {
  var page_load_time = t.timing.navigationEnd - t.timing.navigationStart;
  if (t.navigation.Type == t.navigation.TYPE_LINK) {
  alert (page_load_time);
}

Should be:

var t = performance.timing;

if (t.timing.navigationEnd > 0) {

  var page_load_time = t.timing.navigationEnd - t.timing.navigationStart;

  if (performance.navigation.type == performance.navigation.TYPE_NAVIGATE) {

  alert (page_load_time);

}


   Thanks for catching this. Fixed.


In the code example, you make mention of navigationEnd which is not defined in the document. The feedback here is that, it's a great complement to navigationStart to denote the logical start and end of the navigation phase. Just thinking about how a site developer would intuitively think about the timeline, having a navigationStart paired with a navigationEnd along with a fetchStart and fetchEnd would help bring clarity to the phases of loading the root document.  Where, navigationEnd corresponds with loadEventEnd and fetchEnd with responseEnd. Thoughts?
    In longer term, having two distinct variables referring to the same value soundslike a good way
to get developers confused. :-) Just my $0.02.

thanks,
Zhiheng




[1] Web Timing http://dev.w3.org/2006/webapi/WebTiming/
[2] Resource metadata management http://www.w3.org/TR/html5/dom.html#resource-metadata-management

Anderson Quach
IE Program Manager

From: public-web-perf-request@w3.org<mailto:public-web-perf-request@w3.org> [mailto:public-web-perf-request@w3.org<mailto:public-web-perf-request@w3.org>] On Behalf Of Tony Gentilcore
Sent: Thursday, July 15, 2010 5:38 PM
To: public-web-perf@w3.org<mailto:public-web-perf@w3.org>
Subject: Re: [Web Timing] WebKit's planned processing model

I made two updates to my description of WebKit's processing model:
1. domainLookupStart, domainLookupEnd, connectStart, and connectEnd are now "backfilled" when they would have previously returned 0.
2. Nic Jansma uncovered a bug. In 3.10.b, redirect-start should be set only if it is currently 0.

Here is the live link. Revision history is at the bottom.
https://docs.google.com/document/edit?id=1rZQ_XaiEwb4OL62DGHXY1Ktzk7PhgkHTYlzpnZEeYKw
On Tue, Jul 13, 2010 at 1:52 PM, Tony Gentilcore <tonyg@chromium.org<mailto:tonyg@chromium.org>> wrote:
Attached[1] is my plan for the processing model of WebKit's initial window.webkitPerformance implementation.

I'm hoping its detailed language will be useful in informing the working draft specification<http://dev.w3.org/2006/webapi/WebTiming/>. I'm also very interested to make sure this lines up with the IE9 and Mozilla implementation plans. All feedback appreciated.

Tony

[1] HTML exported from Google Docs. Let me know if you'd like me to share the original.