W3C home > Mailing lists > Public > public-web-perf@w3.org > January 2011

[minutes] 20110105 Web Performance Working Group

From: Anderson Quach <aquach@microsoft.com>
Date: Thu, 6 Jan 2011 00:59:53 +0000
To: public-web-perf <public-web-perf@w3.org>
Message-ID: <1E1FF4102DEA7A40AF9CC342044ECE5D2E3B3813@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
Web Performance Working Group Meeting
05 Jan 2011

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

Minutes
http://www.w3.org/2011/01/05-webperf-minutes.html
Attendees
Present
[Microsoft], +1.650.214.aaaa, +1.650.253.aabb, +1.650.691.aacc, +1.415.829.aadd, Plh, AndersonQuach, JamesSimonsen, TonyG, NicJansma, ChristianBiesinger, Zhiheng, JasonSobel
Regrets
Chair
ArvindJain, JasonWeber
Scribe
AndersonQuach
Contents

  *   Topics<http://www.w3.org/2011/01/05-webperf-minutes.html#agenda>
     *   Moving Navigation Timing to Candidate Recommendation<http://www.w3.org/2011/01/05-webperf-minutes.html#item01>
     *   Feedback on Resource Timing.<http://www.w3.org/2011/01/05-webperf-minutes.html#item02>
     *   Summary<http://www.w3.org/2011/01/05-webperf-minutes.html#item03>

i. Zhiheng will add content to the privacy and security section of navigation timing that correspond to the discussions this working group has had in mail. Will target by EOW to have the draft complete.

ii. The working group will solicit back from web developers on requirements for the resource timing interface.

iii. The working group will continue discussions on resource timing and user timings in the next meeting.

________________________________

scribe+ AndersonQuach
Moving Navigation Timing to Candidate Recommendation

AndersonQuach: Recommend to go to last call.

plh: Nothing prevents us from going to last call.

All: Yes, lets go to Last Call.

plh: We'll publish tomorrow.
... min. duration for last call is four weeks.

AndersonQuach: we can work with four weeks.

plh: let's get feedback from web-apps, that includes webidl

Zhiheng: feedback from http folks.

plh: i can ask these people to look at it.
Feedback on Resource Timing.

move to agenda 2

NicJansma: were you able to do further investigations with event log and addEventListener.

TonyG: We came up with the same amount of memory with the flat array.
... We did an experiment with global event handlers on a top newsite. we site a date in the handler, and capture the date on all the sub-resource. Ran 100 times in a control environment. The error margin was 5ms, but 1ms in delay. Virtually no difference.

NicJansma: Good, I would expect that.

TonyG: The overall page load was 1.2s.

NicJansma: I hope to do the same experiment with the addEventListener implementation, I expect the impact to be comparable.
... We have not gotten good feedback from web developers. We've talked to our own web teams and large websites, how do we potentially narrow down the best approach.

TonyG: Planning summit at Velocity, that has 30-50 from top websites, that might be a reasonable venue to float these ideas then.
... That's a great crowd to solicite feedback from.

NicJansma: Great idea.

TonyG: I'll solicite feedback from these folks about Resource Timing.

AndersonQuach: To recap, add event log optimizes for both batch collection and the ability to collect a single resource timing with lazy loading script. addEventListener is really great at capturing discrete resource timings and the web developer would have to maintain their own data structure to collect all resources.

JamesSimonsen: Zhiheng wants to capture the resource timing in the xhr event itself.

JasonSobel: It's better to have on interface that is consistent.

Zhiheng: That sounds reasonable.

JasonSobel: Seems like the event log is a tiny bit simpler. I don't think that bit of script is a big deal. I'm flexible. It gets at the data our team care about. It's a great idea to pull other teams to get feedback.
... We can ask SteveSounders to put on his blog and or tweet about these two options. He has a pretty wide audience. He can help us.

TonyG: One last question, before the break. We talked about a dead-line to remove the vendor prefix.

NicJansma: We don't have a complete document that captures the two recommendations.

TonyG: A good portion is about collecting requirements.

<plh> oh, section 5 and 6 in navigationtiming are empty (privacy and security). what's our intent there?

<plh> http://dev.w3.org/html5/webstorage/#privacy

<plh> http://dev.w3.org/html5/webstorage/#security-storage

Zhiheng: I'll populate these sections and aim to publish by end of week.
... Let's talk about User-timings next meeting.
Summary

i. Zhiheng will add content to the privacy and security section of navigation timing that correspond to the discussions this working group has had in mail. Will target by EOW to have the draft complete.

ii. The working group will solicit back from web developers on requirements for the resource timing interface.

iii. The working group will continue discussions on resource timing and user timings in the next meeting.
Received on Thursday, 6 January 2011 01:01:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 January 2011 01:01:13 GMT