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

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

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

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