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

Largest Contentful Paint, or LCP, is one of Google's three Core Web Vitals. It measures how long it takes for the largest piece of content in the viewport to appear, which is a good proxy for the moment a visitor feels the page has actually loaded. A fast LCP means people see your main content quickly; a slow one means they stare at a mostly empty screen while the important part is still on its way.

What LCP measures

LCP records the render time of the largest content element visible in the viewport when the page first loads. That element is usually one of a few things: a hero image, a background image loaded through CSS, a poster frame of a video, or a large block of text such as a headline or paragraph. The browser watches these candidates as the page builds and reports the largest one, which is why the LCP element can change during loading until the layout settles.

It is important that LCP is about the largest visible element, not the whole page. The page can still be loading other things in the background; what matters for this metric is when the main content a visitor came to see has been painted.

What is a good LCP score

Google defines three bands, measured at the 75th percentile of real page loads across mobile and desktop:

Good: 2.5 seconds or less
Needs improvement: between 2.5 and 4 seconds
Poor: more than 4 seconds

The 75th percentile matters: it means three out of four visits must hit the target, so optimizing only for a fast test device is not enough. The experience of users on mid-range phones and slower networks is what decides your score.

How LCP is measured: lab and field

LCP appears in two kinds of data, and they answer different questions. Field data, collected from real Chrome users and reported in the Chrome UX Report, is what Google uses to assess Core Web Vitals; it reflects a trailing 28-day window. Lab data, produced by a tool such as Lighthouse or PageSpeed Insights in a controlled environment, is repeatable and useful for debugging but does not feed the ranking signal directly. You can also read LCP in the browser with the Performance API:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const last = entries[entries.length - 1];
  console.log('LCP:', last.startTime, last.element);
}).observe({ type: 'largest-contentful-paint', buffered: true });

The final entry the observer reports, once the layout settles, is your LCP, and last.element tells you exactly which element it was.

Field data in the Chrome UX Report is reported per URL when a page has enough traffic, and otherwise rolls up to an origin-level average. A low-traffic page therefore inherits the whole site's LCP until it gathers its own sample, which is worth knowing before judging a single page by its field score.

Find your LCP element first

Before improving anything, identify the element. PageSpeed Insights names the LCP element in its diagnostics, and the Chrome DevTools Performance panel marks it on the timeline. The Performance panel also shows the LCP subpart breakdown, so you can see whether the delay comes from server time, resource loading or rendering before you change anything. The right fix depends entirely on what that element is: an image LCP and a text LCP are solved in different ways.

What affects LCP: the four subparts

Every LCP breaks down into four consecutive stages. Knowing which one dominates tells you where to spend effort:

Time to First Byte: how long the server takes to send the first byte of the HTML.
Resource load delay: the gap between the first byte and the browser starting to load the LCP resource.
Resource load time: how long the LCP image or resource itself takes to download.
Element render delay: the gap between the resource finishing and the element actually painting.

A slow LCP is almost always one or two of these stages, not all four. Measuring the split keeps you from optimizing the wrong thing.

Common causes of a slow LCP

Each subpart tends to have typical culprits, and recognizing them shortens the diagnosis:

A slow server or missing caching inflates Time to First Byte, so the whole sequence starts late.
Render-blocking CSS and JavaScript delay the browser from discovering and loading the LCP resource.
A large, unoptimized hero image in an old format stretches resource load time.
Client-side rendering, hydration or a late web font pushes out element render delay, because the element cannot paint until the script or font is ready.
Lazy-loading the hero image tells the browser to wait, which is self-defeating for the one image that should load first.

How to improve LCP

Each of the four stages maps to concrete fixes, most of which have their own detailed guide.

Cut Time to First Byte. Faster server responses shorten the whole chain. See reduce initial server response time.
Remove what delays the resource. Render-blocking CSS and JavaScript hold up the LCP element. See eliminate render-blocking resources.
Shrink the LCP image. When the LCP element is an image, size it correctly and use a modern format. See properly size images and serve images in next-gen formats.
Never lazy-load the LCP image. Deferring the hero image is a common cause of poor LCP. See defer offscreen images for the rule.
Preload the LCP resource. Hint the browser to fetch the hero image or critical font early with <link rel="preload">, so resource load delay shrinks.

Because these levers compound, the fastest route to a good LCP is usually to fix the single dominant subpart first, re-measure, then move to the next.

Improving LCP for images versus text

The right fix depends on what the LCP element is. When it is an image, the highest-impact move is to load it early and at high priority so the browser fetches it before less important resources:

<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">
<!-- or directly on the element -->
<img src="/hero.avif" fetchpriority="high"
     width="1200" height="800" alt="Mountain at sunrise">

Combine that with correct sizing and a modern format so the file itself is small. When the LCP element is text, the bottleneck is usually the web font or render-blocking CSS. Add font-display: swap so text paints immediately in a fallback font, preload the font used above the fold, and keep the critical CSS lean so nothing holds up the first paint.

LCP and the other Core Web Vitals

LCP is one of three Core Web Vitals, and improving it in isolation is not the whole job. Cumulative Layout Shift measures visual stability, how much the page jumps around as it loads, and Interaction to Next Paint measures responsiveness, how quickly the page reacts to input. The three overlap in practice. Setting explicit width and height on the LCP image helps both LCP and layout stability, and the render-blocking and unused-JavaScript work that speeds up LCP also frees the main thread that responsiveness depends on. Treat LCP as the entry point, then confirm a fix for one metric has not quietly hurt another.

How to verify your LCP

Re-run PageSpeed Insights and confirm the lab LCP has improved and the flagged element is faster. Then watch the field data in the Chrome UX Report, which updates over its trailing 28-day window, so real-user gains appear gradually rather than instantly. Test several templates and both mobile and desktop, since the LCP element and its bottleneck often differ between a landing page and an article. Because Core Web Vitals are assessed for mobile and desktop separately and mobile is usually the weaker profile, prioritize the mobile LCP under network and CPU throttling that reflects a mid-range phone rather than a developer laptop.

Frequently asked questions

What is a good LCP score?

2.5 seconds or less at the 75th percentile of real users is good. Between 2.5 and 4 seconds needs improvement, and more than 4 seconds is poor.

What is the LCP element?

It is the largest content element visible in the viewport during load, usually a hero image, a CSS background image, a video poster, or a large text block. PageSpeed Insights and DevTools both name it.

What is the difference between LCP and FCP?

First Contentful Paint marks when the first piece of any content appears. Largest Contentful Paint marks when the largest, most meaningful element appears. FCP tells you rendering has started; LCP tells you the main content is there.

How do I improve LCP quickly?

Find the LCP element, then fix its dominant bottleneck: reduce server response time, remove render-blocking resources, optimize the LCP image, and preload it. Never lazy-load the LCP image.

Is LCP a Google ranking factor?

Yes. LCP is one of the three Core Web Vitals, which are part of Google's page experience signals, assessed on real-user field data.

Why is my LCP different in the lab and in the field?

Lab data comes from a single controlled test, while field data reflects a range of real devices and networks over 28 days. Google uses the field data for Core Web Vitals; the lab data is for debugging.

Does the LCP element change during loading?

Yes. As the page builds, a larger element can replace the previous candidate, so the browser keeps updating LCP until the layout settles and the final content is painted. The last reported value is your LCP.

Largest Contentful Paint (LCP)