[Minutes] WebPerf Group Call 31 May 2017 [was: Re: [5/31/17] webperf group call @ 10AM PST]


The minutes of this week's call are available as:

Text version:
WebPerf Weekly Call

31 May 2017


igrigorik, n8s, nolanlawson, shubie, yoav, todd, charles, nic, 
cathiechen, xiaoqian

Summary of Action Items
Summary of Resolutions
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

... element priority could be a hint to the browser to optimize 

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 

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

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


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


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.




On 2017-05-31 05:15, Ilya Grigorik wrote:
> Hangout:
> https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg [1]
> WIP agenda for this week's call:
> https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#heading=h.l20ytfqsn272
> [2]
> On a related note, there seems to be good amount of interest for a f2f
> on June 20th. The list of topics is large and growing [3] -- let's
> spend some time on the call to triage the logistics and possible
> agenda.
> If you have other topics you'd like to discuss, please leave a comment
> on the agenda—the doc is open to everyone.
> Links:
> ------
> [1] https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg
> [2]
> https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#heading=h.l20ytfqsn272
> [3]
> https://docs.google.com/document/d/1fcWpKZhJdrmBlpYUB2wIx42svo9zqojoJMZg8aY7E7Y/edit#

Received on Wednesday, 31 May 2017 18:13:21 UTC