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
