Re: [10/26/16] webperf group call @ 10AM PST

The record of this call is:
https://www.w3.org/2016/10/26-webperf-minutes.html <https://www.w3.org/2016/10/26-webperf-minutes.html>

Plain text pasted below.

Next meeting will be Nov 16th.

Thanks.

-xiaoqian

------------------------
Web Performance Teleconference

26 Oct 2016

Agenda

See also: IRC log

Attendees

Present
igrigorik, Ben_Maurer, Wesley, vladan, yoav, toddreifsteck, n8s, xiaoqian, NicJansma, nolanlawson
Regrets
Chair
igrigorik
Scribe
igrigorik
Contents

 • Topics
  • Long tasks / Long input: same?
  • Beacon: https://github.com/w3c/beacon/issues/29#issuecomment-255882261
 • Summary of Action Items
 • Summary of Resolutions
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 L3, 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

> On 26 Oct 2016, at 6:10 AM, Ilya Grigorik <igrigorik@google.com> wrote:
> 
> Doh. Apologies, the correct links are.. 
> 
> [5] https://github.com/w3c/navigation-timing/issues?utf8=%E2%9C%93&q=milestone%3A%22Level%203%22%20 <https://github.com/w3c/navigation-timing/issues?utf8=%E2%9C%93&q=milestone%3A%22Level%203%22%20>
> [6] https://github.com/w3c/user-timing/issues?utf8=%E2%9C%93&q=milestone%3A%22Level%203%22%20 <https://github.com/w3c/user-timing/issues?utf8=%E2%9C%93&q=milestone%3A%22Level%203%22%20>