Hangout for today's call: https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg

ben: we want to know how long between user action (e.g. click) to response on the screen (e.g. show a spinner)
... 1) hardware input to event running
... 2) event running to processed in app code

3) processed in app code to visible

scribe: today we guess by setTimeout + raf as an estimate on how long it takes for something to get painted
... all three are equally important to surface
... there are cases where we have significant delays; cases where we force costly rendering operations that delay paint
... if we're trying to create an API that measures input, we should try to capture all three phases
... total time should be "duration of the event"
... for paint, timing up to the end of layout may be acceptable -- close enough approximation
... shubhie/tim gave pushback on the 3rd, but there are many opportunities for dev's to screw this up (it's not just up to the browser)

yoav: not clear on what the 3rd part is, what do you want to measure? how does the browser correlate between handling event and paint

ben: the 100ms response cycle places hard constraints on what you can do; you can't do network requests.. first phase is to show a response locally (e.g. spinner)
... a good input API should allow you to distinguish between events that do and do not have a response (e.g. mousemove may not have direct response)

ig: above definition is the ~optimistic first opportunity to provide visual response; it's possible for the code not _not_ do this, but that's their own "fault"

yoav: we also need to think about the thresholds (e.g. 50ms may be too agressive)

ben: breaking out sub-parts is also a good idea, but we should provide total duration also
... there needs to be a way for an event to tell the browser if this event should be considered for this API
... today our heuristic is dirtying the DOM

ig: how about debounce/rate-throttlign pattern

ben: maybe we could treat ~setTimeout as an input event; maybe treat the next paint event

yoav: you could polyfill parts of this?

ben: yes, but it's tricky and requires careful instrumentation -- e.g. all addeventlisteners, custom fields on event, etc. In practice, tricky to deploy and enforce

todd: if you're office.com and have 40 teams.. having a standard API would be very helpful to solve the coordination problem

AIs: Ben to draft summary

----

Long tasks / Long input: same?

Yoav: I think I'm convinced where LT will be triggered but LI won't and vice versa

todd: LT is essential for identifying what the likely impact will be; Input is actually rare..
... in real world you migth only enable LT for subset of users in production

ig: we also discussed blocked flag on LT?

n8s: input api: here's the thing that mattered and it was blocked; LT is good for identifying potential problems, you'll probably sample

AI: continue discussion on github

---

Beacon: https://github.com/w3c/beacon/issues/29#issuecomment-255882261

toddreifsteck: current Chrome quota implementation is interesting... passes current spec language, but probably a little strict
... an SPA can have a lifetime of days

yoav: perhaps the quota should only be enforced once onunload starts? that would solve the SPA case

NicJansma: we're implementing sendBeacon (Soasta), we might have more telemetry

https://www.chromestatus.com/metrics/feature/timeline/popularity/495

AI: take this discussion to Github

https://github.com/w3c/web-platform-tests/pull/4024#discussion_r84792665

toddreifsteck: probably a low priority..

NicJansma: agree, if we get an error we'll probably just fallback strategy

toddreifsteck: I'd like to followup with Travis

ig: let's pull in Anne as well

AI: let's take this for review with Travis and Anne

https://github.com/w3c/beacon/issues/37

ig: I dropped Worker support from spec

toddreifsteck: we're OK with that

bitly.com/w3c-webperf-status

<toddreifsteck> Ilya, if you feed me links to URLs, I can get them to the owner of the DOM page if it isn't properly filtering for any of them.

https://lists.w3.org/Archives/Public/public-web-perf/2016Oct/0004.html

ig: any objections to publishing L3's for Performance Timeline L3, Resource Timing L2, Navigation Timing L3, User Timing L3
... no objections. we'll publish L3's.
... i'll create "v2" branches for each and gh-pages will track L3's

transitions to L2

https://github.com/w3c/user-timing/issues/19

ig: spec is ready, I suggest we push it to CR and work on tests in parallel

toddreifsteck: sgtm
... no objections from others

https://github.com/w3c/page-visibility/issues/25

<plh> +1 re L2 branch and L3 in gh-pages

igrigorik: spec ready to go, suggest we push it to CR
... sgtm from Todd and rest

next call, Nov 16th

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: igrigorik
Inferring Scribes: igrigorik

WARNING: No "Topic:" lines found, but dash separators were found.  
Defaulting to -dashTopics option.

Present: igrigorik Ben_Maurer Wesley vladan yoav toddreifsteck n8s xiaoqian NicJansma nolanlawson

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Agenda: https://lists.w3.org/Archives/Public/public-web-perf/2016Oct/0004.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 26 Oct 2016
Guessing minutes URL: http://www.w3.org/2016/10/26-webperf-minutes.html
People with action items: