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