Re: WG design call - April 12th @ 11am PST

(Just realized this email was never sent after the April 12th call.

Hey all,

and video <> from the call are now available.
Copying them here for safe keeping.


WebPerfWG design meeting - April 12th 2019


Steven Bougon, Gilles Dubuc, Phillippe Le Hegaret, Nicolás Pena, Maxime
Villancourt, Tim Dresser, Benjamin De Kosnik, Ryosuke Niwa, Andrew
Comminos, Markus Stange, Nic Jansma, Todd Reifsteck, Yoav Weiss

Face to Face:

   - We need to notify everyone 8 weeks in advance.
   - No date nailed down yet.
   - Web Games workshop at the end of June

Next call dates:

   - Tuesday April 23th @ 9:00am PST

Largest Contentful Paint: slides

   - Improves on FCP
   - Looks at the largest text or image.
   - Stop looking at input or page unload.
   - Heuristics:

   - Ignore removed elements.
   - Ignore background images attached to the body.

   - Mobile:

   - Most mobile pages have at least one large image.

   - Desktop:

   - May have more page with large text elements.

   - Ryosuke: why is this important?
   - Tim: We have had lots of feedback that FCP isn’t sufficient. Element
   timing is strictly better than LCP, but not everyone will manually annotate
   for element timing.
   - Ryosuke: It seems like this is just heuristics. If developers don’t
   take the time to annotate their websites for ET, why would they care about
   - Yoav: This isn’t just a bunch of heuristics, we’re trying to find the
   largest element, under the assumption that it is meaningful for the user.
   There are heusristics related to size of text elements, meaningfulness of
   BG images, but eventually, we want to use size as a proxy for importance.
   - Todd: I think the question was “are people asking for this?”
   - Ryosuke:

   - Do people want this? Will people use this?

   - Nicolás: FCP is widely used and we get a lot of complaints that it’s
   not enough, so no doubt there’s a need
   - Tim: maybe we need to gather additional data to prove this fills that
   - Ryosuke:

   - Safari doesn’t even paint until we think the majority of the web page
   has painted.
   - First contentful paint should be equivalent to largest contentful

   - Nicolás: Is that also true for splash screens?
   - Ryosuke: won’t that be counted?
   - Nicolás: That’s why we ignore removed elements
   - Tim: maybe we should grab some filmstrips from Safari, and eyeball
   what this metric would do there?
   - Ryosuke: What Safari aims to do is avoid paint, keep the user looking
   at the previous screen, until we have enough to paint something meaningful.
   So this metric will be implementation specific with regards to when things
   are painted. I can see this being useful in Chrome, but not in Safari.
   - Todd: At MS, lots of things are built in React, with 3-5 phases of
   rendering, and only hit “useable” at the 4th phase. IIUC, this API intends
   to cover some of those scenarios as well.
   - Tim: yeah. Would going over Safari filmstrips be useful?
   - Ryosuke: It may be useful, but we’ll consider any difference between
   this metric and FCP as a bug. Safari wants to wait until the main content
   has painted.
   - Gilles: There’s no conclusion if progressive rendering is better than
   waiting. Otherwise, regarding exceptions around user interaction and
   scrolling, how much data do we discard?
   - Nicolás: we don’t discard, we just report the earlier example.
   - Gilles: How can we avoid bias? You’d be different measurements based
   on user behavior.
   - Tim: Hoping that e.g. 90%ile data will be clean, but we can do more
   research there.
   - Nicolás: We can discard those cases based on timing.
   - Gilles: what’s the attribution story?
   - Nicolás: We expose rects, intrinsic sizes, urls as reported by RT, id
   when it’s there. Wondering what attribution is required for this to be
   - Tim: this is different from what Safari does because we can calculate
   it retroactively, where the browser can’t do that while painting. So I’d
   expect differences.
   - Ryosuke: For this to be useful to webdevs, we want a metric that is
   useful in all browsers. Usecase of wanting to identify when important
   things have painted makes sense. Suppose you’re writing an editor app,
   where you first paint a splash screen. The splash screen is a big image.
   The editor content is empty. What would the metric do?
   - Yoav: The page will not be a single element which is completely white.
   Ryosuke - IIUC, this metric and FCP will be very close in Safari?
   - Ryosuke: I think so.
   - Yoav: So Safari will still show this metric very close to Chrome’s
   implemention of it, it’s only FCP that will be significantly delayed, right?
   - Ryosuke: you can see it that way.
   - Tim: There’s certainly developer demand for something like this. What
   would be alternatives we can take?
   - Benjamin: What about last contentful paint?
   - Tim: We don’t want to penalize continuous updates and lazy loading.
   Motivated engineers can create their own metrics using Element Timing.
   - Yoav: and the goal with this metric is to gather that data for the
   majority who won’t annotate their elements.
   - Tim: Ryosuke, any alternatives?
   - Ryosuke: the idea to measure this has come up multiple times, and we
   always didn’t find a good algorithm for this. This is just a bunch of
   - Tdresser: Element Timing as a primitives will help us reach a
   different outcome. FMP was a bag of heuristics. We should solve the problem
   even if the solution is not perfect.
   - Ryosuke: heuristics may change in the future.
   - Nicolás: reasons for heuristics is to exclude some of the images. This
   is not a black box of heuristics. We want to use the size of the image as a
   proxy for its relevance.
   - Ryosuke: the correlation between size and importance is a heuristic in
   - Yoav: I’d be uncomfortable if we said that this is a problem we cannot
   solve. Developers continuously ask for this.
   - Gilles: maybe ET usage can help guide us towards the right solution.
   This is a lot of guesswork. It will probably not work for many other sites.
   - Steven: we sell a platform for our customers to create their pages,
   where ET will not work.
   - Gilles: yeah, but we should give more time for ET to be used. This is
   making a lot of assumptions regarding the user interaction model. This
   reminds above-the-fold synthetic metrics. Maybe the future is that people
   interact more and more early. Input limitation is a problem. So need a
   metric that captures that interaction as well.
   - Nicolás: We saw data saying that this is better than FCP
   - Steven: We sell a platform where customers add components, and want to
   measure it even if they don’t annotate.
   - Gilles: we still haven’t given developers a chance to experiment and
   find patterns that work, which can inform a high-level metric design. This
   is assuming a lot of the user interaction model and how users behave. This
   metric becomes less useful as people interact earlier. We need to also
   capture elements that are below the initial viewport.
   - Ryosuke: can imagine a webapp where users scroll early to the content
   they care about
   - Ryosuke: did you look at pages already using element timing, and seen
   how well this matches up with LCP?
   - Tim: very few websites use ET today, but we should look at that.
   - Yoav: from an analytics provider’s perspective, does this make sense?
   - Nic: we need something that doesn’t require manual annotation.
   Generally excited about this, but we’d need to think through the
   implications of user input stopping the updating of this metric. We’d need
   to log when interactions occurred as well. But onboard with getting
   something like this.
   - Yoav: what I hear from folks is:

   - Concern from folks around input and abort bias.
   - Heuristics: how comfortable are folks with a heuristic based approach
   where the intent is declared, but the heuristic calculation itself is UA

   - Markus: ideally any heuristics would live in the page, and the page
   would do the annotation etc. This isn’t feasible though. We’ll need some
   heuristics in the browser.
   - Ryosuke: it would be better if the heuristics lived in the analytics
   - Nicolás: we could relax the constraints and emit more ETs, so that
   analytics providers can calculate this retroactively.

<out of time>

On Fri, Apr 12, 2019 at 3:31 AM Yoav Weiss <> wrote:

> Hey all,
> Join us tomorrow for a WG call and talk about new feature designs.
> On the agenda
> <>
> for tomorrow we currently have discussions about Element Timing and Largest
> Contentful Paint. Feel free to add more items to the agenda if there's
> something else you'd like to discuss.
> The hangout for the call would be the usual one
> <>.
> See y'all tomorrow,
> Yoav

Received on Monday, 22 April 2019 20:45:48 UTC