RE: [Web Timing] Getting root timings to recommendation

One observation on having explicit domLoading and domComplete marks:  Here's a snippet of an observed page load in IE9 PP4, showing that domComplete != loadEventStart and responseEnd != domLoading, though they are very close (1-3ms off).

[Description: cid:image001.png@01CB3EC2.EE23EB20]

- Nic

From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Anderson Quach
Sent: Wednesday, August 18, 2010 5:04 PM
To: Zhiheng Wang; Tony Gentilcore
Cc: public-web-perf@w3.org
Subject: RE: [Web Timing] Getting root timings to recommendation


Hi Tony and Zhiheng,

This is a great discussion here. Here are thoughts from Nic and I.

It's really important that we keep the normative requirements in both definition and the processing model free from any inconsistencies and ambiguity. I'm presuming you folks are talking about the differences in section 4.2 The NavigationTiming Interface and section 4.5 Processing Model of the Aug 17 working draft [1].

There's a slight typo in section 4.3 NavigationInfo, the "attribute read only attribute unsigned short type" is capitalized.

In section 4.4 window.performance.timing, the sample code use a NavigationInfo.type that does not exist and a  close parenthesis is missing from the if statement block.

In terms of navigationStart, it is the intention to begin immediately after the onbeforeunload.

As for the markers related to the document load and unload. It's our recommendation to be more explicit about the naming. Currently this is not updated in the fourth IE platform preview, but it is our intention to update this as soon as possible.

With the DOM events implemented in the platform preview, the time at which the DOM readystate transitions to loading can be unique from responseEnd, and with the readystate transitions to complete can be unique from loadEventStart.  For consistency and completeness, we would recommend the standardization of the following markers as it relates to HTML5: domLoading, domInteractive, domContentLoaded and domComplete.

We share the same concerns with respect to the ability to standardize the results for firstPaint. All user agents will do different amount of work in their first paint. I'd recommend either making it a non-normative requirement, or perhaps not introducing it in the NavigationTiming interface.

The intention for fullyLoaded is for the site developer to capture when they declare the page and their content is finished loaded. This can be marked by the site developer and can be long after loadEventEnd has completed.  This marker however, is best discussed  in the context of User Timings.

Timing measures allow for site developers to easily and compactly grab the time phases within the timeline. The idea here is to enable access to the overall time it took to navigate, time phases associated with fetching the document and the time phases associated with loading the document in the browser.

Best Regards,
Anderson Quach
IE Program Manager

[1] http://dev.w3.org/2006/webapi/WebTiming/

From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Zhiheng Wang
Sent: Tuesday, August 17, 2010 2:19 PM
To: Tony Gentilcore
Cc: public-web-perf@w3.org
Subject: Re: [Web Timing] Getting root timings to recommendation

     This is extremely helpful. Thanks, Tony. Please find comments inline.
On Mon, Aug 16, 2010 at 11:08 AM, Tony Gentilcore <tonyg@google.com<mailto:tonyg@google.com>> wrote:
Chrome 7 and the IE9 beta are drawing near. While aggressive, it might be possible to push to get the Web Timing spec [1] into a recommended state by then so that we can drop the vendor prefixes for those releases.

    Agree we should moving towards removing the vendor prefixes. As we discussed out of this thread, fortunately, advancing the draft to recommendation doesn't necessarily
block us from doing it (at least for Chrome). :-)


I've surveyed the spec and the two implementations and prepared a summary [2] of the remaining differences. The left most column lists an event or step in the whatwg HTML5 spec. The next four columns list how the two spec sections and two implementations label that step. My editorials are on the right summarizing the differences.

Some high level thoughts:
1. The spec has normative requirements in both 4.2 and 4.4. This introduces the possibility that the spec is internally inconsistent (or at best redundant). My preference would be for 4.4 to be normative and 4.2 to be rephrased as non-normative notes.

    I would keep both normative when eliminating any inconsistency and redundancy (if any). And if one of them has to be relaxed, it should
be 4.5 (processing model) IMO. Definition is what keep the attributes consistent across user agents.

2. The spec could use a careful editorial pass to clean up typos, apply some formatting to 4.4, and link up more definitions.

    Agree. I will take care of them.

3. Resource timing needs to be split into another document.

    Done in the latest updates. ResourceTiming is now under http://dev.w3.org/2006/webapi/ResourceTiming/
I will send out more notes when I add a couple more points into it.

4. In terms of the actual implementations, there are only very minor differences. I think this is all:
  1. We are pretty close on navigationStart, but we need to be specific about beforeunload.

    While having it up in the draft for easy discussion, I incline to remove unloadStart. Security triumphs. That said, I would really like
to see more feedback from others about this particular issue.


  2. [un]loadEvent[Start,End] vs. [un]load[Start,End].
  3. requestEnd is marked differently.
  4. dom*, firstPaint, fullyLoaded timings should either be put in the spec or prefixed w/ ms.

All of this only pertains to window.performance.timing. We probably need to talk about navigation, timingMeasures, and the new Mark/Measure APIs.

    I believe the new Mark API falls into the UserTiming space? (http://www..w3.org/2010/08/webperf.html)

thanks,
Zhiheng




-Tony

[1] http://dev.w3.org/2006/webapi/WebTiming/
[2] https://spreadsheets.google.com/ccc?key=0AvEMl2LYkOQ5dGRLV3Nxc0lCQk0xNTNYRFBFRHlUWXc