LCP image origin (first-party vs third-party domain) and the Core Web Vitals
Serving the hero image from your own domain versus an external image CDN: how a separate connection adds 75 ms of resource load delay (340 ms vs 265 ms) and when <link rel="preconnect"> pays it back.
78.5% of sites use first-party LCP image hosting, and 86% of those sites have a good LCP, against 86% of all sites.
LCP pass rate
Sites with first-party LCP image hosting have a good LCP most often: 86%, against 86% of all sites. Sites with third-party image hosting have it least often, at 86%.
LCP image hosting usage
First-party is the most used: 78.5% of sites.
Where third-party LCP images lose and win time: the four LCP phases
Across the four LCP sub-parts in Chrome's field data, the largest gap between first-party and third-party sits in time to first byte (TTFB): 600 ms median for first-party against 513 ms for third-party. Overall median field LCP is 1.4s for first-party (TTFB 600 ms, load delay 265 ms, load duration 114 ms, render delay 195 ms) versus 1.5s for third-party.
LCP image origin combined with preconnect and priority hints
Combining third-party with Preconnect reaches 88% good LCP across 1,835 sites (334 ms median load delay). At the other end, third-party paired with Preload sits at 84% across 252 sites (251 ms median load delay).
| Image origin | No priority hint | <link rel="preconnect"> | fetchpriority="high" | <link rel="preload"> |
|---|---|---|---|---|
| Same-origin / first-party | 86% 97,715 sites | 86% 404 sites | 87% 11,245 sites | 85% 2,911 sites |
| Third-party domain | 85% 18,035 sites | 88% 6,618 sites | 86% 5,471 sites | 84% 630 sites |
Understanding LCP image origin
Why third-party hero images pay a connection tax in resource load delay
When the LCP image lives on the same origin as the HTML document, the browser reuses the open HTTP/2 or HTTP/3 connection immediately. When the image sits on a separate domain, Chrome must resolve DNS, complete a TCP or QUIC handshake, and negotiate TLS before requesting the first image byte. That handshake shows up directly in Chrome's field data: third-party LCP images have a 340 ms median resource load delay compared with 265 ms for first-party images (75 ms slower to start), even though dedicated image CDNs finish the download slightly faster (115 ms vs 114 ms).
Serve the LCP image from the same origin as your HTML document whenever possible, so the image rides the already-open HTTP/2 or HTTP/3 connection. If you use a dedicated image CDN on a separate domain (21.5% of audited sites), add <link rel="preconnect" href="https://your-cdn.example" crossorigin> in the document <head>. In Chrome's field data, third-party LCP images without a hint wait 354 ms before the download starts, while pairing a third-party image with <link rel="preconnect"> cuts resource load delay to 334 ms and lifts good LCP from 85% to 88%.
How LCP image hosting plays out per platform
What the field data shows when you isolate a single CMS or framework.
WordPress 49,695 sites 94.5% of WordPress sites serve their LCP image from the same origin (75% good LCP).
Across WordPress sites, 94.5% serve the LCP image from the first-party document origin (75% good LCP) and 5.5% serve it from an external origin (73% good LCP).
React & Next.js 7,170 sites 72.0% of React & Next.js sites load LCP media from external image origins (88% good LCP).
Next.js <Image> supports custom loader functions for external image CDNs. Across React sites, 72.0% load the LCP image from an external origin (88% good LCP, 1.3s median) and 28.0% load it from the application origin (71% good LCP, 1.8s median).
By Arjen Karel · 210,902 crawled sites (69,745 with desktop Chrome field data, 143,029 sites with LCP image hosting, October 2026). How we measured.