[LCP] Audit if eager stop of LCP is correct for cases where LCP is in-flight

[mmocny]

Today web-vitals.js will automatically stop the LCP algorithm in cases of measured discrete interaction. The list of interactions that we support is limited, and doesn't include all event types nor scroll.

But one thing I'm also not sure about:

• When the LCP algorithm stops, I think it stops accepting new candidates
• Any existing candidates still get measured to presentation time.

Specifically, I'm wondering about cases where a large image is still loading, or still decoding.

Its possible that PerformanceObserver.tageRecords() will not return entries, but there are still entries "in flight".

(Note: There are similar issues with Event Timing and timings in-flight. Perhaps PerformanceObserver API should also have an async version of takeRecords() which will flush and report one last time...)

[tunetheweb]

Specifically, I'm wondering about cases where a large image is still loading, or still decoding.

I'm not sure there's a good answer here. Think of the following edge cases:

• The in-flight image is half off-screen. The user scrolls while it's still loading and it's completely on-screen now and is larger than the previous LCP. Should that be the new LCP even though it occurred after user input when the LCP element was still on screen? I'd argue not (and it wouldn't have been if the user had waited a little longer to scroll).
• Similarly an in-flight off-screen image that is loaded (either because of no lazy loading, or within lazy-loading viewport thresholds) can now be eligible.
• Or imagine the reverse where an image is inflight and is going to be the LCP element but then the user screens down and nothing is painted. In this case the LCP entry would presumably not fire? But if you're saying in-flight resources should be eligible than that seems kinda inconsistent.

So I'm not sure the PO should fire in these cases, and that the web-vitals.js logic isn't the correct one to go with...

[mmocny]

I think you may have misunderstood my question-- I'm just saying that Chrome has already decided on answers to these questions and web-vitals shouldn't be making different decisions. Even if we want to change the answers, we should still try to synchronize.

I don't for sure yet if it differs, that's why I would like a (quick?) audit!

---

Here's what I think happens today:

• images which have already been rendered (I mean on the main thread stage of rendering) and
• have already been marked as lcp candidates, and
• we are still waiting for their presentation times as they get decoded...

I believe you are effectively guaranteed to get a next presentation time for that image, and an element timing / LCP entry for it, even if you scroll. That is because there is already a main-thread rendering update in the rendering pipeline and the presentation time will be the time that update is included in a screen update. I don't believe we necessarily track if the image was still within viewport at that point.

In other words, I suspect the LCP-halt-on-interaction heuristics stops new candidates from being queued up for measurement, rather than stopping LCP results from being added to timeline.

Not sure!

[mmocny]

Finished Audit. Looks like although image paints are measured until presentation time, even after input or scroll, those times end up discarded. The LCP calculator uses the main thread InputOrScroll time as the last point to capture recorded LCP times.