What Is Largest Contentful Paint (LCP) and How to Improve It

When someone lands on a page, the moment that matters most is when the main content appears — the hero image, the headline, the thing they came to see. Largest Contentful Paint (LCP) puts a number on that moment. It is the Core Web Vital for loading, and because it is dominated by a single element, it is often the most tractable of the three to fix. In short: LCP measures how long the largest visible content element takes to render, a good score is 2.5 seconds or less at the 75th percentile, and the fastest route to improving it is to find that one element and make it arrive sooner. This guide explains what LCP is, what causes a poor score, and exactly how to improve it.

It is the deep-dive behind the loading metric in Core Web Vitals explained.

What LCP measures

LCP reports the render time of the largest content element visible in the viewport during page load, measured from when the page starts loading. As the page loads, the browser tracks the biggest element painted so far; LCP is the time at which the final largest element appears. Crucially, it only counts elements in the initial viewport — content below the fold does not affect it — and it measures render time, not just download time, so the element has to actually be on screen.

The element that triggers LCP is usually one of a handful of types:

• A hero image or large above-the-fold image
• A background image loaded via CSS
• A large block of text (a heading or paragraph)
• A video poster image or the first frame of a video

Because one element decides the score, the whole optimisation strategy is: identify it, then make it arrive and render as fast as possible.

The thresholds

LCP is assessed at the 75th percentile of page loads:

LCP	Rating
≤ 2.5s	Good
2.5s - 4.0s	Needs improvement
> 4.0s	Poor

The 75th-percentile rule means it is not enough for the page to be fast on your test device. Three-quarters of your real visits — including those on mid-range phones and slower connections — need to render the main content within 2.5 seconds.

The four causes of poor LCP

Almost every slow LCP traces back to one (or a combination) of four root causes. Diagnosing which one applies is what makes the fix efficient, because each has a different remedy.

Cause	What is happening	Primary fix
Slow server response (TTFB)	The browser waits a long time for the first byte, delaying everything	Server caching, CDN, faster backend and queries
Render-blocking resources	CSS/JS in the head must load before the browser can paint	Defer/async JS, inline critical CSS, remove unused CSS
Slow resource load time	The LCP image is large, late-discovered, or low-priority	Optimise the image, preload it, raise fetch priority
Client-side rendering	JavaScript has to build the content before anything shows	Server-render or pre-render critical content; reduce JS

A genuinely slow LCP often has more than one of these at play — for example a slow server and an unoptimised hero image — which is why measuring the breakdown, not just the total, pays off.

How to improve LCP

1. Optimise the LCP element

If the LCP element is an image (it usually is), this is the highest-leverage fix. Compress it, size it to the dimensions it is actually displayed at — serving a 4000px image into an 800px slot is pure waste — and use a modern format such as WebP or AVIF. The full method is in how to optimize images for the web. Shrinking the LCP image from hundreds of kilobytes to tens often moves the metric on its own.

2. Preload it and raise its priority

The browser can only fetch a resource once it has discovered it, and the LCP image is sometimes found late (for example when it is set via CSS or injected by script). Tell the browser about it early with <link rel="preload">, and mark it fetchpriority="high" so it jumps the queue ahead of less important downloads. This addresses the common case where the image is fine but simply requested too late.

3. Reduce Time to First Byte

If the server is slow to respond, the LCP clock is already running before the browser receives anything. Lower TTFB with server-side and full-page caching, a CDN that serves from a nearby edge, optimised database queries, and adequate hosting. This is covered more broadly in how to make your website load faster.

4. Eliminate render-blocking resources

CSS and synchronous JavaScript in the <head> block rendering until they are fetched and processed, so the LCP element cannot paint even once it has arrived. Add defer or async to scripts, inline the minimal CSS needed for the above-the-fold view and load the rest non-blocking, and delete unused CSS and JavaScript. Reducing JavaScript helps here and elsewhere — see how to reduce JavaScript and speed up your site.

5. Never lazy-load the LCP image

This is the most common self-inflicted LCP wound. loading="lazy" is excellent for below-the-fold images, but applying it to the LCP element tells the browser to delay the exact thing the metric is timing. Lazy-load everything off-screen; load the LCP image eagerly, ideally with a preload and high priority.

6. Address client-side rendering

If your content is built in the browser by JavaScript, the LCP element may not exist until a framework has downloaded, parsed and run. Server-side rendering or static pre-rendering of the critical above-the-fold content lets the browser paint it without waiting for JavaScript, which can transform LCP on single-page apps.

Lab data vs field data for LCP

LCP appears in two flavours and it is vital to know which you are looking at. Lab data (Lighthouse, the PSI lab section, WebPageTest) is a single simulated load on a fixed device and network — reproducible and ideal for diagnosis. Field data (the Chrome UX Report, shown in PSI and Search Console) is collected from real visitors and is what Google uses for ranking. A page can post a great lab LCP and still fail in the field if real users are on slower devices than the test assumes, or if the LCP element differs by viewport. The workflow: iterate with lab data because it is fast, but judge success by field data because that is what counts.

How to find and measure your LCP

A short, repeatable process:

1. Run the URL through PageSpeed Insights — it names the LCP element and shows both field and lab values.
2. Open Chrome DevTools → Performance, record a load, and read the LCP marker and its timing breakdown (TTFB, load delay, load time, render delay).
3. For real-user attribution, add the open-source web-vitals library, which can report the specific LCP element your visitors experience.
4. Cross-check with WebPageTest or GTmetrix for a detailed waterfall and a filmstrip that shows visually when the main content appears.

The four-part breakdown in DevTools is especially useful: it tells you whether your problem is the server (TTFB), late discovery (load delay), a heavy resource (load time), or blocking (render delay) — pointing you straight at the relevant fix above.

Understanding the four LCP sub-parts

It is worth dwelling on that breakdown, because matching the dominant sub-part to its fix is what makes LCP work efficient rather than guesswork. Web.dev describes LCP as the sum of four phases, and on most pages one of them dominates:

Sub-part	What it represents	If it dominates, fix
Time to First Byte	Waiting for the server's first byte	Server caching, CDN, faster backend
Resource load delay	Gap between TTFB and when the LCP resource starts loading	Preload the resource; stop loading it via CSS/JS late
Resource load time	How long the LCP resource takes to download	Compress and resize the image; modern format
Element render delay	Gap between resource arriving and it painting	Remove render-blocking CSS/JS; reduce main-thread work

A common pattern is a small TTFB but a large load delay, which almost always means the LCP image is being discovered too late — the classic fix is a preload plus high fetchpriority. Another is a fine load delay but a large load time, which points squarely at an oversized image that needs compression. Knowing which phase is biggest turns "my LCP is slow" into a specific, solvable task.

Why LCP matters commercially

LCP is easy to treat as an SEO box to tick, but the stronger reason to care is behavioural. The largest element is, by definition, the main thing a visitor came to see — the product photo, the headline, the article's opening. If it takes four seconds to appear, many visitors have already formed an impression of slowness, and some have left before the content even renders. Faster main-content rendering has been repeatedly linked to lower bounce and higher engagement, which is why LCP is a proxy not just for a Google signal but for whether your page makes a good first impression at all. Because Core Web Vitals feed Google's page-experience signals, a good LCP also pays a modest SEO dividend — but the user-experience case stands on its own, and it is usually the more persuasive argument when performance work competes with feature work for engineering time.

A worked example

Suppose PSI reports a field LCP of 3.8 seconds — "needs improvement" — and names a hero image as the element. The DevTools breakdown shows a moderate TTFB but a large load delay: the image is discovered late because it is set as a CSS background. You make three changes: convert the background image to a regular <img> (or add a preload for it), compress and resize it from 900KB to 90KB in AVIF, and add fetchpriority="high". The browser now discovers and fetches a much smaller image immediately, and the field LCP drops below 2.5 seconds. This is the typical shape of LCP work — one element, two or three targeted changes, a large result — which is exactly why LCP is usually the friendliest Core Web Vital to tackle first.

Common mistakes

• Lazy-loading the LCP image, delaying the very element being measured.
• Optimising the lab score while field LCP stays poor.
• Forgetting the server: a fast image cannot rescue a slow TTFB.
• Preloading too much, which congests the network and helps nothing.
• Assuming the LCP element is fixed — it can differ between mobile and desktop viewports, so check both.

Go deeper

• The full set of metrics: Core Web Vitals explained.
• The big picture, in priority order: how to make your website load faster.
• The heaviest assets: how to optimize images for the web.
• The expensive resource: how to reduce JavaScript and speed up your site.

Want your LCP measured alongside the rest of your Core Web Vitals, SEO and security? Analyse any URL with StackOptic — free, no sign-up.