WordPress LCP resource discovery and the Core Web Vitals
HTML markup, CSS background-image, <link rel="preload">, JavaScript, or HTTP Link header: how the browser finds the LCP element and how much load delay each path adds.
On 55.4% of WordPress sites, the browser finds the LCP element straight in the HTML. 39.7% hide it in a CSS stylesheet, 3.6% declare it with <link rel="preload">, and 1.3% inject it with JavaScript. Sites with the LCP element in HTML have a good LCP on 73% of sites (1.9s median), against 66% for CSS discovery (2.1s) and 62% for JavaScript discovery (2.1s). Preloading cuts median resource load delay to 206 ms, the lowest of any discovery path.
LCP pass rate
Sites with HTML discovery have a good LCP on 73% of WordPress sites, <link rel="preload"> at 77%, CSS discovery at 66%, and JavaScript discovery at 62%. Within WordPress, preloading the LCP resource beats standard HTML discovery by 4 percentage points and CSS discovery by 11 percentage points.
LCP resource discovery usage
On WordPress, 55.4% of sites put their LCP element in the initial HTML markup. 39.7% (23,868 sites) put the LCP image inside a CSS background-image rule. Explicit <link rel="preload"> tags appear on 3.6% of WordPress sites (2,171 sites), JavaScript injection on 1.3% (759 sites), and HTTP Link headers on (23 sites).
LCP phase breakdown by discovery path
How the browser discovers the LCP asset directly sets its resource load delay: <link rel="preload"> starts the download after a median 206 ms, HTML discovery after 257 ms, CSS discovery after 428 ms, JavaScript discovery after 548 ms. When a hero image lives in CSS, Chrome must download and parse the stylesheet and match the selector against the DOM before it sees the image URL. That adds 171 ms of load delay over HTML discovery.
LCP discovery path by element type
More than half of all <link rel="preload"> sites (1,644 of 2,171) preload a CSS background-image rather than an <img> tag. Preloading cuts the background image's field load delay from 428 ms to 209 ms. That lifts LCP from 66% to 78%. Among standard <img> LCP elements, HTML discovery covers 19,937 sites (74% good, 242 ms load delay), <link rel="preload"> covers 477 sites (75% good, 202 ms delay), and JavaScript injection covers 748 sites (61% good, 549 ms delay).
| Discovery path | <img> element | CSS background-image | Text block | <video> element |
|---|---|---|---|---|
| HTML document | 74% 19,937 sites | few sites | 72% 11,623 sites | 67% 1,743 sites |
| CSS background-image | few sites | 66% 23,868 sites | few sites | few sites |
| <link rel="preload"> | 75% 477 sites | 78% 1,644 sites | 79% 34 sites | few sites |
| JavaScript injection | 61% 748 sites | few sites | few sites | few sites |
| HTTP Link header | few sites | few sites | few sites | few sites |
LCP resource discovery per framework
jQuery discovers the LCP element in HTML on 55% of its sites and in CSS on 40%, and 69% of jQuery sites have a good LCP. Vue discovers the LCP element in HTML on 49% of its sites and in CSS on 43%, and 68% of Vue sites have a good LCP.
Alpine 349 sitesHTML document 66%CSS background-image 26%80%
jQuery 57,286 sitesHTML document 55%CSS background-image 40%69%
Vue 4,721 sitesHTML document 49%CSS background-image 43%68%
React 2,117 sitesHTML document 56%CSS background-image 37%61%LCP discovery path or the framework
Does the framework explain the discovery gap?
On jQuery, 77% of sites that preload their LCP resource have a good LCP, compared with 72% for HTML discovery and 65% for CSS discovery. Within jQuery, keeping the LCP element in HTML instead of CSS lifts the pass rate by 7 percentage points. On Vue, 79% of sites that preload their LCP resource have a good LCP, compared with 70% for HTML discovery and 63% for CSS discovery. Within Vue, keeping the LCP element in HTML instead of CSS lifts the pass rate by 7 percentage points.
How much time early discovery saves
Resource load delay is the gap between Time to First Byte (when the HTML arrives) and the moment the browser starts downloading the LCP resource. When the LCP image is a standard <img> in the HTML, Chrome's preload scanner finds it at a 257 ms median load delay. When the image sits in an external stylesheet as a background-image, load delay jumps to 428 ms. The browser has to download the CSS, build the CSSOM, and match selectors to the DOM before it sees the image URL. A <link rel="preload" as="image"> tag in the <head> lets the preload scanner start the image download alongside the stylesheet. That cuts the CSS background image's load delay from 428 ms to 209 ms.
Understanding LCP resource discovery
Render the hero image as a standard <img> or <picture> block in the WordPress template with fetchpriority="high", not as a container background-image in Elementor, Divi, or WPBakery. On WordPress, 39.7% of sites hide their LCP image inside CSS background-image rules, which adds 171 ms of resource load delay and drops good LCP from 73% to 66%. If a page builder locks the hero into a CSS background-image, print a <link rel="preload" as="image" fetchpriority="high"> tag in wp_head so Chrome's preload scanner starts downloading the image before the stylesheet arrives.
By Arjen Karel · 63,295 crawled WordPress sites (60,855 with all devices Chrome field data, 60,125 sites with LCP resource discovery, October 2026). How we measured.