See also: IRC log
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
----
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
---
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:[End of scribe.perl diagnostic output]