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 81 ms of resource load delay (390 ms vs 309 ms) and when <link rel="preconnect"> pays it back.
21.5% of sites use third-party LCP image hosting, and 85% of those sites have a good LCP, against 82% of all sites.
LCP pass rate
Sites with third-party LCP image hosting have a good LCP most often: 85%, against 82% of all sites. Sites with first-party image hosting have it least often, at 82%.
LCP image hosting usage
First-party is the most used: 78.5% of sites. Third-party is 21.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 third-party and first-party sits in time to first byte (TTFB): 517 ms median for third-party against 709 ms for first-party. Overall median field LCP is 1.5s for third-party (TTFB 517 ms, load delay 390 ms, load duration 137 ms, render delay 218 ms) versus 1.6s for first-party.
LCP image origin combined with preconnect and priority hints
Combining third-party with Preconnect reaches 87% good LCP across 6,276 sites (368 ms median load delay). At the other end, third-party paired with Preload sits at 78% across 604 sites (339 ms median load delay).
| Image origin | No priority hint | <link rel="preconnect"> | fetchpriority="high" | <link rel="preload"> |
|---|---|---|---|---|
| Same-origin / first-party | 81% 97,715 sites | 85% 404 sites | 83% 11,245 sites | 82% 2,911 sites |
| Third-party domain | 84% 18,035 sites | 87% 6,618 sites | 87% 5,471 sites | 78% 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 390 ms median resource load delay compared with 309 ms for first-party images (81 ms slower to start), even though dedicated image CDNs finish the download slightly faster (137 ms vs 151 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 397 ms before the download starts, while pairing a third-party image with <link rel="preconnect"> cuts resource load delay to 368 ms and lifts good LCP from 84% to 87%.
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 (70% good LCP).
Across WordPress sites, 94.5% serve the LCP image from the first-party document origin (70% good LCP) and 5.5% serve it from an external origin (69% good LCP).
React & Next.js 7,170 sites 72.0% of React & Next.js sites load LCP media from external image origins (92% 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 (92% good LCP, 1.3s median) and 28.0% load it from the application origin (65% good LCP, 2.1s median).
By Arjen Karel · 210,902 crawled sites (196,263 with all devices Chrome field data, 143,029 sites with LCP image hosting, October 2026). How we measured.