LCP discrepancy between web-vitals and performance observer when a page becomes hidden then shown

[Simeon Totev]

Hello there!

We noticed a discrepancy of the LCP measurement by the web-vitals library (v4.0.0) in the following scenario:

1. Visit a page
2. Go to a different tab, and then return to the initial tab
3. An LCP happens that is detected by the performance observer, but not by web-vitals

If you do not do the tab switching on Step 2, then the web-vitals and performance observer will both detect the LCP.

You can see an isolated example on this video: https://drive.google.com/file/d/1RGi2y_RIDtO1s2eRxuDa57EnmvDh9M8L/view?usp=sharing

Here is also a code snippet to reproduce the results: https://codepen.io/Simeon-Totev/pen/OJYyeJa

A few questions arise:
1. Is this the expected behavior of the web-vitals library given that I haven't really interacted with the page (no clicks and no scrolls), and the LCP happened while the tab was visible (despite it being temporarily hidden before the LCP happened)?
2. How will CRUX record the LCP in such a scenario?

Cheers,

Simeon

[Simeon Totev]

Hello!

[Barry Pollard]

Yes this is expected. See the note here: 

https://web.dev/articles/lcp#differences-metric-api

• The API dispatches largest-contentful-paint entries for pages loaded in a background tab, but those pages should be ignored when calculating LCP.

You can also see this in the web-vitals library here: 

https://github.com/GoogleChrome/web-vitals/blob/27f5d87205e852d5b98cd7bb10304800a96c0fe6/src/onLCP.ts#L66

CrUX works in a similar manner ignoring any page views where the LCP was emitted after a page was hidden and made visible again.

This is all done because it’s complicated to measure LCP when a page hide is involved as the hidden time should be excluded and background pages are often throttled. As it is not easy to measure the impact of both of these we simply exclude these pages.

Barry

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/6edde2f2-f3a9-4e65-82cd-7671e523f359n%40googlegroups.com.

[Michal Mocny]

Yes, this is expected.  LCP and visibility work as follows:

• When a page starts initially in the background (i.e. "Open in new tab" option) no LCP should be recorded at all (because paints are held back and network/main thread might be throttled)
• When a page starts in the foreground LCP reports as usual.... and when visibility changes the LCP metric stops (for the same reasons as above).

I checked this article and found a note about it ("Caution: Because users can open pages in a background tab....") as well a section on "Differences between the metric and the API" which do a great job explaining.

(CLS does something similar with hadRecentInput: true.  This feature of LCP might have been more obvious of LCP entries exposed a "last-visibility-change-time: 0" or "was-loaded-in-foreground: false" or something, but, there are other ways to observe visibility changes)

 

2. How will CRUX record the LCP in such a scenario?

As above, with some more differences listed in the article (i.e. LCP measures for bfcache activation, iframes, or prerendering, all require extra work as well).

 

Cheers,

Simeon

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/fef7c7d0-c506-429e-8a94-907b2bc29f3dn%40googlegroups.com.

[Simeon Totev]

Thanks for the extra clarifications, much appreciated!