Re: Completeness markers

On Tue, Dec 14, 2010 at 3:10 PM, Zhiheng Wang <zhihengw@google.com> wrote:

> Hi, Tony,
>
>    Please find comments inline.
>
> On Mon, Dec 13, 2010 at 3:06 PM, Tony Gentilcore <tonyg@google.com> wrote:
>
>> James and I took a step back today to look at the completeness markers.
>> Now that things have settled down, we'd like to double check that we are
>> really happy with how they turned out.
>>
>> We have:
>> *domInteractive* Marks completion of parsing. This means that the root
>> document has been fully received, all HTML has been parsed and all
>> synchronous (inline and external) scripts have been executed.
>> *domContentLoadedEventStart* Marks just before the DOMContentLoaded event
>> is fired. In addition to the above, deferred scripts have now been executed.
>> *domContentLoadedEventEnd* Marks just after the DOMContentLoaded event,
>> including time spent in any event handlers.
>> *domComplete* Marks completion of the document. In addition to the above,
>> async scripts have now been executed and all subresource loads have
>> completed.
>> *loadEventStart* Identical to domComplete.
>> *loadEventEnd* Like loadEventStart, but includes time spent in load event
>> handlers.
>>
>>
>      These look great.
>
>
>
>>  While we realize that different markers might be important to different
>> pages, it seems a bit hard to justify 6 markers. Some observations:
>>
>> 1. All of these metrics can be gathered without Navigation Timing by
>> listening to onreadystatechange, ondomcontentloaded and onload. So we are
>> just offering them for ease of access and lazy loaded scripts.
>>
>
>     agree.
>
>
>> 2. domComplete is identical to loadEventStart. Perhaps we should kill
>> domComplete like we killed requestEnd (which was identical to
>> responseStart). We talked about completeness of all ready state change
>> events, but is that really a good argument to expose an identical marker?
>>
>
>     It's redundant right now. Though other than "completeness", one could
> also argue there two are distinct events in
> browser processing and it's possible that their timing gets to be different
> in the future. In short, I am neutral and would
> like to hear what others say. :-)
>
>
>> 3. loadEventEnd and domContentLoadedEventEnd probably aren't too useful.
>> The *EventStart markers are useful because if a page doesn't have event
>> handlers for those events, they can still get the time without listening.
>> But by definition, if the *EventEnd markers are different from start, the
>> page did some work in the handler and could have easily marked a completion
>> time (either using Date() or the forthcoming User Timing). Perhaps we should
>> kill these two end metrics before we set a precedent that every event we
>> measure will have both start and end markers (which could be expensive for
>> Resource Timing). Note that unloadEventStart/End still makes sense since the
>> page could not have timed that event.
>>
>
>    These two *End events are still interesting given many pages have
> heavily relied on these load
> events. Even though developers can now use onload event handlers, some 3rd
> party snippets can
> chain up the existing onload event handler and put its own at the end. In
> that case, the measurement
> could not be sure it's the last one to be handled.
>

Multiple handlers is an interesting use-case I hadn't thought of. If that's
common, it would be a good argument to keep end events. In any case, I'm
interested to hear thoughts from the IE folks.


>
>    I do feel a bit itchy about loadEventEnd, mostly because I imagine the
> most common use case for developers
> is to collect timing information using onload handler. In that case,
> loadEventEnd is not (yet) available. unload
> handler is better here but it seems to be a less reliable approach.
>
> cheers,
> Zhiheng
>
>
>
>>
>> To summarize, we think trimming down to these 3 would make the interface
>> easier to learn and use without sacrificing any information:
>> *domInteractive *Immediately before readyState transitions to interactive
>> *domContentLoadedEvent* Immediately before the DOMContentLoaded event is
>> fired
>> *loadEvent* Immediately before the window's load event is fired
>> *
>> *
>> We'd like to consider this only if it won't put the IE9 implementation at
>> risk. Thoughts?
>>
>> -James,Tony
>>
>>
>