Re: Completeness markers

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.

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