New audit: LCP element was lazy-loaded

[rviscomi]

Feature request summary

I'd like to see a new performance or best practices audit that fails if the LCP element was lazy-loaded.

What is the motivation or use case for changing this?
Lazy-loading images above the fold may adversely affect LCP performance.

How is this beneficial to Lighthouse?
It identifies an opportunity to improve the performance of LCP, a Core Web Vital metric.

[patrickhulce]

We'll do it! 🎉

Any of our 20%ers up for tackling this? High impact and straightforward change! :)

@jckr or @milutin perhaps?

[milutin]

I quickly drafted a solution, let me know if I captured your idea correctly. I will do tests, titles, descriptions, ... if you are ok with my proposed solution.

[connorjclark]

We'll do it!

Some issues I've thought of, were these discussed? Any notes worth sharing?

• Deep-linking (anchor or test fragment) exists, but LH discards the fragment before auditing so this isn't introducing a new issue.
• Will any FR snapshot or timespan mark this audit n/a? Otherwise, if the scrollbar position is not 0, an image element which is normally not the LCP element could be the LCP element for that snapshot run. Which essentially means LH suggests large images (Well, the largest image for any given viewport) should never be lazy loaded. Is "do not lazy load every possible LCP image in every viewport, just in case deep links are used" good advice?

[adamraine]

Will any FR snapshot or timespan mark this audit n/a? Otherwise, if the scrollbar position is not 0, an image element which is normally not the LCP element could be the LCP element for that snapshot run.

@milutin's implementation wouldn't be available in snapshot mode since it gets the LCP element from the trace. Are you suggesting this could apply to the largest image in the viewport instead of just the LCP element?

[brendankenny]

Some issues I've thought of, were these discussed? Any notes worth sharing?

• Deep-linking (anchor or test fragment) exists, but LH discards the fragment before auditing so this isn't introducing a new issue.

LH will test a URL with a fragment and correctly pick out the LCP from that lower viewport. The fragment is stripped from the finalUrl, unfortunately, since we get that from the protocol.

• Will any FR snapshot or timespan mark this audit n/a? Otherwise, if the scrollbar position is not 0, an image element which is normally not the LCP element could be the LCP element for that snapshot run. Which essentially means LH suggests large images (Well, the largest image for any given viewport) should never be lazy loaded. Is "do not lazy load every possible LCP image in every viewport, just in case deep links are used" good advice?

Agreed that it's a probability game, with the current assumption that the top of the page is what most users see on first load, but that's not always true. @philipwalton sometimes brings up a page on his blog where almost all visitors are deep linked into a particular heading, so they almost all get a different LCP than what's in the top of the page.

So without a scroll we risk optimizing poorly for pages where most users start scrolled, and with a scroll we risk the opposite.

Notably this is also true for our existing positive advice, like recommending lazy loading images outside of the viewport (which viewport?), when/if we ever recommend preloading LCP images again, or, much more indirectly, prioritizing opportunities to optimize for what we think is the LCP, possibly at the expense of other critical paths to LCPs of other views of the page.

This could be a good future opportunity for an analytics/RUM <-> lighthouse development loop, where devs could set up CI to test common paths that their users actually visit (a la #1453). Future FR tie in? :)

Maybe worth discussing the immediate issue in Monday/Tuesday meeting(s)?