What Is Your LCP Element? 464 Page Audits Show It's Often Text, Not an Image

The Numbers at a Glance#

How This Study Was Done#

Every number here is computed from Page Audit results stored in Greadme's database, read once and read-only on October 23, 2026. Nothing was re-scanned and nothing is estimated. The data covers every audit that stored Lighthouse's LCP breakdown, from December 31, 2025 (when Greadme began storing it) to October 23, 2026: 743 of the 951 Page Audits stored in that period. Of the 464 audits studied, 112 were run by signed-out visitors and the rest by 252 signed-in accounts.

Counting only the first audit of each page on each device keeps a page that someone audited twenty times from counting twenty times. The LCP element is the node Lighthouse names in its LCP breakdown. An element that needed a resource download before it could paint is an image or video. One that didn't is text. The three loading conditions come from Lighthouse's LCP request discovery check, which Greadme stores only when it fails, so an LCP image without one passed all three. Lab LCP is the simulated value behind the Performance score. Each figure's source line names the audits it counts.

This study looks at a different question from our Greadme State of Websites Report 2026, which measured how often pages miss the LCP target. Here the question is what the LCP element is, and why it's late.

Finding 1: On 4 in 10 Pages, the LCP Element Is Text#

LCP counts more than images. web.dev lists the elements it considers: <img>, an <image> inside SVG, <video>, an element with a CSS background image, and “block-level elements containing text nodes or other inline-level text element children”. In this data, that last group won 197 times out of 464.

The most common text LCP is the page's <h1> (89 audits), then a paragraph (52). It happens on both devices: 44.8% of mobile audits and 40.1% of desktop audits.

Why it matters: a text LCP needs nothing downloaded for itself. web.dev's guide to optimizing LCP says that if the element is “a text node rendered with a system font”, the resource load delay and the resource load duration are both 0. The time goes elsewhere: to the server response and to whatever has to finish before the browser paints. A web font is the one resource a text LCP can wait on; the same guide says the LCP resource, “if it has one”, is either an image or a web font.

In this data, text LCP pages had the faster median lab LCP on mobile: 4.1 s (n = 93) against 6.8 s for image LCP pages (n = 105). That's an observation about two groups of pages, not proof that text is faster. Render-blocking resources were flagged on 91.3% of mobile text-LCP pages, about as often as on image-LCP pages (89.1%). If your LCP is a headline, there's no LCP image to optimize; look at what delays the first paint instead. See render-blocking resources.

Finding 2: 7 in 10 LCP Images Miss at Least One Loading Condition#

Lighthouse's LCP request discovery insight checks three things about an LCP image. The Chrome developer docs put them like this: use fetchpriority=high on the image or its preload, “ensure the image is discoverable from the main document (either because it is directly in the HTML, or the image is preloaded)”, and “avoid loading=lazy for the image.” Of the 267 audits whose LCP element was an image or a video, only 81 (30.3%) met all three.

The most common miss is also the cheapest fix. 84 LCP images (31.5%) were already in the HTML and loaded eagerly, and failed only because nothing marked them as important. web.dev's advice is direct: “It's a good idea to set fetchpriority="high" on an <img> element if you think it's likely to be your page's LCP element.” The same guide warns that “setting a high priority on more than one or two images makes priority setting unhelpful”, so this is an attribute for the one image that matters.

<!-- The LCP image: in the HTML, eager, and marked as important -->
<img src="/hero.webp" alt="…" width="1200" height="630" fetchpriority="high">

The image's file size was the smaller factor. Of the 169 LCP <img> elements with a readable source, 57 (33.7%) were flagged as oversized or in an older format, and the median estimated saving on those was 47 KB. Where the hero is flagged, it's worth fixing, but loading-condition misses were far more common: 186 of the 267 LCP images missed at least one.

Finding 3: CSS Background Heroes Are the Ones Found Late#

How the image is put on the page makes a large difference. When the LCP image was an <img> tag, it was missing from the initial HTML 38 times out of 171. When it was a CSS background on a container, it was missing 48 times out of 81.

web.dev explains why. To start loading early, the LCP resource must be “discoverable in the initial HTML document response by the browser's preload scanner”, and two of its examples of a resource that is not are “an <img> that is dynamically added to the page using JavaScript” and an element that “requires a CSS background image”. A background image becomes discoverable when it's preloaded in the HTML. The Chrome docs add that the preload needs fetchpriority=high too.

<!-- A CSS background hero: let the browser find it in the HTML -->
<link rel="preload" as="image" href="/hero.webp" type="image/webp" fetchpriority="high">

Simpler still: if the hero is content, make it an <img>. In this data, <img> heroes were missing from the initial HTML far less often (22.2% against 59.3%). That's a difference between two groups of pages, not a measured before and after.

Finding 4: Lazy-Loading the LCP Image Is Rare, and the Slowest Group#

web.dev puts it plainly: “Never lazy-load your LCP image.” In this data it was the least common of the three misses: 21 LCP images (7.9%), every one of them an <img> tag. The missing priority (67%) and the late discovery (33%) were far more common.

The groups do line up with lab LCP, though. On mobile, the median simulated LCP was lowest for LCP images that passed all three conditions, and highest for the few that were lazy-loaded.

Desktop shows the same order: a median of 962 ms for images that passed (n = 31) against 1.5 s for those that failed at least one condition (n = 69). Pages that get these details right may also do other things well, so read the gap as a pattern worth acting on, not as the exact payoff of one attribute.

Finding 5: On 8 Sites, the Cookie Banner Was the LCP Element#

web.dev describes LCP as the render time of “the largest image, text block, or video visible in the viewport”, and sometimes that's an overlay. On 8 of the 376 sites, the element Lighthouse named was the text of a cookie or consent banner. On one more it was an accessibility widget's button icon, and on another a discount popup. Each of these was checked by hand; hero sections that merely had “banner” in their class name were not counted.

When this happens, the audit's LCP is timing the banner, not the hero you designed. It's worth knowing which one you're measuring before you start optimizing: the banner's own paint, and the content behind it once it's dismissed, both reach the visitor.

What Happened After a Loading Condition Was Fixed#

Greadme stores each audit, so when someone audits the same page again the two results can be compared. Across the dataset, 115 page-and-device pairs were audited more than once. In 8 of those re-audits, on 6 sites, the same LCP element went from failing a loading condition to passing it, with no condition getting worse. Here is every one of them, including the two where LCP went up.

Lab LCP fell in 6 of the 8 cases. The clearest is Site A, whose LCP element is a video: 38 minutes after its first audit, the video carried the priority hint, LCP dropped from 4.9 s to 1.2 s and the Performance score rose from 71 to 96. Site D shows the biggest change. Its hero is a CSS background, and when the page started serving its content in the HTML (Greadme's client-side rendering check flipped to server-rendered) the image became discoverable and mobile LCP fell from 18.7 s to 8.4 s. 3.5 hours later, the priority hint appeared and LCP was 7.1 s.

Two caveats keep this honest. First, a change between two audits is an observation, not proof: other things on the page may have changed too, especially across Site C's two-month gap, and Site C's mobile LCP went up while its desktop LCP fell. Second, the Performance score is a blend of five metrics, in which LCP carries 25%, so it doesn't always follow LCP: Site D's LCP improved by more than ten seconds while its score went down. Sites E and F added the priority hint to an image that still wasn't discoverable: Site E's LCP barely moved (2.3 s to 2.2 s) and Site F's rose. One reading is that a priority hint helps less while the browser still finds the image late, but two cases can't prove that.

How to Check and Fix Your Own LCP Element#

For the wider picture of what LCP is and its thresholds, read our guide to Largest Contentful Paint.

Limitations#

• Who audits with Greadme. These are pages people chose to audit, not a random sample of the web. 419 of the 464 audits are of homepages, so the findings describe homepages more than inner pages.
• Audits without a breakdown are left out. 208 of the 951 Page Audits in the period stored no LCP breakdown, so their LCP element can't be known and they aren't counted.
• Lab, not field. Every LCP value here is Lighthouse's simulated lab measurement from one run, not the experience of real visitors.
• Associations, not effects. Differences between groups of pages (passing vs failing, text vs image) can have other causes. The re-audit cases are observations of what changed between two audits, not controlled experiments.
• One moment per page. The LCP element can change between visits, devices and versions of a page; each page here is counted at its first audit on each device.

Frequently Asked Questions#