[minutes] 20110112 Web Performance WG

Web Performance Working Group
12 Jan 2011

See also: IRC log<http://www.w3.org/2011/01/13-webperf-irc>

Minutes
http://www.w3.org/2011/01/13-webperf-minutes.html
Attendees
Present
AndersonQuach, TonyG, JamesSimonsen, Zhiheng, NicJansma
Regrets
JasonWeber
Chair
ArvindJain
Scribe
AndersonQuach
Contents

  *   Topics<http://www.w3.org/2011/01/13-webperf-minutes.html#agenda>
1.     Resource Timing.<http://www.w3.org/2011/01/13-webperf-minutes.html#item01>
2.     Test Case submissions.<http://www.w3.org/2011/01/13-webperf-minutes.html#item02>
3.     UserTimings.<http://www.w3.org/2011/01/13-webperf-minutes.html#item03>
4.     Summary<http://www.w3.org/2011/01/13-webperf-minutes.html#item04>

i. Let's capture the resource timing requirements so that we can circulate this out to the web development community.

ii. Kicking off the approval for the first sets of tests and the test harness in preparation for the beginning of the next meeting.

iii. Review updates to the user timing specification Zhiheng will updating.

________________________________
Resource Timing.

Move to Agenda 1

TonyG: Provide the ability to play the event model to see if it meets the use cases. Looking at the demo page to see if it meets the requirements. Bubbling the onload event we can pub items into an array. We like it because of the ability to garbage collect. If there is no listener, set the flag to not record these times.

NicJansma: Looks fairly simple in terms of the demo. What's in the payload?

TonyG: Virtually the same attributes in Navigation Timing. All the network times and the load event.

NicJansma: Do you have the URL or id?

TonyG: No, you can do event id or source element. It's implicit based on the events. You don't have to recreate these things.

AndersonQuach: What about statically declared resources?

TonyG: This assumes the user calls addEventListener prior to resource being loaded? The listeners need to be registered before the load event fires. Gotchas with asynchronous image loaded with start recording and stop recording. The callback need to be there until the event is fired. It needs to be present until the bubbled event.

Zhiheng: How are we going to deal with resources like JS and CSS?

TonyG: This works for iframe, link rel stylesheet, embed, and the other known resources. It misses CSS sub resources, a URL, background image and font and no load event for that. There might be a way to add an event to that, it's not too natural.

NicJansma: That's my biggest concern. I would want to make sure we can still get the css sub resources and object that doesn't have an onload handler. I'm not sure about the complexity of having an event to register for these sub resources. I feel it's important to get a complete picture to download for the load.

TonyG: People can ideally generate a waterfall diagram with this data. It would be strange to put this API out there, CSS images are not here, and you have a gap. That would be strange. James and I, Darren Fischer, having an event on the link element. Applies to inline and external stylesheet.

NicJansma: Perhaps there's an existing need when css sub resources loaded. Reach-out to the css working group?

TonyG: You've pointed some fair gaps. That's what we were hoping, to figure out missing use cases and start the discussion.

Zhiheng: I do agree we need to cover all the resources. The requirement of addEventListener for all the resources we care about may not always be feasible. The demo is great.

NicJansma: Thanks for putting the demo together.

AndersonQuach: I want to make sure that we have the right use-cases and requirements to circulate that with web developers.

Zhiheng: I think that's great, I think Anderson's requirement email covers it quite well. I feel like we need to cover security. I propose having that discussion with the working group on security.

AndersonQuach: Absolutely. We can offer a less granularity timeline in cross-domain accesses. A load start and end. We can think about an authorization mechanism to grant access to the more detailed timeline.

Zhiheng: I like that.

NicJansma: Even if the server responds it is okay, I'm not sure if that fixes the privacy concern. What if facebook.com has an image server, this doesn't help the user. I guess the server can respond what domain the can access the detailed timing information. We can look into that further.

Zhiheng: We don't have to come up with an answer right now. It's a blocking issue, particularly the timing information we want to provide.

AndersonQuach: We've talked about allow, deny, limited timelines and authorization mechanisms. Are there other levers to explore?
Test Case submissions.

move to agenda 4

TonyG: The test cases we use in web kit, it uses our supporting scripts. There's overlap with the Microsoft tests

AndersonQuach: Look at the html5 harness. URL.

Zhiheng: We are using a private web perf branched from HTML5.

NicJansma: Is the harness a derivative from HTML5.

Zhiheng: The only catch is that it is local to the repository. The test harness.js that was uploaded.
... is the additions complementary?

NicJansma: they are complementary, to help reduce complexity of the tests overall.

AndersonQuach: Let's work towards EOD Thrus to get the additions of the harness and aim for the attribute tests to approve it.

Harness: http://test.w3.org/html/tests/harness/

move to agenda 2.
UserTimings.

move to agenda 2

Zhiheng: Minor things in mind with user timings. One thing I want to get here is that mark fullyloaded is redundant and remove that and add another enum. My proposal is I tend to agree, we should come up with a set of ENUM type. Later we might have critical points.

AndersonQuach: That makes sense.

Zhiheng: Add measures to provide the time interval.

NicJansma: Can you explain that?

Zhiheng: Measure event, compute the time in the phase as an input. As it can be commonly used.
... Is there a way to carry over timing information to another page.

AndersonQuach: We can use existing mechanisms, like cross document messaging.

Zhiheng: Can use web storage, for cross navigation communication for potential use.
Summary

i. Let's capture the resource timing requirements so that we can circulate this out to the web development community.

ii. Kicking off the approval for the first sets of tests and the test harness in preparation for the beginning of the next meeting.

iii. Review updates to the user timing specification Zhiheng will updating.