See also: IRC log
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[End of scribe.perl diagnostic output]