IRC log of webperf on 2017-05-31

Timestamps are in UTC.

17:03:36 [RRSAgent]
RRSAgent has joined #webperf
17:03:36 [RRSAgent]
logging to http://www.w3.org/2017/05/31-webperf-irc
17:03:43 [Zakim]
Zakim has joined #webperf
17:07:02 [igrigorik]
f2f: June 20 LGTM from everyone
17:07:12 [igrigorik]
we have attendance from Mozilla, Chrome, Apple, Edge.
17:07:30 [igrigorik]
we have a room booked for 16 people
17:07:52 [igrigorik]
AI: Yoav to add link with directions
17:08:33 [igrigorik]
9-4AM on 20th
17:10:41 [igrigorik]
Agenda: let's allocate an hour or two for key issues, and then focus for the forward looking work.
17:11:09 [igrigorik]
Yoav: it'll be good to have repo owners triage issues ahead of time.
17:12:20 [igrigorik]
let's work on the agenda and review on the 14th
17:12:42 [igrigorik]
AI: call on the 14th
17:14:46 [igrigorik]
next up: enhanced Element proposal
17:14:55 [igrigorik]
cathiechen: https://discourse.wicg.io/t/proposal-enhance-heroelement/2163
17:17:27 [igrigorik]
... element priority could be a hint to the browser to optimize rendering
17:20:34 [igrigorik]
Shubhie: we should probably treat hero, priority, and callbacks as different requirements
17:20:48 [igrigorik]
... a page should probably have just a few hero elements
17:21:02 [igrigorik]
... the prioritization system feels like a separate thing
17:21:12 [igrigorik]
... the browser should try to prioritize hero elements
17:21:41 [igrigorik]
Yoav: agree, prioritization is something we need to tackle and it should probably be a separate concern
17:22:29 [igrigorik]
Yoav: there is rendering vs resource priorities
17:23:57 [igrigorik]
n8s: not sure if we want hero element to be treated differently
17:24:23 [igrigorik]
... prioritization is separate; we mostly want metrics for those elements
17:24:39 [igrigorik]
nic: for RUM it's a great way to identify which elements should be measured
17:25:24 [smaug]
smaug has joined #webperf
17:26:14 [igrigorik]
todd: callbacks is another issue, we're hesitant to expose more of these
17:26:28 [igrigorik]
Shubhie: what's the value of callbacks?
17:27:16 [igrigorik]
... other than measurement, which we already tackle
17:29:41 [igrigorik]
Cathie: we use callbacks to know when element is paitned, so we can switch (web)views
17:29:51 [igrigorik]
todd: we've had requests like this for Edge
17:30:20 [igrigorik]
... implementing callbacks like this is probably not the best place in Hero Element
17:30:38 [igrigorik]
... there is a use case here, but its unclear if callbacks on elements is the correct solution
17:31:24 [igrigorik]
... the hard part about elements, is that if browser is well optimized, because we may never even layout something out of view.. let alone paint
17:31:48 [igrigorik]
... the entire idea of the use case doesn't match the processing model -- it does match how some browsers operate
17:32:29 [igrigorik]
AI's: cathie to followup on WICG
17:32:44 [igrigorik]
... on how to identify hero elements
17:34:37 [igrigorik]
next up: Long Tasks
17:34:55 [igrigorik]
nic: we have beta plugin of boomerang collecting LT data
17:35:10 [igrigorik]
... using for attribution and signal as time to interactive
17:35:41 [igrigorik]
... using alongside raF powered frame-rate (not ideal but still useful)
17:36:05 [igrigorik]
... really impressed with how well it's giving us attribution into delays of page load process
17:36:41 [igrigorik]
... e.g. container-id is a pretty good signal that allows you to bucket for identifying culprits -- e.g. social widgets, ads, other scripts
17:37:20 [igrigorik]
... there are a lot of cases where large chunks we can't identify, maybe there's some opportunities for improvement there
17:37:42 [igrigorik]
... overall, very actionable data and we're very enthusiastic about it
17:38:01 [igrigorik]
... attribution is key
17:38:17 [igrigorik]
shubhie: also, Nic has a polyfill for time-to-interactive
17:38:50 [igrigorik]
nic: our customers are very enthusiastic about moving away from onload and more towards "when is page interactive" metrics
17:39:25 [igrigorik]
... we're currently doing something similar to LH and WPT for measuring time to interactive; long tasks looks to be a pretty good signal.
17:41:26 [igrigorik]
... heuristic: combination of load time of hero images, followed by monitoring long-tasks, rAf powered frame rate, and polling for setTimeout (to detect stalls).. checking that it doesn't happen for 1s
17:42:11 [igrigorik]
todd: large chunks of idle time are not necessarily.. necessary for a good experience; current heuristics don't capture that
17:42:39 [igrigorik]
.. the core problem is when browser is ready to process input
17:42:55 [igrigorik]
shubhie: but input can trigger your rendering pipeline, etc.
17:43:29 [igrigorik]
todd: long task can block input, but 3 back-to-back LT's can allow for input to be interleaved
17:44:22 [igrigorik]
shubhie: right, we have different metrics.. e.g. time-to-consistently-interactive vs more optimistic interactive window
17:44:54 [igrigorik]
todd: how do we measure interactivity? there is probably an opportunity to have some standardization here
17:45:10 [igrigorik]
igrigorik: let's move this to F2F.
17:45:40 [igrigorik]
shubhie: we're starting to think about long-tasks v2.. input welcome.
17:46:06 [igrigorik]
next up Preload
17:46:34 [igrigorik]
yoav: there is a bunch of HTML and Fetch integrations in progress
17:46:53 [igrigorik]
... landed big update in Fetch to use "potential destination"
17:47:50 [igrigorik]
... Domenic is working on adding a hook for adding processing model into HTML spec
17:48:05 [igrigorik]
... the processing logic will live in HTML spec
17:48:27 [igrigorik]
... similar to this, working on moving 'as' attribute into HTML spec
17:48:58 [igrigorik]
... last but not least, need to define "preload cache"
17:49:17 [igrigorik]
... FF is implementing preload and WPT tests are failing because they have a different model for caching
17:50:13 [igrigorik]
... we're starting to hit observable differences when it comes to preload implementation
17:50:44 [igrigorik]
... we need to define that under a single processing model in Fetch
17:51:51 [igrigorik]
Blink update: pending i2s for empty-as as an error
17:52:02 [igrigorik]
... 1LGTM, waiting for more feedback
17:52:12 [igrigorik]
... also planning to implement in webkit
17:53:09 [igrigorik]
https://github.com/w3c/performance-timeline/issues/77
17:53:55 [igrigorik]
Shubhie: this came up when we told folks to try PaintTiming
17:54:10 [igrigorik]
Charles: could you provide "*" for I want everything?
17:54:23 [igrigorik]
... that doesn't tell you if something is not supported
17:54:41 [igrigorik]
Yoav: we have feature detection covered
17:56:19 [igrigorik]
~polyfill: https://github.com/w3c/performance-timeline/issues/77#issuecomment-305068588
17:56:28 [igrigorik]
todd: what if the types are constructable?
17:57:27 [igrigorik]
... it feels like .getSupportedTypes might be a good convenience feature
17:58:20 [igrigorik]
yoav: what's the difference from 'as'?
18:01:00 [igrigorik]
igrigorik: let's take this to the list to discuss
18:01:07 [igrigorik]
next call June 14 @ 10am -- our usual slot.
18:02:10 [xiaoqian]
present+ igrigorik, n8s, nolanlawson, shubie, yoav, todd, charles, nic, cathiechen
18:02:16 [xiaoqian]
present+ xiaoqian
18:02:22 [xiaoqian]
chair: igrigorik
18:02:26 [xiaoqian]
scribe: igrigorik
18:02:30 [xiaoqian]
RRSAgent, make minutes
18:02:30 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/05/31-webperf-minutes.html xiaoqian
18:02:34 [xiaoqian]
RRSAgent, make log public
18:03:29 [xiaoqian]
meeting: WebPerf Weekly Call
18:03:34 [xiaoqian]
RRSAgent, make minutes
18:03:34 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/05/31-webperf-minutes.html xiaoqian
18:27:54 [yoav_]
yoav_ has joined #webperf
20:23:06 [n8s]
n8s has joined #webperf
20:24:13 [Zakim]
Zakim has left #webperf
20:48:16 [n8s]
n8s has joined #webperf