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 161 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, 74% with default loading and 69% with a lazy-loaded LCP image have a good LCP. In Chrome's field data, loading="lazy" adds 161 ms of resource load delay before the image request starts (384 ms against 223 ms).
LCP pass rate
Sites with no loading attribute have a good LCP most often at 74%, followed by loading="eager" at 70% and loading="lazy" at 69%. Within WordPress, leaving the LCP image at default loading beats loading="lazy" by 5 percentage points and cuts median LCP from 2.0s to 1.8s.
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 223 ms to 384 ms in Chrome's field data. That is a 161 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 356 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 211 ms before the image request starts, and 74% 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 179 ms load delay without duplicate markup.
| loading attribute | No priority hint | fetchpriority="high" | <link rel="preload"> | <link rel="preconnect"> |
|---|---|---|---|---|
| No loading attribute (auto) | 74% 10,637 sites | 76% 6,070 sites | 72% 103 sites | 68% 313 sites |
| loading="lazy" | 69% 2,871 sites | 74% 46 sites | few sites | 64% 134 sites |
| loading="eager" | 65% 624 sites | 77% 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 68% 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 69% of jQuery sites have a good LCP.
jQuery 19,922 sitesNo loading attribute (auto) 81%loading="lazy" 15%69%
Vue 1,400 sitesNo loading attribute (auto) 75%loading="lazy" 21%68%
React 811 sitesNo loading attribute (auto) 77%loading="lazy" 18%61%LCP image loading or the framework
Does the framework explain the loading="lazy" pass rate?
On jQuery, 73% of sites with default loading have a good LCP, against 68% of jQuery sites with loading="lazy" on the LCP image. Within jQuery, leaving the LCP image at default loading beats loading="lazy" and cuts median LCP from 2.0s to 1.8s. On Vue, 74% of sites with default loading have a good LCP, against 64% of Vue sites with loading="lazy" on the LCP image. Within Vue, leaving the LCP image at default loading beats loading="lazy" and cuts median LCP from 2.1s to 1.9s.
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 161 ms (223 ms vs 384 ms) and lifts good LCP from 69% to 74%.
By Arjen Karel · 63,295 crawled WordPress sites (60,855 with all devices Chrome field data, 21,174 sites with an <img> LCP element by loading attribute, October 2026). How we measured.