Re: [minutes] 20110105 Web Performance Working Group

  FYI,  the draft is updated with a couple privacy/security discussions the
group had before.

cheers,
Zhiheng

On Wed, Jan 5, 2011 at 4:59 PM, Anderson Quach <aquach@microsoft.com> wrote:

> Web Performance Working Group Meeting05 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>
>       1. Moving Navigation Timing to Candidate Recommendation<http://www.w3.org/2011/01/05-webperf-minutes.html#item01>
>       2. Feedback on Resource Timing.<http://www.w3.org/2011/01/05-webperf-minutes.html#item02>
>       3. 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.
>
>
>