Available at
http://www.w3.org/2015/08/26-webperf-minutes.html
Text version:
Web Performance
26 August 2015
Attendees
Present
Todd, Eli, Ilya
Regrets
Chair
Ilya
Scribe
igrigorik
Contents
* [2]Topics
1. [3]PerformanceTiming#dom* attributes are poorly
defined
2. [4]Should Frame Timing report slow frames only?
3. [5]Navigation timing and Time-Allow-Origin
4. [6]Performance Timeline
5. [7]requestStart definition differ with navtimg
* [8]Summary of Action Items
__________________________________________________________
we'll start, agenda:
[9]https://lists.w3.org/Archives/Public/public-web-perf/2015Aug
/0016.html
[9]
https://lists.w3.org/Archives/Public/public-web-perf/2015Aug/0016.html
ACTION: start thread with plh@ to address first 3 items on
agenda.
PerformanceTiming#dom* attributes are poorly defined
ToddReifsteck: we should move this into an issue and figure out
the missing pieces, this may be more than one issue.
ACTION: open issue and followup on mailing list to clarify
Should Frame Timing report slow frames only?
ToddReifsteck: we're ok with that
eliperelman: left a comment on GitHub, it seems like all the
use cases are addressed, I don't have a problem with it.
ACTION: Ilya or Michael to put together a pull to expose slow
frames only
eliperelman: does Frame Timing name still make sense?
frame is a bit of a squishy concept.. we may need to clarify
its meaning. we should also think about input, scroll handlers,
etc
eliperelman: we do some jank detection in gecko side, it's not
exposed to JS today
we should continue this discussion on mailing list / github
(switching topic) for slow frames: we could report periodic
events with aggregate stats for min/slowest/median frames
ACTION: we'll take discussion to mailing list
Navigation timing and Time-Allow-Origin
igrigorik: Use Timing-Allow-Origin to determine same-origin on
redirects?
[10]https://github.com/w3c/navigation-timing/issues/20
... we would get this behavior if/when we redefine NavTiming on
top of ResTiming
[10] https://github.com/w3c/navigation-timing/issues/20
ToddReifsteck: edge may work like this, need to test.
... I think plh@ was close to completing that
ACTION: followup with plh@ on status and annevk@ to sanity
check
Performance Timeline
igrigorik: PerfTimeline task queue must be processed at least
once every Xms?
[11]https://w3c.github.io/performance-timeline/#performance-tim
eline
[11] https://w3c.github.io/performance-timeline/#performance-timeline
ToddReifsteck: requestIdleCallback is the only one that
intentionally designed to potentially starve the queue, others
don't.
eliperelman: we can just drop that requirement
ACTION: igrigorik to remove that section in the algorithm.
requestStart definition differ with navtimg
ACTION: confirm with plh@
ACTION: igrigorik to open pull for it
[12]https://github.com/w3c/resource-timing/issues/8
[12] https://github.com/w3c/resource-timing/issues/8
ACTION: ToddReifsteck to followup on issue with list of
implemented initiator's in IE
[13]http://w3c.github.io/resource-timing/#widl-PerformanceResou
rceTiming-initiatorType
[13]
http://w3c.github.io/resource-timing/#widl-PerformanceResourceTiming-initiatorType
igrigorik: we also need to make it fetch aware
ToddReifsteck: also doesn't say what it should be when its not
one of those on the list.. we need some MAY's in there
next call, Sept 9th
Summary of Action Items
[NEW] ACTION: confirm with plh@
[NEW] ACTION: followup with plh@ on status and annevk@ to
sanity check
[NEW] ACTION: igrigorik to open pull for it
[NEW] ACTION: igrigorik to remove that section in the
algorithm.
[NEW] ACTION: Ilya or Michael to put together a pull to expose
slow frames only
[NEW] ACTION: open issue and followup on mailing list to
clarify
[NEW] ACTION: start thread with plh@ to address first 3 items
on agenda.
[NEW] ACTION: ToddReifsteck to followup on issue with list of
implemented initiator's in IE
[NEW] ACTION: we'll take discussion to mailing list
[End of minutes]
