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 (195 ms with preload vs 306 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 80% of those sites have a good LCP, against 76% of all WordPress sites.
LCP pass rate
Sites with <link rel="preload"> LCP priority hints have a good LCP most often: 80%, against 76% of all WordPress sites. Sites with <link rel="preconnect"> priority hints have it least often, at 70%.
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 resource load delay: 195 ms median for <link rel="preload"> against 306 ms for no. Overall median field LCP is 1.6s for <link rel="preload"> (TTFB 975 ms, load delay 195 ms, load duration 128 ms, render delay 306 ms) versus 1.8s for no.
LCP priority hints combined with the loading attribute
Combining fetchpriority="high" with Eager reaches 80% good LCP across 160 sites (181 ms median load delay). At the other end, <link rel="preconnect"> paired with Auto sits at 65% across 116 sites (357 ms median load delay).
| Priority hint | No loading attribute (auto) | loading="lazy" | loading="eager" |
|---|---|---|---|
| No priority hint | 78% 10,637 sites | 75% 2,871 sites | 75% 624 sites |
| fetchpriority="high" | 79% 6,070 sites | 72% 46 sites | 80% 343 sites |
| <link rel="preload"> | 79% 103 sites | few sites | few sites |
| <link rel="preconnect"> | 65% 313 sites | 67% 134 sites | few sites |
LCP priority hints per framework
On jQuery, 85% of sites use no LCP priority hints, and 75% of jQuery sites have a good LCP, against 76% of all sites. On Vue, 85% of sites use no, and 75% of Vue sites have a good LCP.
Alpine 349 sitesNo priority hint 75%fetchpriority="high" 18%82%
jQuery 57,286 sitesNo priority hint 85%fetchpriority="high" 11%75%
Vue 4,721 sitesNo priority hint 85%75%
React 2,117 sitesNo priority hint 81%fetchpriority="high" 13%66%LCP priority hints or the framework
Does the framework explain the LCP priority hints difference?
On jQuery, 80% of sites with <link rel="preload"> LCP priority hints have a good LCP, against 75% of jQuery sites with no. Within jQuery, sites with <link rel="preload"> have a good LCP more often. On Vue, 79% of sites with <link rel="preload"> LCP priority hints have a good LCP, against 74% of Vue sites with no. Within Vue, sites with <link rel="preload"> and no have a good LCP about equally 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 306 ms to 195 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 (75% good LCP vs 79% with fetchpriority="high" and 80% with preload) because CSS background heroes and custom page-builder sliders bypass core's detection.
By Arjen Karel · 63,295 crawled WordPress sites (17,005 with desktop Chrome field data, 60,125 sites with LCP priority hints, October 2026). How we measured.