Suggesting which sub-resources to consider for Early Hints

[KenjiBaheux]

Feature request summary
Early Hints is a preliminary HTTP status code to indicate to the client that the server is likely to send a final response with the header fields included in the informational response. This is particularly compelling * in combination with LINK REL PRELOAD or PRECONNECT HTTP headers as a way to get the client to proactively prefetch/preconnect critical resources/origins while the server is busy generating / retrieving the main response.

We did an experiment with external partners and saw some significant improvements to LCP. That said, the benefits is really a function of what the Early Hints are used for. For instance, fetching a low-priority async JS is probably not the best use of this API.

So, I was wondering if Lighthouse could play a role in:

• raising awareness of this feature when it launches
• suggests reasonable resources/origins to consider sending via Early Hints based on a dependency chain for LCP.

I can help with product related aspects if needed.

What is the motivation or use case for changing this?
While Early Hints is inherently designed to avoid H2 Push's overpushing flaw (i.e. pushing assets that the client already has), it still has some potential sharp edges (e.g. link rel preload/preconnect to non-critical resources/origins). Having lighthouse offer guidance would likely avoid sub-optimal usage or even downright perf-negative usage.

How is this beneficial to Lighthouse?
I believe that providing actionable insights with significant wins on LCP would be welcomed by lots of Lighthouse users.

[connorjclark]

We're actively working on redoing all our preload advice, including adding early hints, hopefully all to land for 10.0

#13738 has some discussion (but limited to LCP image)

[addyosmani]

Now that we're further along with the rollout for Early Hints, it may make sense to form an opinion on whether a Lighthouse audit would make sense here framed as an LCP benefit. A key part for us (related to the re-work of preload and priority hints) is how to get the framing right so we're not confusing developers. It certainly does help that EH doesn't have quite the same footguns as we saw with H/2 Push.

https://developer.chrome.com/blog/early-hints/
https://twitter.com/Cloudflare/status/1546180450988834816
https://twitter.com/colinbendell/status/1539322190541295616

[philipwalton]

The biggest benefit of Early Hints is on sites that need to do a decent amount of server processing, but where they likely know ahead of time that:

1. Certain critical resources will be requested (e.g. stylesheets, fonts, images)
2. Certain origins will be used (e.g. an image CDN, font CDN, etc.)

If Lighthouse could (with reasonable certainty) detect cases where the page load had relatively high server processing times, then I think it would make sense to recommend the use of Early Hints in those cases. Especially if the LCP resource (or any render-blocking resource) is hosted on a different origin.

On the other hand, I do not think Lighthouse should recommend Early Hints in general because I could easily see that leading to a situations where developers send Early Hints in cases where they don't need to (or worse, for every single resource, like what we saw with over-preloading).