- From: Philippe Le Hegaret <plh@w3.org>
- Date: Mon, 14 Sep 2015 10:29:11 -0400
- To: public-web-perf <public-web-perf@w3.org>
Available at http://www.w3.org/2015/08/12-webperf-minutes.html Text version: Web Performance Working Group 12 August 2015 [2]Agenda [2] https://lists.w3.org/Archives/Public/public-web-perf/2015Aug/0007.html Attendees Present Michael, Todd, Ilya, Eli, Mark Regrets plh Chair Todd Scribe igrigorik Contents * [3]Topics 1. [4]Next steps with Animation Timing spec... 2. [5]requestIdleCallback to FPWD 3. [6]Navigation Timing 4. [7]Frame Timing 5. [8]Beacon issues * [9]Summary of Action Items __________________________________________________________ Next steps with Animation Timing spec... ToddReifsteck: we should wait for plh@ for right steps to do a crisp handoff ... we should ask plh@ how to handoff outstanding issues AI: we'll wait for next call with plh@ to resolve this one requestIdleCallback to FPWD mpb: any concerns over visited, does that need to block FPWD? ToddReifsteck: doesn't need to block, we can publish FPWD igrigorik: I'll check if we can publish, might need plh to flip right bits Navigation Timing <ToddReifsteck> [10]https://github.com/w3c/navigation-timing/pull/32 [10] https://github.com/w3c/navigation-timing/pull/32 ToddReifsteck: no objections, will merge Frame Timing Next item: [11]https://github.com/w3c/frame-timing/issues/46 [11] https://github.com/w3c/frame-timing/issues/46 <ToddReifsteck> Upcoming: [12]https://github.com/w3c/performance-timeline/issues/41 [12] https://github.com/w3c/performance-timeline/issues/41 <ToddReifsteck> Upcoming: [13]https://github.com/w3c/performance-timeline/pull/43 [13] https://github.com/w3c/performance-timeline/pull/43 mpb: keeping them separate allows us to add different attributes in the future (something we discussed but don't have today.. yet) eliperelman: the paths to both of them are very different, there might be some associated overhead.. ToddReifsteck: we can add the counter event interface in the future if we get a 3rd or 4th ... wontfix, will followup on the bug <ToddReifsteck> Next item: [14]https://github.com/w3c/performance-timeline/issues/41 [14] https://github.com/w3c/performance-timeline/issues/41 ToddReifsteck: thinking is.. if PO has ability to report existing timeline then JS interface is much simpler (no races) ... same thing is possible via other means but we need a crisp processing model some issues: lookback doesn't play well with our current buffer model; we should nail the processing model first mpb, eliperelman: there is potential for missed events (e.g. exceeded buffer) looking at Chrome, changing buffer size is very rare mpb: a plausible v2 enhancement? [15]https://github.com/w3c/navigation-timing/issues/1 [15] https://github.com/w3c/navigation-timing/issues/1 <ToddReifsteck> [16]https://github.com/w3c/performance-timeline/pull/43 [16] https://github.com/w3c/performance-timeline/pull/43 ToddReifsteck: we should nail down the processing model, we'll resolve current issue as possible future enhacement any objections to going back to "new PerfObserver" approach? ToddReifsteck: no, we should iron out the language questions and get Anne/Boris to sign off Eli: no objection mpb: we'll follow up on the thread Beacon issues <ToddReifsteck> [17]https://github.com/w3c/beacon/issues/10 [17] https://github.com/w3c/beacon/issues/10 [18]http://w3c.github.io/beacon/#sec-processing-model [18] http://w3c.github.io/beacon/#sec-processing-model <ToddReifsteck> [19]https://github.com/w3c/beacon/issues/5 [19] https://github.com/w3c/beacon/issues/5 Re, #10: igrigorik to followup, current spec is already defined via Fetch Re, #5: we'll define Beacon-Age, the similar use case for NEL is no longer relevant because NEL can deliver multiple reports in same payload <ToddReifsteck> Preload: [20]https://github.com/w3c/preload/pull/26 [20] https://github.com/w3c/preload/pull/26 <ToddReifsteck> 8/26 for next call
Received on Monday, 14 September 2015 14:29:14 UTC