New audit: prioritize-lcp-image focusing on Priority Hints

Feature request summary

tl;dr rename the preload-lcp-image audit to prioritize-lcp-image, and update it to recommend the use of Priority Hints (shipping in Chrome 101) in cases where the LCP image is found within the main document but queued after other resources.

What is the motivation or use case for changing this?

Currently, the preload-lcp-image does not apply to cases where the LCP image was discoverable from within the main document (see relevant audit logic).

This potentially misses a big opportunity for sites to improve LCP because in many cases—even though those elements are discoverable from the main document—they’re fetched with a low priority and often end up queued up waiting for other resources to finish.

Here’s an example of that happening on httparchive.org

In this screenshot you can see that the LCP image (the red outline) is discovered immediately, but it’s assigned a “low” priority, so it still gets queued after other resources (e.g. font/stylesheets). In other words, there is clear opportunity to start loading the LCP image sooner, but Lighthouse currently does not highlight this opportunity.

If this site were updated to use Priority Hints and added fetchpriority="high" to the LCP image tag, the trace would look like this:

Notice how now the image is fetched in parallel with the fonts and stylesheets, and LCP happens at the same time as FCP.

As for what the opportunity value should be: my suggestion is to take the delta between the startTime of the first resource and the requestStart of the LCP resource. Note that I recommend looking at requestStart rather than startTime for the LCP resource because startTime can be the point when the resource was queued (as in the first screenshot above), and the time that’s important is the time the network request started.

How is this beneficial to Lighthouse?

The current preload-lcp-image audit misses lots of opportunity to improve. I recently analyzed all mobile page loads in HTTP Archive where LCP was an image (5M pages) to look at the time delta between when the first resource started loading and when the LCP resource started loading, and those times were surprisingly high.

Passed preload-lcp-audit ?	AVG time between 1st resource start and LCP resource start as a % of total LCP time
TRUE	38.4%
FALSE	55.5%

This table shows that pages that pass the audit are doing better than pages that do not pass it, but even for pages that pass the audit, a substantial amount of total LCP time is spent waiting for the LCP resource to start loading.

cc: @paulirish since we discussed this yesterday.

[pmeenan]

FWIW, preload helping may also be specific to Chromium (at least in most cases). Chromium is the only engine with the 2-phase loading where it holds back requests for low-priority resources before the parser gets to the body (as long as there are any other high-priority requests in flight, low priority won’t be requested).

Webkit and Gecko both fetch resources as soon as they are discovered, assuming the HTTP/1 connection limit hasn’t been reached.

[philipwalton]

@philipwalton should we update https://web.dev/optimize-lcp/ too?

Yeah, I plan to update that post ahead of I/O (to coordinate with some other recommendations).