[minutes] 20100922 Web Performance

Available at
http://www.w3.org/2010/09/22-webperf-minutes.html

Web Performance Working Group Teleconference
22 Sep 2010
See also: IRC log
http://www.w3.org/2010/09/22-webperf-irc


Attendees
Present
  SteveSouders, Tony, Zhiheng, NicJansma, AndersonQuach
Regrets
  plh, Arvind, JasonWeber
Chair
  Arvind
Scribe
  AndersonQuach
Contents

Topics

1.       Follow-up on feedback on requestCount and uniqueDomains attributes.

2.       Follow-up on feedback on requestEnd and responseStart.

3.       The lifetime management of the navigation timing. What timing should be accessible at which phase of the document loading.

4.       Resource Timing scenarios.

5.       User Timings scenarios.

6.       F2F meeting updates.

7.       TPAC meeting updates.

8.       Any other business.

Summary of Action Items

Anderson will create a draft of user timings.
Zhiheng will update requestEnd in navigation timing.

--------------------------------------------------------------------------------



<scribe> chair: "JasonWeber"

agenda

list the agenda

Zhiheng: not sure if it is useful, I do not have a preference either way

NicJansma: thoughts about additional helper metrics for navigation timing?

Zhiheng: the value of the two attributes is marginal value

SteveSouders: why not lump it in now, it makes sense to have it in navigation timing, it's a state not specific about any resources, it's a stat about the overall page
... if i take a step back, i would put these attributes in navigation timing

NicJansma: that was our original intention, to help describe why the page had been faster or slower, the feedback is JasonSobel feels it not useful, however not opposed. Nik Matsievsky from Webo mentioned he would value these attributes.
... No privacy concern or security issue noted so far, may require additional deeper dive. Not expensive to implement.

Tony: Not opposed, does resource timing make this redundant. if we add it now, we'll make sure it's not redundant.

Zhiheng: I have the same concern with Tony. If the resource fetched from cache, is that counted as request, that may reduce the value of what we are looking for and the bottle neck on the page. we need to work on the details on these two metrics.

Tony: If we do indicate if its from the cache we have concerns of privacy information.

NicJansma: IE9 have number of all the resources.

AndersonQuach: the two metrics complement each other.

SteveSouders: the attribute is called requestCount, sounds like network access. if the attribute is about resources, we should call it resource count.

NicJansma: We cannot split out resource that came from network or via cache, it would need to be appropriately named resourceCount.

Tony: this never decrements.

NicJansma: anytime thru an xhr, or img source, or get an external resource we increment by one.

AndersonQuach: next step, Anderson will propose the recommended text for the navigation timing to the spec.

NicJansma: do we think this has high value? or questioning it?

Tony: if we have a flat list of resource timings, like resourceTiming.length, however if we decide that we cannot have a flat list in resource timing. then i think it is high value. it's important information to convey. i much rather count the length of the resources.

SteveSouders: good point.

Zhiheng: adding a counter to resource timing instead.

SteveSouders: as the page is loading we'll be adding things to the resource timing array, and incrementing a counter. it would be better just to add things on the array and get the length. i'll flip here, there's a chance that this attribute has decreased value, redundant with resource timing. there is a little bit of complexity slowing down getting navigation timing out.
... i'm fine with omitting resourceCount from navigation timing.

Zhiheng: in addition to what we have in resource timing, we can expose a counter to make it easy to get a resource count.

NicJansma: resourceCount / requestCount is a close fit to the length of ResourceTiming; what do you think about uniqueDomains, they can compute the # uniqueDomains on their own, it would be nice to provide that to them. is this something we can fit into navigation timing.

SteveSouders: recommend bundle them together and post-pone them until resource timing.

AndersonQuach: sounds like a plan, IE will update the RC to reflect the most stable version of the navigation timing

Tony: will we see window.performance or window.msPerformance

NicJansma: our goal is to have window.performance, as long as we get navigation timing to a stable point.

AndersonQuach: get to CR to drop the vendor prefix

Tony: what are the blockers?

NicJansma: major differences are uniqueDomains, requestCount, definition of requestEnd

AndersonQuach: work through the differences, stablize the interface and address the definitions in the spec to get the spec stable.

Tony: let's proceed without uniqueDomains and requestCount

Zhiheng: let's move requestCount and uniqueDomains to resource timing

NicJansma: sounds good

Zhiheng: get as much information out of the timeline as much as possible.
... that seems like some problem in the implementation, do we need responseStart if the definition of requestEnd be the first byte of the server.

NicJansma: the thoughts in IE, having start and end defined, ease communication. it would be weird to have requestStart, requestEnd and responseEnd.
... we have start and stop for everything else, we don't have a stop for fetchEnd or navigationEnd, other phases have very similar timestamps. the time for the end of domain name lookup is close / similar to establishing the connection. it does not add a lot of overhead in the browser. it does help communicate the overall picture. it will help the developer understand the navigation.

Tony: what are your thoughts on measures and marks in IE?

AndersonQuach: in IE we will either vendor prefix or drop them for RTW.

Tony: we are leaning the way not having measures, i can echo what Nic says, it's nice for the developers, it looks like a measure, but you have to do the subtraction.

NicJansma: you can layout the overall timeline with start-stop marks.
... having the full timeline from the marks will make it more intuitive.
... we added it to the IE9 platform preview for feedback, but we have not gotten a lot of feedback from the community about this interface. if we decided to keep the measures, it may take longer to get through the navigation timing spec.
... we put it in because we thought it would be easy to use and useful for site developers.

SteveSouders: what's the definition to measures?

NicJansma: measures are the subtraction of the timing phases defined in the marks. e.g. dns measure is domainLookupEnd - domainLookupStart. easy to pack and easy to JSON.stringify
... it only gives you the deltas of the phases not the full details of the utc timestamps.

Zhiheng: seems like can omit in the measures for now and add the responseStart

NicJansma: that's my thoughts

AndersonQuach: as long as we can get to a uniform definition that is interopable to get a stable spec.

Tony: i like easily packable, i don't like redundant information. this is a grey close call. if all the users want to JSON.stringify to send it home. at this point, i really want to get to requestEnd, if marks in general should look like measures. wondering if starts and end should match up.

NicJansma: as a best practice, provide a JSON library to pack up the timing measures that's in a tightly packed structure, we can provide this type of sample to the community, here's 20-30 lines of JScript that makes this JSON array in a measure in a defined order.
... measure is redundant data.

Tony: Browser done its job to expose information that did not exist before, we do not yet what exactly is useful and we don't know what will be useful in the future. leaving measures up to the app is appealing to me.

NicJansma: we can always revisit measures in a future interface.

Zhiheng: we have an agreement here.

Tony: Are you okay with changing the definition of requestEnd == responseStart.

Zhiheng: if everyone agrees let's do it.

Tony: awesome.

NicJansma: we will work to get IE9 to get 100% conforming.

Tony: starting to feel real.
... not sure what you mean about that? if you get a reference to the frame, does the underlying object change?

NicJansma: good question, our testers pointed out. clicking a link and directs you to another page, the current page has the navigation timing object and initiating a new navigation. there is two navigation timing objects instantiated. in IE unload the last page only after we downloaded the new page, in the unload JavaScript even there is two navigation timings. the lifetime was not defined for the unload event. unload cannot pop-up dialog, cannot guar

Tony: they can make an img request

NicJansma: we do not make guarrantee packaging and transmission of navigation timing in unload, recommend to do it in onBeforeUnload.
... get your feedback on the lifetime.

Tony: in unload the current page performance information is available.
... it would be strange to expose information for subsequent page.

NicJansma: we don't want to do that's the wrong thing.

Tony: everything accessible in beforeunload is accessible in unload. that's the way i implemented the webkit version.
... is that difficult in IE?

NicJansma: there are technical challenges, but not a driving factor to what we want it to be.

Tony: if developers should not be doing much in the unload handler, they will try to ping this information back in the unload handler. i expect web developers to expect this to work.

NicJansma: one option is to access denying object in unload event.

Tony: i don't know how big the technical objects. webkit, everything is ref counted. if it's really hard. i would not be opposed to exploring other options. however, it should be accessible.

Zhiheng: is there anything blocking to releasing the navigation object in unload.

NicJansma: currently in the IE9 beta, future timing is started to be exposed in unload event, this can be worked around. we wanted to define the lifetime.

Zhiheng: we should keep the current browsing context in unload before populating the target / next browsing context in unload.

AndersonQuach: need to provide a constraint that the timing is relevant for the current browsing context in all events

Zhiheng: if i have JScript getting the timing object in the unload, what timing object are we getting.

Tony: in the current page, webkit has two timing objects in unload. the target navigation's timing object is not accessible in the current page's unload.
... look for any property in the window object, language or pattern to indicate properties of window object should have

Zhiheng: i'll check it out

AndersonQuach: sounds like a good plan

list the agenda

Zhiheng: good shape

Tony: we solved the first three we have consens

agenda 12

move to agendum 12

AndersonQuach: i'd like to propose review navigation timing, and review the intended reference implementation in IE9 and in Webkit, thoughts?

SteveSouders: those sound good to me. focusing on things that are better face to face than over email.
... we can work on examples, we may have a 30 line snippet for javascript, use the timing and becon it back. work on recommended sample snippets. may iterate faster live. add code samples.

AndersonQuach: agreed

Tony: great time to draw a straw man for the resource timing and user timing.

AndersonQuach: can use the time to dive deeper in ResourceTiming.

Zhiheng: let's bring up these issues in the face to face meeting.

NicJansma: do we want to tackle user timing in the f2f or the next conference call.

SteveSouders: let's talk about it on the conference call a little bit. i would add both of those tenatively to the agenda for the f2f. we should figure out which is more important.

NicJansma: sounds good let's talk about it next week's conference call.

Zhiheng: if we can come up with the initial draft of user timing before the face to face.

AndersonQuach: i'll sign up for that.

move to agenda 13

NicJansma: additional business?

Zhiheng: sounds good.

Summary of Action Items