LCP image loading (lazy vs eager) and the Core Web Vitals
No loading attribute, loading="lazy", or loading="eager" on the LCP image: how many sites use each, where the 177 ms lazy-load delay shows up, and whether fetchpriority="high" overrides it.
Of the sites whose LCP element is an <img>, 17.4% put loading="lazy" on that image. 74.9% leave loading at the browser default and 7.7% set loading="eager". Across all sites, 86% with a lazy-loaded LCP image and 85% with default loading have a good LCP. Fast platforms like Shopify and Wix use loading="lazy" more often. In Chrome's field data, loading="lazy" adds 177 ms of resource load delay before the image request starts (417 ms against 240 ms).
LCP pass rate
Sites with loading="eager" have a good LCP most often at 87%, followed by loading="lazy" at 86% and no loading attribute at 85%. Those overall rates sit within two percentage points of each other because Shopify and Wix put loading="lazy" on hero images far more often than WordPress does. Inside WordPress, lazy-loaded LCP images fall behind default loading.
LCP image loading usage
An <img> element is the Largest Contentful Paint element on 42.4% of all audited sites, ahead of CSS background images (29.0%) and text blocks (26.2%). Among the 83,267 sites with an <img> LCP element, 74.9% omit the loading attribute, 17.4% set loading="lazy", and 7.7% 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 240 ms to 417 ms in Chrome's field data. That is a 177 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 361 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 208 sites with both attributes still wait 503 ms before the image request starts, and 85% 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 262 ms because the preload tag starts the fetch right away. Removing loading="lazy" and adding fetchpriority="high" on a normal <img> reaches a 290 ms load delay without duplicate markup.
| loading attribute | No priority hint | fetchpriority="high" | <link rel="preload"> | <link rel="preconnect"> |
|---|---|---|---|---|
| No loading attribute (auto) | 86% 46,193 sites | 83% 13,398 sites | 85% 592 sites | 82% 2,205 sites |
| loading="lazy" | 85% 12,639 sites | 85% 208 sites | 84% 38 sites | 89% 1,622 sites |
| loading="eager" | 85% 2,831 sites | 89% 3,188 sites | 87% 80 sites | 90% 273 sites |
Understanding LCP image loading
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.
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 177 ms of resource load delay (417 ms against 240 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.
How LCP image loading plays out per platform
What the field data shows when you isolate a single CMS or framework.
WordPress 21,884 sites WordPress sites without loading="lazy" on the hero image pass LCP 5 percentage points more often than sites with lazy-loaded heroes.
WordPress 6.3+ omits loading="lazy" on the first three content images by default. Across WordPress, 80.8% of sites use default loading and 14.5% have loading="lazy" on the LCP image, with median LCP ranging from 1.8s to 2.0s (74% vs 69% good LCP).
Shopify 6,304 stores 31.2% of Shopify stores have loading="lazy" on their main banner image.
Shopify's Liquid image_tag filter omits loading="lazy" unless explicitly passed as a parameter. Across Shopify, 45.8% of stores use default loading (97% good LCP, 1.2s median) and 31.2% have loading="lazy" (97% good LCP, 1.3s median), with 96% good LCP overall.
React & Next.js 5,689 sites 19.3% of React sites have loading="lazy" on their hero component.
Next.js <Image> sets loading="lazy" by default unless priority or preload is configured. Across React sites, 89% with default loading pass LCP compared with 88% with loading="lazy".
Wix 4,113 sites 78% of Wix hero images use default or eager loading.
Across Wix sites, 71.4% of LCP images use default loading (1.2s median LCP, 94% good LCP) and 7.1% set loading="eager".
By Arjen Karel · 210,902 crawled sites (196,263 with all devices Chrome field data, 83,267 sites with an <img> LCP element by loading attribute, October 2026). How we measured.