W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2016

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

From: Xiaoqian Wu <xiaoqian@w3.org>
Date: Thu, 27 Oct 2016 20:37:46 +0800
To: public-web-perf <public-web-perf@w3.org>
Message-Id: <4B7D71E2-75B3-4B80-A30D-3D2918DF2F66@w3.org>
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.



Web Performance Teleconference

26 Oct 2016


See also: IRC log


igrigorik, Ben_Maurer, Wesley, vladan, yoav, toddreifsteck, n8s, xiaoqian, NicJansma, nolanlawson

	• 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


AI: take this discussion to Github


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


ig: I dropped Worker support from spec

toddreifsteck: we're OK with that


<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.

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


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

toddreifsteck: sgtm
... no objections from others


<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>
Received on Thursday, 27 October 2016 12:38:01 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 27 October 2016 12:38:01 UTC