Wix LCP image loading and the Core Web Vitals
No loading attribute, loading="lazy", or loading="eager" on the LCP image: how many sites use each, where the 8 ms lazy-load delay shows up, and whether fetchpriority="high" overrides it.
Of the Wix sites whose LCP element is an <img>, 22.2% put loading="lazy" on that image. 70.6% leave loading at the browser default and 7.2% set loading="eager". Across Wix sites, 94% with default loading and 94% with a lazy-loaded LCP image have a good LCP. In Chrome's field data, loading="lazy" adds 8 ms of resource load delay before the image request starts (465 ms against 457 ms).
LCP pass rate
Sites with loading="lazy" have a good LCP most often at 94%, followed by no loading attribute at 94% and loading="eager" at 93%. Within Wix, 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 70.4% of audited Wix sites, ahead of CSS background images (1.1%) and text blocks (26.7%). Among the 3,936 Wix sites with an <img> LCP element, 70.6% omit the loading attribute, 22.2% set loading="lazy", and 7.2% 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 457 ms to 465 ms in Chrome's field data. That is a 8 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 465 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 84 sites with both attributes still wait 565 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.
| loading attribute | No priority hint | fetchpriority="high" | <link rel="preload"> | <link rel="preconnect"> |
|---|---|---|---|---|
| No loading attribute (auto) | 100% 33 sites | 94% 2,745 sites | few sites | few sites |
| loading="lazy" | 95% 789 sites | 89% 84 sites | few sites | few sites |
| loading="eager" | 93% 285 sites | few sites | few sites | few sites |
LCP image loading per framework
React puts loading="lazy" on the LCP image on 22% of its sites, and 94% of React sites have a good LCP.
React 3,936 sitesNo loading attribute (auto) 71%loading="lazy" 22%94%LCP image loading or the framework
Does the framework explain the loading="lazy" pass rate?
On React, 94% of sites with default loading have a good LCP, against 94% of React sites with loading="lazy" on the LCP image. Within React, 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 8 ms of resource load delay (465 ms against 457 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 · 5,621 crawled Wix sites (5,333 with all devices Chrome field data, 3,936 sites with an <img> LCP element by loading attribute, October 2026). How we measured.