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

On Sun, Jul 25, 2010 at 11:04 AM, Zhiheng Wang <zhihengw@google.com> wrote:

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

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