RE: [Web Timing] Getting root timings to recommendation

The definition for requestEnd may need some more specificity, the spec currently states "the time when the user agent finishes requesting the current document from the server". Here are a few approaches to how request end can be interpreted.


*         When the browser has finished generating its request (often, building a memory buffer) that it hands off to the network API. If so, this time will be very close to 0.

*         When the network API is done constructing its last buffer to be sent over TCP. Some browsers may not have insight into this and lower levels.

*         When the TCP layer has send out its last packet to the server.

*         When the server receives the last packet.

Nic and I recommend defining requestEnd as "the point the browser receives the first byte from the server", we maintain a browser-centric POV that is well-defined and the easiest implementable solution by all user agents.

Defining it as such would also remove the large, very important gap of waiting on the server.

It would be great to get the perspective from Mozilla and Opera on the request and response phase.

Anderson Quach
IE Program Manager


From: Nic Jansma
Sent: Thursday, August 19, 2010 1:59 PM
To: Tony Gentilcore; Anderson Quach
Cc: Zhiheng Wang; public-web-perf@w3.org
Subject: RE: [Web Timing] Getting root timings to recommendation

Thanks Tony.  IE Platform Preview's implementation of requestEnd being the time of first byte of the webserver's response was implemented to align with our F12 Developer Tools, which describe the "Request" time as "Time to first byte. The time taken to send the request and receive the first response from the server.".

My concern with changing the definition of requestEnd to be the time that the user agent finishes sending the request (and not including the time waiting on the webserver) is that it then creates an undefined region between requestEnd and responseStart that encompasses both a significant and important period of a web request - waiting on the server.  I realize we have other potential undefined regions (delays from proxy determination, etc.), but the "waiting on server" period is a very important one and I'm afraid if we don't explicitly put it in an existing timeframe or make a new period for it, web developers who are unfamiliar with the interface may be confused by the large undefined region.

Additionally, from an implementation perspective, I suspect that if we define the "request" phase as the time it takes to send data to the server and not time waiting for the first byte, the "request" phase will generally be 0 in most cases.  Most requests will be able to be sent in a few packets and (depending on the user agent and OS platform) the entire process may be abstracted away at a lower level where the user agent may not be specifically told of the transition between sending the request and waiting for the server's response.  For example, in IE/Windows, IE notifies the networking subsystem of the request/headers/payload and doesn't get a specific notification of the transition between sending the request bytes and are waiting on a response.

I would suggest one of two solutions to this:

1.       Define requestEnd to be the time of the first byte of the server's response.  Thus the "request" period includes sending the request and waiting for the initial response from the server.

2.       Define requestEnd to be the time of the last byte sent to the server, and add two new timestamps "waitingForServerStart" and "waitingForServerEnd" (or something similar) to explicitly call out that region.

- Nic

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

Thanks for the updates.

Leaving mark/measure/fullyLoaded for our next conversation, the only question I still have is about the definition of requestEnd. The IE platform preview sets it at a later point than the draft and Chrome 6.

Everything else looks good to me.

-Tony
On Wed, Aug 18, 2010 at 5:03 PM, Anderson Quach <aquach@microsoft.com<mailto:aquach@microsoft.com>> wrote:

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> [mailto: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<mailto: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