f2f: June 20 LGTM from everyone

we have attendance from Mozilla, Chrome, Apple, Edge.

we have a room booked for 16 people

AI: Yoav to add link with directions

9-4AM on 20th

<scribe> Agenda: let's allocate an hour or two for key issues, and then focus for the forward looking work.

Yoav: it'll be good to have repo owners triage issues ahead of time.

let's work on the agenda and review on the 14th

AI: call on the 14th

next up: enhanced Element proposal

cathiechen: https://discourse.wicg.io/t/proposal-enhance-heroelement/2163
... element priority could be a hint to the browser to optimize rendering

Shubhie: we should probably treat hero, priority, and callbacks as different requirements
... a page should probably have just a few hero elements
... the prioritization system feels like a separate thing
... the browser should try to prioritize hero elements

Yoav: agree, prioritization is something we need to tackle and it should probably be a separate concern
... there is rendering vs resource priorities

n8s: not sure if we want hero element to be treated differently
... prioritization is separate; we mostly want metrics for those elements

nic: for RUM it's a great way to identify which elements should be measured

todd: callbacks is another issue, we're hesitant to expose more of these

Shubhie: what's the value of callbacks?
... other than measurement, which we already tackle

Cathie: we use callbacks to know when element is paitned, so we can switch (web)views

todd: we've had requests like this for Edge
... implementing callbacks like this is probably not the best place in Hero Element
... there is a use case here, but its unclear if callbacks on elements is the correct solution
... 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
... the entire idea of the use case doesn't match the processing model -- it does match how some browsers operate

AI's: cathie to followup on WICG

scribe: on how to identify hero elements

next up: Long Tasks

nic: we have beta plugin of boomerang collecting LT data
... using for attribution and signal as time to interactive
... using alongside raF powered frame-rate (not ideal but still useful)
... really impressed with how well it's giving us attribution into delays of page load process
... e.g. container-id is a pretty good signal that allows you to bucket for identifying culprits -- e.g. social widgets, ads, other scripts
... there are a lot of cases where large chunks we can't identify, maybe there's some opportunities for improvement there
... overall, very actionable data and we're very enthusiastic about it
... attribution is key

shubhie: also, Nic has a polyfill for time-to-interactive

nic: our customers are very enthusiastic about moving away from onload and more towards "when is page interactive" metrics
... we're currently doing something similar to LH and WPT for measuring time to interactive; long tasks looks to be a pretty good signal.
... 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

todd: large chunks of idle time are not necessarily.. necessary for a good experience; current heuristics don't capture that
... the core problem is when browser is ready to process input

shubhie: but input can trigger your rendering pipeline, etc.

todd: long task can block input, but 3 back-to-back LT's can allow for input to be interleaved

shubhie: right, we have different metrics.. e.g. time-to-consistently-interactive vs more optimistic interactive window

todd: how do we measure interactivity? there is probably an opportunity to have some standardization here

igrigorik: let's move this to F2F.

shubhie: we're starting to think about long-tasks v2.. input welcome.

next up Preload

yoav: there is a bunch of HTML and Fetch integrations in progress
... landed big update in Fetch to use "potential destination"
... Domenic is working on adding a hook for adding processing model into HTML spec
... the processing logic will live in HTML spec
... similar to this, working on moving 'as' attribute into HTML spec
... last but not least, need to define "preload cache"
... FF is implementing preload and WPT tests are failing because they have a different model for caching
... we're starting to hit observable differences when it comes to preload implementation
... we need to define that under a single processing model in Fetch

Blink update: pending i2s for empty-as as an error

scribe: 1LGTM, waiting for more feedback
... also planning to implement in webkit

https://github.com/w3c/performance-timeline/issues/77

Shubhie: this came up when we told folks to try PaintTiming

Charles: could you provide "*" for I want everything?
... that doesn't tell you if something is not supported

Yoav: we have feature detection covered

~polyfill: https://github.com/w3c/performance-timeline/issues/77#issuecomment-305068588

todd: what if the types are constructable?
... it feels like .getSupportedTypes might be a good convenience feature

yoav: what's the difference from 'as'?

igrigorik: let's take this to the list to discuss

next call June 14 @ 10am -- our usual slot.

<xiaoqian> scribe: igrigorik

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: igrigorik n8s nolanlawson shubie yoav todd charles nic cathiechen xiaoqian
Found Scribe: igrigorik

WARNING: No "Topic:" lines found.

Got date from IRC log name: 31 May 2017
Guessing minutes URL: http://www.w3.org/2017/05/31-webperf-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report