[LCP] Add Recommendation to use the same domain as the root/site one for LCP Images in order to reduce LCP timing

[gilbertococchi]

Serving LCP Images from non Root Site domain implies significant additional latency for sites and this may impact the likehood to meet the LCP threshold in the Lab and Field.

I believe Developers would find useful to see this opportunity exposed among the other audits exposed for LCP Images optimization.

[Dandi84]

It would be extremely useful!

[brendankenny]

This is definitely a situation Lighthouse should highlight more prominently. Possibly a new audit, or it might make more sense to broaden uses-rel-preconnect to suggest bringing everything onto the same origin, and only if that's not possible suggest preconnecting.

[mcmd]

Hi brendankenny! Is there an update in this issue? Thanks!

[paulirish]

it might make more sense to broaden uses-rel-preconnect to suggest bringing everything onto the same origin, and only if that's not possible suggest preconnecting.

The obvious alternative to moving everything to the root origin is.... static assets are served on a static.somedomain.com host PLUS a preconnect. (Even better, advertise the preconnect in either the Link response header or Early Hints).

From a developer effort/difficulty POV, moving the image host under the same origin is likely pretty challenging for large hosts. (All the ones I know keep all static assets on a separate hostname). (Admittedly adopting early hints is not easy either).

All that to say, I think I'd favor a more aggressive preconnect audit than this origin-consolidation recommendation.

From a purely webperf POV, I think using this "obvious alternative" is arguably as good or better than a 1-origin setup. CDNs got plenty of benefits beyond just latency. And the time for the extra TCP connection should be mitigated by the preconnect (especially if its an early hint or link header)

[paulirish]

The "LCP Request Discovery" Insight is all about discovering the LCP req:

• fetchpriority=high is applied
• (one of these):
  • Network initiated during preloadscanner (in the HTML as an <img>)
  • Preload directive applied
• Lazyload not applied

---

My above comment comes out on the side of "lets just recommend preconnect more aggressively".

Preload is even better and the LCP Req Disc insight captures that. I guess the important thing is that its docs spell out that preconnect is OK if you don't have a predictable URL.

[gilbertococchi]

Hi Paul, I wanted to recommend developers something different here: if possible, serve the LCP Image from the same domain/origin as the root page.

I agree that preconnect is helpful but it should be overall better to serve the image via the same domain as the root one to fully reduce that network delay, do you agree?

From HTTP Archive I've noticed many sites serving images (or CSS/JS) from different domains for old/legacy HTTP1 related reasons and many of them struggle to get rid of this custom domain.