Participants:

Steven Bougon, Gilles Dubuc, Phillippe Le Hegaret, Nicolás Peña, 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 (Nicolás)

• 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 this?
• 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 gap.
• 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 paint.

• 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 useful.
• 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 heuristics.
• 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 itself
• 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 defined?

• 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 provider.
• Nicolás: we could relax the constraints and emit more ETs, so that analytics providers can calculate this retroactively.

<out of time>