Reset LCP for Single Page App soft navigations

[nicjansma]

I'm excited about LCP, and hope it'll provide value as an "automatic" metric for websites that don't want to (or can't) annotate with ElementTiming/etc.

One thing that we're always thinking about for Boomerang with new metrics like these are how they relate to Single Page App frameworks. Specifically, many metrics are focused on the Page Load experience, then kind of "turn off" once that's happened. A lot of our customer's sites have significant user experiences after the Page Load, e.g. soft navigating between views.

LCP stops emitting candidates when the user provides input or navigates away, and my understanding is it's also only emitting candidates if they're larger than the ones before it. It would be nice if we could ask LCP to "reset", and restart the algorithm as if it's the beginning of the page load experience, with max size=0. SPA frameworks (or RUM tools like Boomerang) could then trigger this "reset" when a SPA is changing its route/view, and would get notified of LCPs from the soft nav (and not be affected by the Page Load / Hard Nav's paints)

Websites could probably also get the same effect from annotating important components of the Soft Nav with ElementTiming, but that requires site changes, and I'd love to take advantage of LCP if we can!

[npm1]

Good use case! I wonder if this sort of 'reset' would be useful in general for performance entries (not just LCP), and what the API for this would look like (we'd need to be cautious about the memory cost of restarting all performance measurements, especially if it's done frequently).

[nicjansma]

It could be useful for FP/FCP as well probably (the former instead of turning on rAF).

[yoavweiss]

We discussed this at the F2F and there seemed to be general agreement that we need to tackle the broader problem for FP, FCP, Navigation Timing, as well as provide a way to terminate in-flight requests in "soft nav" scenarios. I think that once we'd do that, LCP would be an obvious addition to that list (as well as FID, and maybe others).

[nithinnew2010]

Any updates on utilizing the Largest Contentful paint with the Boomerang?

[Guillaume-Nx]

Most websites and web apps are now mainly using soft navigations, therefore monitoring hard navigations is clearly not enough to get a good picture of what end-users experience.
Having LCP also for soft navigations would be really great and prevent implementing complex algorithms to tentatively measure load time of soft navs.

[npm1]

Indeed, we are aware that SPAs are not being properly measured by existing APIs (and this is not just the case for LCP). I think there's some complexity with LCP because:

1. LCP is meant to be somewhat 'automatic', so analytics providers can obtain values without much work. However, with SPA navs we currently don't have a standard way of 'performing' the nav so the developer would need to provide an explicit signal. And then I wonder how much value this provides on top of Element Timing, which lets you annotate elements and query the time their rendering times.

2. It is somewhat expensive to compute. Allowing a developer to reset LCP all the time may cause performance issues, which is definitely not desirable. Investigation would be required to ensure this does not become a problem.

[Guillaume-Nx]

Thanks a lot for your answer. In our case we cannot use Element Timing because we’re monitoring mainly SaaS applications so we cannot annotate elements. To palliate this we have to use alternative solutions, rather complex and no working well in all cases.

[yoavweiss]

I think we can close this as a duplicate of w3c/performance-timeline#168 and continue discussions over there.