Largest Contentful Paint: The One Element Killing Your Score

On this page

1. What Largest Contentful Paint Actually Measures
2. The Element Responsible Most of the Time
3. Hero Image vs Background CSS Image: Why the Difference Matters
4. Preload, Lazy Load and the Mistake That Cancels Them Out
5. Hosting and TTFB: The Upstream Problem That Caps Your LCP
6. How to Prioritise Which Fix to Make First

What Largest Contentful Paint Actually Measures

Largest Contentful Paint measures the time from when a user first navigates to a page until the browser renders the largest visible content element in the viewport. That element is almost always a hero image, a large heading, a video poster frame, or a block-level image sitting above the fold. It is not a composite score of everything loading on the page. It is one specific moment, one specific element, timed to the millisecond. Google set the “good” threshold at 2.5 seconds, and anything beyond 4 seconds is flagged as poor. Miss that window and you are telling both the user and the algorithm that your page is slow, regardless of how fast everything else loads.

The reason Google weights LCP so heavily in Core Web Vitals is that it correlates tightly with how fast a page feels to a real person. Users do not notice DNS lookups or Time to First Byte in isolation. What they notice is the moment the page looks usable, and that moment is almost always defined by the largest visible element settling into place. A page can pass on Interaction to Next Paint and Cumulative Layout Shift but still feel broken if LCP is poor. That is why understanding what the PageSpeed numbers actually tell you matters before you start chasing individual metrics.

The Element Responsible Most of the Time

In the vast majority of cases, the element dragging down your largest contentful paint score is a hero image or a large above-the-fold banner. These images are typically the biggest visible element when the page first loads, which is exactly what the LCP metric is measuring. A full-width homepage banner at 1.8MB, served without modern compression or a next-gen format like WebP, will almost always be the culprit. Before you start auditing fonts, scripts, or server configs, confirm what your LCP element actually is, because assumptions here cost you time.

PageSpeed Insights makes this straightforward. Run your URL, scroll to the Diagnostics section, and look for the “Largest Contentful Paint element” callout, which highlights the exact DOM node being measured. Chrome DevTools gives you the same answer under the Performance tab, where an LCP marker appears on the timeline and the corresponding element gets flagged in the summary panel. If you want to go deeper on how to interpret what those scores are telling you, PageSpeed Insights: Which Score Actually Matters? breaks down what the numbers mean in practice. Nine times out of ten, that flagged element will be a hero image, and that is where your optimisation work should start.

Hero Image vs Background CSS Image: Why the Difference Matters

The browser discovers an HTML <img> element the moment it parses the raw HTML, which means the image request fires as early as possible in the loading sequence. A CSS background-image works differently. The browser has to download and parse the stylesheet first, then build the CSS Object Model, then apply the style to the relevant element before it even knows the image exists. That chain of dependencies adds real latency before the first byte of your hero image is requested, and every millisecond of that delay lands directly on your largest contentful paint time. A background-image declared in an external stylesheet will almost always lose that race.

The fix is straightforward. Move your hero visual from a CSS background-image into a proper <img> tag in the HTML, then add fetchpriority="high" and loading="eager" so the browser treats it as the most urgent network request on the page. If you want the same precise cropping or positioning control that CSS gives you, use object-fit, cover on the <img> element itself. You keep the visual result and the browser keeps the early discovery window. For a deeper look at how these timing gaps show up in the data, PageSpeed Insights: Which Score Actually Matters walks through exactly how to read those waterfall traces.

Preload, Lazy Load and the Mistake That Cancels Them Out

A preload hint tells the browser to fetch your largest contentful paint element as early as possible, before the parser even reaches it in the HTML. Lazy loading does the opposite, it tells the browser to hold back and only fetch the resource when it is close to the viewport. Apply both to the same element and they cancel each other out. The browser receives two contradictory instructions, and in most cases the lazy load attribute wins, meaning your hero image arrives late regardless of the preload tag sitting in your <head>. That is not a minor inefficiency. It directly delays the LCP timestamp and tanks your score on every page load.

This exact conflict is one of the most common misconfiguration patterns on WordPress sites. A performance plugin like WP Rocket or Smush applies lazy loading globally to every image on the page, which is sensible for below-the-fold content but catastrophic when it catches the hero. A separate plugin or the theme itself adds a preload hint for that same image. The two settings rarely talk to each other, so you end up with conflicting directives you did not deliberately choose. The fix is straightforward, explicitly exclude your LCP element from lazy loading. If you want to understand how response time compounds this further, server response time and TTFB have their own separate drag on that initial fetch. Audit both settings in the same session, not separately.

Hosting and TTFB: The Upstream Problem That Caps Your LCP

No amount of image optimisation rescues a slow LCP if your server takes too long to respond in the first place. Time to First Byte is the clock that starts before anything else, and it runs before your browser has even seen the page HTML, let alone the LCP element. A server that takes 800ms to respond means the browser cannot begin fetching, parsing, or rendering anything until that time has already passed. If your LCP target is 2.5 seconds, you have already spent a third of your budget before a single pixel is drawn. That is a ceiling imposed entirely by your hosting stack, and no front-end fix touches it.

Shared hosting is the most common offender. On a shared server, your site competes for CPU and memory with dozens or hundreds of other tenants, and response times can spike without warning, especially during traffic peaks. A well-configured VPS or managed WordPress host with server-side caching can consistently return a first byte in under 200ms, which is the threshold Google treats as fast. If you want a clear picture of where your TTFB sits relative to that benchmark, our post on server response time and TTFB walks through exactly how to measure and diagnose it. Fix the upstream problem first, then optimise the element.

How to Prioritise Which Fix to Make First

Most sites waste time tuning delivery before they have fixed the source, and that is the wrong order. Start with image format and file size, because an oversized JPEG that should be a WebP at half the weight will hurt your largest contentful paint score more than almost anything else you can do to the delivery layer. Swap the format, compress to the correct dimensions for the viewport, and measure again before touching anything else. You will often find this single change closes the majority of the gap.

If the score is still lagging after you have sorted format and size, move to delivery method next, check whether your images are served from a CDN, whether HTTP/2 is active, and whether your server response time and TTFB are adding hidden latency before a single byte of the image arrives. Once delivery is clean, add a preload hint for the LCP element so the browser fetches it in parallel rather than waiting for the render tree. Hosting is the final lever to pull, because migrating servers is expensive and disruptive, and it rarely compensates for a 400 KB image that should have been 80 KB from the start.