LCP image loading on React sites
No loading attribute, loading="lazy", or loading="eager" on the LCP image: how many sites use each, where the 36 ms lazy-load delay shows up, and whether fetchpriority="high" overrides it.
Of the React sites whose LCP element is an <img>, 19.3% put loading="lazy" on that image. 73.6% leave loading at the browser default and 7.1% set loading="eager". Across React sites, 89% with default loading and 88% with a lazy-loaded LCP image have a good LCP. In Chrome's field data, loading="lazy" adds 36 ms of resource load delay before the image request starts (471 ms against 435 ms).
LCP pass rate
Sites with loading="eager" have a good LCP most often at 89%, followed by no loading attribute at 89% and loading="lazy" at 88%. Within React, default loading and loading="lazy" have a good LCP about equally often.
LCP image loading usage
An <img> element is the Largest Contentful Paint element on 60.6% of audited React sites, ahead of CSS background images (14.6%) and text blocks (22.7%). Among the 5,689 React sites with an <img> LCP element, 73.6% omit the loading attribute, 19.3% set loading="lazy", and 7.1% set loading="eager".
Where lazy LCP images lose time: the four LCP phases
Putting loading="lazy" on the LCP image raises median resource load delay from 435 ms to 471 ms in Chrome's field data. That is a 36 ms wait before the browser starts downloading the image. Without loading="lazy", Chrome's preload scanner queues the <img> as soon as it reads the HTML. With loading="lazy", Chrome holds the request back until layout confirms the image sits in the viewport. Sites with loading="eager" show a 452 ms load delay in the field because many of them also preload other assets or load the hero image from a script.
LCP loading combined with fetchpriority and preload
Adding fetchpriority="high" to a lazy-loaded LCP image does not fix the lazy-load delay. The 90 sites with both attributes still wait 566 ms before the image request starts, and 89% have a good LCP. In Chromium, ShouldDeferImageLoad runs before resource priority is assigned, so the request stays deferred until layout. Pairing loading="lazy" with a <link rel="preload"> tag cuts the field load delay to 218 ms because the preload tag starts the fetch right away. Removing loading="lazy" and adding fetchpriority="high" on a normal <img> reaches a 452 ms load delay without duplicate markup.
| loading attribute | No priority hint | fetchpriority="high" | <link rel="preload"> | <link rel="preconnect"> |
|---|---|---|---|---|
| No loading attribute (auto) | 77% 779 sites | 92% 3,194 sites | few sites | 87% 199 sites |
| loading="lazy" | 89% 990 sites | 89% 90 sites | few sites | few sites |
| loading="eager" | 90% 325 sites | 87% 71 sites | few sites | few sites |
LCP image loading per platform
Wix puts loading="lazy" on the LCP image on 22% of its sites, and 94% of Wix sites have a good LCP. WordPress leaves the LCP image at the browser default on 77% of its sites and sets loading="lazy" on 18%, and 61% of WordPress sites have a good LCP.
Wix 4,113 sitesNo loading attribute (auto) 71%loading="lazy" 22%94%
WordPress 853 sitesNo loading attribute (auto) 77%loading="lazy" 18%61%LCP image loading or the platform
Does the platform explain the loading="lazy" pass rate?
On Wix, 94% of sites with default loading have a good LCP, against 94% of Wix sites with loading="lazy" on the LCP image. Within Wix, sites with default loading and loading="lazy" have a good LCP about equally often. On WordPress, 65% of sites with default loading have a good LCP, against 58% of WordPress sites with loading="lazy" on the LCP image. Within WordPress, sites with default loading and loading="lazy" have a good LCP about equally often.
Why loading="lazy" holds back the preload scanner
Chrome's HTML preload scanner finds <img> tags in the first bytes of the document. It starts fetching default and eager images right away, before stylesheets and blocking scripts finish downloading. When an <img> carries loading="lazy", Chromium's ShouldDeferImageLoad check stops the preload scanner from queuing the request. The image waits until CSS downloads, the render tree builds, and layout confirms the image sits in the viewport. WordPress core has skipped loading="lazy" on the first three content images since version 6.3. Theme templates and page builders that hardcode loading="lazy" on hero banners still pay the full layout wait.
Understanding LCP image loading
Leave the loading attribute off the LCP image, or set loading="eager", and pair it with fetchpriority="high". Never put loading="lazy" on an image in the initial viewport. In Chrome's field data, loading="lazy" adds 36 ms of resource load delay (471 ms against 435 ms for default loading). Adding fetchpriority="high" on top of loading="lazy" does not fix that delay, because Chromium decides whether to defer the image before it applies resource priority. Omitting the loading attribute and setting loading="eager" do the exact same thing in the browser: both fetch the image right away. Omitting the attribute is cleaner, and fetchpriority="high" raises the network priority from Low to High before layout runs.
By Arjen Karel · 9,570 crawled React sites (9,110 with all devices Chrome field data, 5,689 sites with an <img> LCP element by loading attribute, October 2026). How we measured.