Warn about LCP inflated by background loading

[rviscomi]

If I open a new tab in the background, and wait ~15 seconds before switching over to it, then LCP will be at least 15 seconds. From a UX perspective, the page appeared almost instantly, so a "slow" LCP value like this is not representative.

However, this seems to be a feature (not a bug) of the API because it's documented at web.dev/lcp:

Caution: Since users can open pages in a background tab, it's possible that the largest contentful paint will not happen until the user focuses the tab, which can be much later than when they first loaded it.

It'd be useful if this extension annotated LCP in some way to indicate that the value was inflated by the amount of time the page was in the background. If complete=true and active=false then the annotation would be useful. If needed we could also use the difference in time between complete=true and the activation change as a heuristic.

[addyosmani]

It'd be useful if this extension annotated LCP in some way to indicate that the value was inflated by the amount of time the page was in the background.

I think this is an interesting idea. One option would be to introduce some notion of diagnostic information about each metric below it (similar to this mock).

My only concern would be how busy this gets. Another idea is we could treat each metric as <details> and this additional information is only shown on expansion so it's not too distracting. Or we could do what Lighthouse does and "extra info" is treated as a toggle.

[rviscomi]

Yeah any of those options sound good to me.

[addyosmani]

Cool. I'm happy to explore some UI affordances for this after I wrap up work on the overlay.

I've been very surprised at the extent to which LCP gets inflated due to backgrounding. Today I experienced a tab where LCP got inflated by 15 seconds. Oof.

[philipwalton]

I think this issue has already been resolved in the extension, but to provide a bit more context, this is a known issue that exists in the web API, but most libraries and tools that track LCP (and FCP) already account for it:

Here are a few of the open spec issues discussing the issue (across multiple specs):

• surprising (if not understandable) results for first-paint when document.visibilityState === 'hidden' w3c/paint-timing#40
• Log if a page was ever visible w3c/page-visibility#29
• PerformanceEntries are affected by backgrounded status w3c/performance-timeline#105

Since this extension uses web-vitals under the hood, it should no longer have this problem since web-vitals will not report the metric if the page was loaded in the background.

[addyosmani]

@philipwalton @rviscomi

I've tried a few different approaches locally for solving this problem (or rather, consistently indicating a value may have been bloated due to the tab being backgrounded). Unfortunately, I have found the usual approaches (Page Lifecycle API, Page Visibility etc) behave inconsistently in an extension context.

I believe web-vitals.js may also suffer from this as I'm seeing these kinds of values with tabs loaded in the background, though this won't be a problem for normal use of the library:

There are some simple, but potentially effective? ideas for helping navigate developers through these problems in the short term:

• For a surprisingly high value of N for LCP (e.g LCP > 100s), display a line of text in the pop-up saying "High LCP value may be due to tab backgrounding. Reload page"
• The above, but just as a note in the README

[housseindjirdeh]

Unfortunately, I have found the usual approaches (Page Lifecycle API, Page Visibility etc) behave inconsistently in an extension context

Agreed that their behavior seemed finicky within an extension. Took a slightly different approach in #31 to only show the message when a tab is reloaded in the background.