WordPress 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 90 ms lazy-load delay shows up, and whether fetchpriority="high" overrides it.
Of the WordPress sites whose LCP element is an <img>, 14.5% put loading="lazy" on that image. 80.9% leave loading at the browser default and 4.7% set loading="eager". Across WordPress sites, 78% with default loading and 75% with a lazy-loaded LCP image have a good LCP. In Chrome's field data, loading="lazy" adds 90 ms of resource load delay before the image request starts (321 ms against 231 ms).
LCP pass rate
Sites with no loading attribute have a good LCP most often at 78%, followed by loading="eager" at 78% and loading="lazy" at 75%. Within WordPress, 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 35.2% of audited WordPress sites, ahead of CSS background images (42.5%) and text blocks (19.4%). Among the 21,174 WordPress sites with an <img> LCP element, 80.9% omit the loading attribute, 14.5% set loading="lazy", and 4.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 231 ms to 321 ms in Chrome's field data. That is a 90 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 230 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 46 sites with both attributes still wait 305 ms before the image request starts, and 72% 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 305 ms because the preload tag starts the fetch right away. Removing loading="lazy" and adding fetchpriority="high" on a normal <img> reaches a 195 ms load delay without duplicate markup.
| loading attribute | No priority hint | fetchpriority="high" | <link rel="preload"> | <link rel="preconnect"> |
|---|---|---|---|---|
| No loading attribute (auto) | 78% 10,637 sites | 79% 6,070 sites | 79% 103 sites | 65% 313 sites |
| loading="lazy" | 75% 2,871 sites | 72% 46 sites | few sites | 67% 134 sites |
| loading="eager" | 75% 624 sites | 80% 343 sites | few sites | few sites |
LCP image loading per framework
Vue puts loading="lazy" on the LCP image on 21% of its sites, and 75% of Vue sites have a good LCP. jQuery leaves the LCP image at the browser default on 81% of its sites and sets loading="lazy" on 15%, and 75% of jQuery sites have a good LCP.
jQuery 19,922 sitesNo loading attribute (auto) 81%loading="lazy" 15%75%
Vue 1,400 sitesNo loading attribute (auto) 75%loading="lazy" 21%75%
React 811 sitesNo loading attribute (auto) 77%loading="lazy" 18%66%LCP image loading or the framework
Does the framework explain the loading="lazy" pass rate?
On jQuery, 77% of sites with default loading have a good LCP, against 74% of jQuery sites with loading="lazy" on the LCP image. Within jQuery, 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
WordPress core has omitted loading="lazy" on the first content image since 5.9 (expanded to the first three images in 6.3 via wp_omit_loading_attr_threshold) and adds fetchpriority="high" to the detected LCP image. Still, 14.5% of WordPress LCP images carry loading="lazy" because themes, sliders, and optimization plugins (WP Rocket, LiteSpeed Cache, Smush, Perfmatters) rewrite every <img> tag after core runs. Add your hero image class or filename to your lazy-load plugin's exclusion list, pass 'loading' => false to wp_get_attachment_image() in custom hero templates, and pair it with fetchpriority="high". On WordPress, removing loading="lazy" cuts median resource load delay by 90 ms (231 ms vs 321 ms) and lifts good LCP from 75% to 78%.
By Arjen Karel · 63,295 crawled WordPress sites (17,005 with desktop Chrome field data, 21,174 sites with an <img> LCP element by loading attribute, October 2026). How we measured.