Minutes (was: Re: [8/16/17] webperf group call @ 10AM PST)

Hi all,

Thanks for joining the call today.

Minutes are available:
https://www.w3.org/2017/08/16-webperf-minutes.html

The next meeting will be 30 August.

See also:
Web Performance Working Group

16 Aug 2017

See also: IRC log

Attendees

Present
igrigorik, shubhie, Yoav, todd, xiaoqian, Tim
Regrets
Chair
igrigorik
Scribe
igrigorik
Contents

Topics
Progress on existing specs
Moving incubation work into WG
New Proposals / reviews -- Event Timing and Custom Events
Summary of Action Items
Summary of Resolutions

https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#

Progress on existing specs

[hr-time] unload test > Todd will followup w/ Dale

we can publish CR once that lands

[beacon] CORS tests are blocking

Todd: I'll check-in with Brandon, we should have those tests

https://github.com/w3c/beacon/issues/41#issuecomment-322365422

[user-timing] https://github.com/w3c/user-timing/issues/20

Todd will check-in on status

one resource per entry test: 
https://github.com/w3c/web-platform-tests/pull/6567

yoav: feedback makes sense, we should accumulate the entries, I'll 
update the test

Moving incubation work into WG

Device Memory: propose to adopt officially into WG charter

Yoav/Todd: sgtm.

@yoav @xiaoqian will coordinate the move.

Paint Timing: proposal to adopt into WG

shubhie: shipped in Chrome, has TAG approval.

Todd: LGTM

Yoav: will coordinate the transfer

New Proposals / reviews

Tim: event timing proposal

https://docs.google.com/presentation/d/1tp3VzgekEfEvymx7eG3ABDoocOZUE7ZsHR3fB44y088/edit

Tim: ^ motivation
... why not long tasks? LT does not associate al the different 
top-level-tasks that contribute to a long input event --> goal: this 
input event caused a long frame
... for every DOM event: report handler duration, and if we "drew", time 
until draw
... "drew" is step 4.3 of event loop: "if necessary update the rendering 
of document..."
... if it was necessary use the timestamp when update ran, if not do not 
provide
... show eventTimestamp and when processing starts and ends (e.g. if 
event processing was blocked)
... we can polyfill much of this, but performance overhead is 
prohibitive; had to monkey patch addEventListener

Todd: at first glance, this looks good; some of field names need a more 
developer friendly name
... also worried about linking to rendering but not accounting for 
off-thread work -- e.g. compositing time, etc.
... a lot of partners I see today, are using raF based polyfills
... let's say we have this and Long Tasks, are we missing anything?

Tim: frame display time, probably...
... perhaps more associated event data

Shubhie: we still need slow frames API

Todd: right, we need to find the right balance on that API; we can't / 
shouldn't report every frame
... event duration signals that something got in the way of paint; Long 
tasks / long frame help explain what happened
... I like the overall idea and direction here, need to iterate on 
naming and developer ergonomics

Shubhie: what about mitigations for rendering?

Tim: ... we expose if step 4.3 was executed
... one possibility is to run 4.3 whenever you hover, not sure if it 
provides full coverage

Yoav: how does an analytics provider register for this?

Tim: you register for all events (e.g. type => "event")

Yoav: sgtm

Ilya: do we need to have a conditial 4.3?

Tim: it may be hard to figure out when to record that timestamp, but 
probably doable
... the question is whether we can "fake" it well enough
... I'll do some more thinking on if/how we can do this; the idea is to 
always report 4.3 and make it indistinguishable

Yoav: what about changing :visited. Alex Russel had a proposal

AI's: iterate on developer ergonomics; investigate rendering steps

scribe: let's move to WICG to enable feedback and comments
... timeline: prototype in ~Q4 in CHrome

Custom Events: 
https://docs.google.com/presentation/d/1vGE_6wWNBI7Mm4PHLry0L-Hmu4Mg3xco0vKsb0Zrsoc/edit

Tim: motivation ^
... right now developers are doing pretty gross things with mark and 
measure -- e.g. encoding data into name string, etc.
... arbitrary timestamps is another limitation of UT
... e.g. if you want to mark something retroactively, UT does not 
support
... also, want to provide ability to provide custom data
... proposal: performance.queueEntry(...)
... we could probably extend UT mark or measure
... we could expose a constructor, but that's inconsistent with 
mark/measure
... that said, we can make either of those work
... we can get pretty far with a polyfill, but the value here is 
providing a shared interface for developers + analytics
... there may be merit in providing filtering capabilities in v2+, don't 
think this is strictly required in v1

Todd / Ilya: filtering is more of a generic PO function, let's separate 
that from this proposal

Shubhie: an explicit difference from mark and measure is that you have 
to provide timestamps

Todd: need to look at this some more; Nolan wanted arbitrary data and 
more; the downside is that it requires that you write more JS

Tim / Todd: mark and measure have some benefits, we should think about 
how much we can extend and improve them

scribe: Tim: we could probably easily build a shim to implement mark and 
measure on top of this

Todd: this looks great, just need to iterate on shape and timeline
... if you can get this up on WICG, then we can start iterating; I'm 
very supportive of this, because it provides clear value to the web

AI: get the spec on WICG
... next call: Aug 30.

On 2017-08-16 05:26, Ilya Grigorik wrote:
> Hangout:
> https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg [1]
> 
> WIP
> agenda:https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#heading=h.ub36z2juzhwm
> [2]
> 
> If you have other topics you'd like to discuss, please feel free to
> edit and add to the doc above.
> 
> Links:
> ------
> [1] https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg
> [2]
> https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#heading=h.ub36z2juzhwm

Received on Wednesday, 16 August 2017 18:29:02 UTC