Web Performance Working Group Teleconference

October f2f meeting planning

Arvind: End of week, meeting in mountain view, date 10/5/2010, from noon to 5pm.

plh: may not be able to come for a subsequent 5hr meeting in Moutain View

Arvind: keep the 12-5 for the first f2f, get agenda set by next week
... if we have enough items on the agenda extend the meeting to all day
... block out rooms at google for the entire day

Anderson: sounds great

Arvind: plh do you have advice to set the agenda?
... already have the basic agenda to discuss the three specs

plh: we should discuss testing as well

Arvind: place to add agenda?

plh: can send agenda items to the mailing list

Arvind: mailing list is sufficient, with a link to a document

Anderson: comfortable with establishing the agenda over email, low overhead

Arvind: send an email to add to the list

TPAC f2f

plh: got lucky we got room, monday and tuesday

plh, nov 1st and nov 2nd, web apps working group will be meeting at the same time, one other thing, there is a fee to cover the costs. for each attendee register before oct 22nd

plh: fee after 10/22 is dramatically increased, costs rise for late

Arvind: potentially meet with the web apps working group at tpac
... ask them for a slot to present

plh: everyone in the same room for a technical plannery day

Arvind: send email to web app chairs

<plh> see http://www.w3.org/Member/Mail/ for contact information

Anderson: send feedback to the email list for agenda items and goals for meeting in tpac before committing to attending

plh: one goal that can be satisfied with tpac is establishing test cases

Arvind: let's establish the agenda through the email list for tpac and the f2f in mountain view
... let's get to item to 1 and 2
... let's start with the next set of items

processing Model, requestEnd and responseStart

Anderson: analyzed phases with tools
... look at it from the wire or the browser

Tony: some things are not present from the browser perspective, do we consider, browser phase or network stack
... maybe answer is both, sending phase, network view, request phase from the browser view
... the way the spec in webkit, reflects network view, the actual sending of data, as opposed to time to get back

Anderson: the phases are broken down into browser work, sending request, waiting for server, first byte

Steve: browsers may be downloading of resources before added to the dom, i can look at firebug netpanel and other tools and see when the request was sent over the wire
... do not lose this ability in the web timing spec, as a web developer i have no ability to measure how long it too on the network to download the jscript file
... lump together may lose this interesting data

Nic: this conversation is intended to cover, the requestEnd phase in the IE implementation the point that we get the first byte back from the server, the webkit implementation is the browser has sent the request from the browser.
... approach taken was that from the user agent point of view, there is a consistent story across user agents.
... concern with perspective of sending the bytes to the server, some user agents sit on an abstraction of the network layer.
... in IE, sits on the abstraction of browser, wininet, tcp. the browser may not have insight into the lower layers.
... difference between the browser queuing the payload from when it actually was sent out.
... responseStart is not the time the server sends the response, it's the time the first byte was received in the browser. we are flexible for input.
... we want to make sure we can satisify the requirements as stated in the spec and is consistent in user agents.

Steve: is there something in the spec that defines the requestEnd, when you're done with sending and receiving.

Nic: definition in spec: time user agent finishes request the current document from the server.

Tony: good time to have zhiheng on the call.
... get unique datapoint with different data point between requestEnd and responseStart, capture that the user agent spends time uploading.
... not arguing one or another, key point to note here, is it important to measure time spent uploading request. okay with the phase with get me this, i got something back from the server.

Anderson: request phase can encapsulate a large upload. it captures a large upload and a long latency

Tony: Chrome network stack is re-written for multiple platform capability.
... usually from the browser perspective, there is no insight, if this is something to be difficult to implement, be interested to hear Mozilla's take. maybe it's nto worth breaking out sending and waiting for server., be interesting to hear mozilla's thoughts and zhiheng's thought.
... more parties need input here.

Anderson: value input from other user agents on this matter.

plh: can send emails to mozilla and apple if it helps?

Anderson: absolutely

Arvind: let's do that.

<plh> ACTION: plh to reach out to Mozilla and Apple [recorded in http://www.w3.org/2010/09/15-webperf-minutes.html#action01]

<trackbot> Created ACTION-4 - Reach out to Mozilla and Apple [on Philippe Le Hégaret - due 2010-09-22].

the addition of requestCount and uniqueDomains

Arvind: next item is addtion of requestCount and uniqueDomains

Anderson: was introduced in the 3rd platform preview, we would like feedback.
... provided to give top level information about the navigation, to decribe dynamically generated pages, show total requests and show number of domain name lookups

Tony: in absence of resource timing, may not be necessary and duplicate resource timing. resource timing is going to be a large topic, there's a lot of hard issues there.
... maybe it is useful to have something on the root document to expose these.

Arvind: is there ambiguity how to compute requestCount and uniqueDomains.

Tony: need a point where these are lock down, such as the point of loadEventEnd, or some point in the document, in the case of dynamic additions of resources to the document.
... Can you desribe how it works in IE?

Nic: requestCount as we've talking about is the count of scripts, images, css, objects, and iframes/subdocs.
... in our implementation there is no end point, it continuously updates. the requestCount will continue to increment.
... similar to uniqueDomains, root document domain + unique domain, we increment domains.
... added from feedback from web properties. this helps site developers gives a characteristic of the page load.

Tony: these don't peer into subframes.

Nic: yes

Tony: if i have a resource in a redirect, it's only one request. i do like them, they may be redudant to resource timing.

Nic: good point.

Arvind: decide to include them or not?

Tony: present to Zhiheng, i have no problems adding them to webkit if they are in the spec.

Arvind: cover that next week.
... last item for today start discussion on resource timing and user timing.

start Resource Timing and User Timing discussions

Anderson: want to cover the scenarios to cover in resource timing, i. access to resource timing, ii. access to resource timing from resources that have a different origin from the root document. With the constraint of not disclosing browser history to an attacker.

Arvind: can you put this on the email list?

Anderson: Yes.

Arvind: no items left.

Anderson: We've covered all topics.

Arvind: let's adjourn.