Call back to indicate that the observer is about to stop

[DanShappir]

My understanding, per the spec, is that once the user interacts with the page, or even scrolls, LCPs will no longer be recorded via the observer. However, there is no indication of this, so the user of this API has no way of knowing that no additional LCP notifications are forthcoming.

It would be useful to have a callback on the observer, possibly identifiable using the name field, that indicates that user interaction has happened, and that no more LCPs will be recorded.

While user interaction could be identified using FID observer, that will not identify scroll. It is possible to monitor for the scroll using other APIs, but that seems a much more complicated solution.

[npm1]

I agree that this is a problem! Currently a website could just observe LCP forever (having the observer won't cost anything if it's not receiving entries), but it certainly would be useful to know when a 'final' LCP has been reached.

The complexity of this is from a design perspective. We use PerformanceObserver for this, and no other entryType has this kind of problem. So we'd basically need to create a callback unique to this entryType, which does not seem ideal. An alternative would be to re-dispatch the final LCP entry when the algorithm stops due to user input, and have a bit indicating this in the entry. That seems more feasible from my perspective, though a bit less intuitive for developers?

[DanShappir]

As far as I can tell, the name field is not currently used for meaningful information by this eventType. If this is indeed the case, a specific value in the field name could be used instead of adding a Boolean (bit) field. And indeed use the same observer callback rather than create some mechanism for having two callbacks on the same observer.

[npm1]

I think it makes sense to use the name, given that it's currently unused. We can set it to some special value and dispatch the largest entry again when user input occurs and we know the 'final' LCP value.

[philipwalton]

Hmmm, I'd be hesitant to use the name field for something that's not a name. Other than that, I think re-dispatching an entry as soon as the final value is known makes a lot of sense.

[npm1]

Well, what is a name? :) For instance, on Paint Timing it is used to distinguish first-paint from first-contentful-paint. But fine, if name is deemed inappropriate then we could add a new attribute.

[paulirish]

I was hoping that the first-input entries with PO would indicate this, but they don't fire on trusted scrolls, so it's not a reliable signal. :/

[patrickhulce]

I have a proposal to address the broader "when is an LCP a real LCP" problem.

Give name two possible values: largestContentfulPaintCandidate and largestContenfulPaint

largestContentfulPaintCandidate is essentially all the events that are emitted today. Any new computation of a largest contentful paint issues this event.

largestContentfulPaint is a new event that is only emitted when two conditions have been met:

1. We are certain that no more LCPCandidates will ever be issued again for this page load.
2. We are at least reasonably confident that no more LCPCandidates would have been issued if user input had not occurred.

I know thus far this issue has primarily discussed the problems with detecting item 1, but item 2 seems equally important to not mistake early LCP events for the actual LCP. In scenarios with poor network and device quality this leads to misleading conclusions that attribute FCP to the LCP value and give a falsely rosy picture of page performance.

This amounts to creating an absolute stopping point for LCP computation irrespective of user input. If user input occurs before that point then the page has an "unknown" LCP. At a minimum I'm thinking that there shouldn't be any inflight requests for above the fold images with an unknown size or known size larger than the previous largest element, maybe more aggressive network quiet and/or cpu quiet windows as well? Something to think about.

[npm1]

I'll be presenting this idea probably in the next WebPerf WG call. Slides: https://docs.google.com/presentation/d/1Ll8hMdr7SIqIKLWYf6Nw-5dJQha45BsNQWVHQDzAiSI/edit#slide=id.p

[npm1]

An update here: we presented the final LCP proposal but have decided not to move forward with it for now because most analytics providers currently dispatch their metrics at early points in time during the page load, like onload. They would not be able to use final-LCP because it may not have dispatched at this time, so using the latest candidate is probably better. As for a signal about when input or scroll has occurred, I don't think there is an easy one right now, but I'm not sure LCP is the right spec to discuss this. @flackr do you know what would be a good place to add a feature request for a signal about the user having scrolled the page (maybe ScrollObserver)?

[clelland]

Ping @flakr :) Would you have any thoughts on a way to signal to a page that the user has ever scrolled?