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

Hi, Anderson,

   Please see comments inline.

On Fri, Jul 23, 2010 at 3:22 PM, Anderson Quach <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.

>
>
> 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] *On Behalf Of *Tony Gentilcore
> *Sent:* Thursday, July 15, 2010 5:38 PM
> *To:* 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>
> 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.
>
>
>