WordPress LCP priority hints (fetchpriority, preload) and the Core Web Vitals
fetchpriority="high", <link rel="preload">, <link rel="preconnect">, or no hint at all: how priority hints cut LCP resource load delay (209 ms with preload vs 368 ms with no hint) and move Largest Contentful Paint.
84.8% of WordPress sites have no LCP priority hints. Of the 15.2% that do, 20% use <link rel="preload">, and 77% of those sites have a good LCP, against 70% of all WordPress sites.
LCP pass rate
Sites with <link rel="preload"> LCP priority hints have a good LCP most often: 77%, against 70% of all WordPress sites. Sites with <link rel="preconnect"> priority hints have it least often, at 66%.
LCP priority hints usage
15.2% of WordPress sites use LCP priority hints, and 71% of those use fetchpriority="high". <link rel="preload"> is 20% of the sites with priority hints, 3.1% of all WordPress sites.
Where priority hints save time: the four LCP phases
Across the four LCP sub-parts in Chrome's field data, the largest gap between <link rel="preload"> and no sits in time to first byte (TTFB): 900 ms median for <link rel="preload"> against 1150 ms for no. Overall median field LCP is 1.7s for <link rel="preload"> (TTFB 900 ms, load delay 209 ms, load duration 179 ms, render delay 350 ms) versus 2.0s for no.
LCP priority hints combined with the loading attribute
Combining fetchpriority="high" with Eager reaches 77% good LCP across 329 sites (188 ms median load delay). At the other end, <link rel="preconnect"> paired with Lazy sits at 64% across 128 sites (421 ms median load delay).
| Priority hint | No loading attribute (auto) | loading="lazy" | loading="eager" |
|---|---|---|---|
| No priority hint | 74% 10,637 sites | 69% 2,871 sites | 65% 624 sites |
| fetchpriority="high" | 76% 6,070 sites | 74% 46 sites | 77% 343 sites |
| <link rel="preload"> | 72% 103 sites | few sites | few sites |
| <link rel="preconnect"> | 68% 313 sites | 64% 134 sites | few sites |
LCP priority hints per framework
On jQuery, 85% of sites use no LCP priority hints, and 69% of jQuery sites have a good LCP, against 70% of all sites. On Vue, 85% of sites use no, and 68% of Vue sites have a good LCP.
Alpine 349 sitesNo priority hint 75%fetchpriority="high" 18%80%
jQuery 57,286 sitesNo priority hint 85%fetchpriority="high" 11%69%
Vue 4,721 sitesNo priority hint 85%68%
React 2,117 sitesNo priority hint 81%fetchpriority="high" 13%61%LCP priority hints or the framework
Does the framework explain the LCP priority hints difference?
On jQuery, 77% of sites with <link rel="preload"> LCP priority hints have a good LCP, against 68% of jQuery sites with no. Within jQuery, sites with <link rel="preload"> have a good LCP more often. On Vue, 80% of sites with <link rel="preload"> LCP priority hints have a good LCP, against 66% of Vue sites with no. Within Vue, sites with <link rel="preload"> have a good LCP more often.
How fetchpriority and preload change Chrome's network queue
Chromium starts <img> requests at Low network priority while stylesheets and head scripts download at Highest or High priority, only promoting visible viewport images to High after layout completes. Adding fetchpriority="high" to the hero <img> sets its initial network priority to High during the preload scan, while <link rel="preload" as="image"> starts the download from the document <head> and cuts median resource load delay from 368 ms to 209 ms.
Understanding LCP priority hints
Put fetchpriority="high" on your hero <img> tag and add <link rel="preload" as="image"> when the hero image is referenced inside CSS or a late block. WordPress 6.3+ automatically adds fetchpriority="high" to the image it estimates as the LCP element, yet 84.8% of WordPress sites still have no priority hint on their actual LCP element (69% good LCP vs 76% with fetchpriority="high" and 77% with preload) because CSS background heroes and custom page-builder sliders bypass core's detection.
By Arjen Karel · 63,295 crawled WordPress sites (60,855 with all devices Chrome field data, 60,125 sites with LCP priority hints, October 2026). How we measured.