Largest Contentful Paint (LCP): What It Is, How to Measure & Optimize

What is the Largest Contentful Paint (LCP)?

The Largest Contentful Paint is a measurement of the render time of the largest content element (of type image, video, or text) that has been painted on the visible part of the screen. The LCP timing indicates the time in milliseconds between requesting the page and when that largest contentful element is displayed on the visible part of the web page (above the fold).

History of the Largest Contentful Paint

When you think about it, the LCP might seem a trivial metric to represent the loading part of the Core Web Vitals. Why not measure loading speed as 'the time it takes for the page to load'?

That is because it is hard (or even impossible) in most modern websites to define when the page has loaded. More and more websites use techniques such as lazy loading or progressive loading where the page basically can keep loading forever. That means page speed cannot be measured by a single point in time.

There are several moments when loading the page that can cause a user to experience the page as fast or slow. For example the server delay (Time to First Byte), the first time that content is visible (First Contentful Paint), the time that the visible viewport may seem complete (Largest Contentful Paint) and when the page becomes interactive (when clicking on a link becomes possible) are all points during the loading process where the site may seem slow or fast!

The Largest Contentful Paint (LCP) is chosen because it focuses on a visitor's user experience. When the LCP occurs you can assume that a visitor thinks the page is finished loading (even if behind-the-scenes processes are still running). The LCP was created to answer the question: 'When is the content of a page visible?'. This is why LCP is recognized as a core indicator of user-centric performance.

LCP vs FCP: What is the Difference?

Largest Contentful Paint (LCP) and First Contentful Paint (FCP) both measure loading performance, but they capture fundamentally different moments in the page load timeline. FCP fires as soon as the browser paints the first pixel of content, which could be a tiny navigation bar or a loading spinner. LCP fires when the largest meaningful element renders in the viewport.

Think of it this way: FCP tells you the page has started to load; LCP tells you the page feels loaded. Google chose LCP as the Core Web Vital because it more accurately reflects what users perceive as "speed."

For most websites, optimizing LCP should be the priority. If your LCP is fast, your FCP will almost always be fast as well, because FCP occurs earlier in the loading timeline. The reverse is not true: a fast FCP does not guarantee a fast LCP.

Why LCP Matters for Your Business

The Largest Contentful Paint is one of the 3 Core Web Vitals. As a Core Web Vital, the Largest Contentful Paint is important for SEO, but more importantly, LCP is critical for UX. Visitors do not like to be kept waiting, and with more and more mobile traffic (that tends to be slower than desktop traffic) optimizing the Largest Contentful Paint makes a lot of sense.

• For SEO. Yes, Google focuses on serving the best pages in its search results. LCP is part of Google's Core Web Vitals. Google clearly states that site speed is a factor in search results.
• For Visitors: According to recent research by Google itself, the probability of a user leaving the site doubles with a loading time of 3 seconds. You will probably recognize that for yourself. While surfing the internet almost nothing seems as annoying as a slow loading website. Chances are that you will quickly leave a slow loading page.
• Other reasons: Page Speed is a factor in your Google Ad Score. This means you can buy your ads cheaper. Additionally, passing the Core Web Vitals is one of the prerequisites for Google's top Story box.

A fast LCP gives the visitor the idea that the page loads quickly. As a result, a visitor is less likely to navigate away from the page.

Case Study: Vodafone (31% LCP Improvement, 8% More Sales)

Vodafone Italy ran a controlled experiment optimizing their LCP score. By reducing LCP by 31%, they measured an 8% increase in sales. This is not a correlation; it is a direct A/B test proving that faster perceived loading translates to more revenue. The optimization focused on preloading the LCP image and reducing render-blocking resources. Read the full Vodafone case study on web.dev.

Case Study: Google Flights (fetchpriority Saved 700ms)

The Google Flights team added fetchpriority="high" to their hero image and saw the LCP improve by 700 milliseconds. This single HTML attribute change was the most impactful optimization in their performance sprint. The fetchpriority attribute tells the browser to prioritize the LCP image download over other resources, and as the Google Flights experiment demonstrates, the impact can be dramatic. Learn more about resource prioritization for Core Web Vitals.

Which Elements are Considered LCP Elements?

Not all elements are considered as an LCP element. The largest Contentful element has to be painted on the visible part of the screen (the viewport) before the user has interacted with the page.

The element has to be:

• An <img> element.
• An <image> element nested inside an <svg> element.
• A <video> element (the poster image or first video frame, whichever happens earlier, is used).
• An element with a background image loaded via the CSS url() function. (Note: This is an anti-pattern for LCP optimization as it makes the image undiscoverable to the browser's preload scanner. Read our guide on deferring background images).

• A block-level element containing text nodes or other inline text elements (in case of inline text elements like <span> the nearest block-level element <div> or <p> is considered).

Currently, certain elements are excluded as LCP candidates, such as elements hidden with opacity: 0, images that match 100% of the viewport size (cover images), and placeholders (low-entropy images). Keep in mind, this can change as the spec evolves!

Getting Technical: Measuring LCP Element Size

LCP identifies the largest visible content element in the viewport and calculates its size based on a set of precise rules. These rules ensure consistency and accuracy, even in complex layouts.

• Viewport only: Only the visible part of the page is considered. If an element is only partially in the visible viewport, the considered size will be clipped.
• No border, padding or margin: For all elements, text and image borders, padding and margins are completely ignored.
• Text size: Text elements get reported as the smallest rectangle that can be painted around the text node(s).
• Image size: For images, the smallest of the intrinsic dimensions (the original width and height) and the display size (the size on screen) is used to calculate LCP element size.
• First size counts: When layout changes or when an element size changes, only the first size is considered for the LCP.
• Removed elements are included: When an element is removed from the DOM it is still an LCP candidate.

Dynamic Nature of LCP

Largest Contentful Paint (LCP) is a dynamic metric. While rendering can be complex and occur in stages, it's normal for the LCP element to change during page load. Before the first user interaction, the browser's performance observer identifies all elements that could be considered LCP candidates. If a new element is rendered that is both visible within the viewport and larger than the previously identified LCP element, it becomes the new LCP.

Take-aways from LCP field data: At CoreDash we track millions of LCP entries per day. As it turns out, for mobile pageviews the LCP element is often a text-based element, either a paragraph or a heading. On average (or at the 75th percentile to be precise) the Core Web Vitals will pass when the LCP element is a text node or even a normal image. When the LCP element is a background image, video, or a lazy-loaded image, the Core Web Vitals tend to fail.

What is a Good LCP Score?

To pass the Core Web Vitals for the Largest Contentful Paint at least 75% of your visitors need to have a 'good' LCP score. A LCP score between 0 and 2.5 seconds is considered a good LCP score, a LCP score between 2.5 and 4 seconds needs improvement and a LCP score above 4 seconds is considered poor.

What Real-World LCP Data Shows

CoreDash tracks millions of real user LCP measurements every day. Here is what the data reveals about LCP performance across the web.

Image LCP vs Text LCP

Pages with image-based LCP elements have a 75th percentile LCP of 744ms, nearly twice as slow as text-based LCP elements at 388ms. This confirms that image optimization is the single most impactful area for improving LCP scores. If your LCP element is an image, you need to be particularly aggressive with optimization.

The Impact of Preloading and Lazy Loading

Preloaded LCP images achieve 100% "good" scores with a 75th percentile of 364ms. In contrast, lazy-loaded LCP images are among the slowest at 720ms, with 4.3% of page loads rated "poor." Non-preloaded images perform almost as badly at 752ms. The takeaway is clear: preload your LCP image and never lazy-load it.

Mobile vs Desktop LCP

Mobile LCP (764ms at the 75th percentile) is 2x slower than desktop LCP (380ms). This gap is driven by slower mobile networks and less powerful mobile processors. Since Google uses mobile-first indexing, optimizing for mobile LCP should be the priority.

Global LCP Statistics

According to the HTTP Archive Web Almanac 2024, 59% of mobile pages globally achieve a good LCP score (under 2.5 seconds), up from 44% in 2022. LCP remains the hardest Core Web Vital to pass and is the primary bottleneck for overall CWV scores. Additionally, 73% of mobile LCP elements are images, and 16% of mobile sites mistakenly lazy-load their LCP image.

How LCP is Measured: The Four Key Phases

According to Google, the Largest Contentful Paint can be broken down into 4 sub-parts. Understanding which phase is causing the bottleneck is essential for efficient optimization, because each phase requires a completely different fix. A slow Time to First Byte (TTFB) needs server-side work, while a slow resource load delay needs changes to your HTML.

A page's final LCP time is not a single, monolithic value. It is the sum of four distinct sub-parts. Understanding this breakdown is the key to diagnosing and fixing LCP issues efficiently.

Here is a breakdown of the four phases:

• Time to First Byte (TTFB): This is pure server response time. It covers everything from the DNS lookup, through the TCP/TLS connection, to the moment the browser receives the first byte of the HTML document. A slow TTFB is a foundational problem that will always kill your LCP. Across the web, sites with poor LCP spend an average of 2.27 seconds on TTFB alone, which is nearly the entire 2.5 second threshold. Optimizing TTFB involves server-side caching, CDN configuration, and efficient backend code.
• Resource Load Delay: This is the "discovery gap." It measures the time between TTFB completing and the browser actually starting to download the LCP resource. A long delay here means the browser found the LCP resource late. This is the classic symptom of using CSS background images (which the preload scanner cannot discover) or client-side rendering (where the LCP element only appears after JavaScript executes). The fix is to ensure your LCP element is in the initial HTML and to preload the LCP image if the browser cannot discover it early enough.
• Resource Load Duration: This is how long it takes to actually download the LCP resource file (the image, font, or video). This phase is all about file size and network conditions. Optimizing means using modern image formats like AVIF or WebP, implementing responsive images with srcset, and serving assets through a CDN with proper compression.
• Element Render Delay: This is the final delay. It measures the time between when the LCP resource finishes downloading and when the element is fully rendered on screen. This delay is almost always caused by the browser's main thread being blocked by other tasks, especially JavaScript processing. Render-blocking CSS and synchronous scripts are the most common culprits.

Each of these focus areas can be optimized to improve the Largest Contentful Paint. To understand the steps you need to take, read Fix &amp; Identify Largest Contentful Paint (LCP) issues.

Common LCP Mistakes

After analyzing millions of page loads through CoreDash, three LCP mistakes appear far more often than any others. Avoiding these will get most sites to a passing LCP score.

Mistake 1: Lazy-Loading the LCP Image

Adding loading="lazy" to your hero image is the single most common LCP mistake. Lazy loading tells the browser to intentionally delay downloading the image until it scrolls into view. For your LCP image (which is already in the viewport), this creates an entirely unnecessary delay. According to CrUX data, 16% of mobile sites make this mistake. CoreDash data shows lazy-loaded LCP images have a 75th percentile of 720ms with 4.3% poor experiences, compared to 364ms and 0% poor for preloaded images. Read our complete guide on how to fix a lazily-loaded LCP image.

Mistake 2: Not Preloading the LCP Image

Even without lazy loading, many sites fail to tell the browser about the LCP image early enough. If the image URL is only discovered after parsing CSS or executing JavaScript, the browser wastes hundreds of milliseconds before it even starts downloading. The fix is to add a preload hint in the <head> of your document:

<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">

This tells the browser to start downloading the image immediately, without waiting for CSS or layout calculations. Combine it with fetchpriority="high" for maximum impact. Learn more in our guide to preloading the LCP image.

Mistake 3: Using a CSS Background Image for LCP

CSS background images loaded via background-image: url(...) are invisible to the browser's preload scanner. The browser cannot discover them until it has downloaded the HTML, parsed the CSS, and built the render tree. This adds significant resource load delay. According to CrUX data, 9% of mobile pages use a CSS background image as their LCP element. The solution is to use a standard <img> tag instead, with the fetchpriority="high" attribute:

<img src="/img/hero.webp"
     alt="Descriptive alt text"
     width="1200"
     height="600"
     fetchpriority="high">

The fetchpriority="high" attribute is a direct signal to the browser that this image is the highest priority resource on the page. As the Google Flights case study demonstrated, this single attribute can reduce LCP by 700ms. For a deeper understanding, see our guide to resource prioritization.

How to Measure the Largest Contentful Paint

The Largest Contentful Paint (LCP) can be measured with pure JavaScript, Lab data, and Field tools. Both have their advantages and disadvantages.

Measure the Largest Contentful Paint with JavaScript

To measure Largest Contentful Paint (LCP) using JavaScript, the Performance Observer API offers a quick solution. The following code snippet demonstrates how to capture the LCP timing and element information:

new PerformanceObserver((list) => {
    const lcpEntry = list.getEntries().at(-1);
    console.log('LCP value: ', lcpEntry.startTime);
    console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  }).observe({ type: 'largest-contentful-paint', buffered: true });

This snippet tracks the LCP entry as it's reported, displaying its timestamp and element details in the console. For more extensive insights, consider using the Web Vitals Library.

Measure Largest Contentful Paint (LCP) in Chrome DevTools

1. Open Chrome DevTools by pressing Ctrl+Shift+I (or Cmd+Option+I on Mac).
2. Navigate to the Performance tab.
3. Reload the page to view the Core Web Vitals.

The DevTools Performance tab now displays information about Core Web Vitals, including the timing and element of the Largest Contentful Paint.

Measure the Largest Contentful Paint with Lab and Field Tools

Let's be clear: Lab and Field data serve two different purposes. You need both.

• Field data (RUM and CrUX) is the only data that actually matters for passing Core Web Vitals. It's what your real users experience. Google uses this data from its CrUX dataset. You start here to find out if you have a problem.
• Lab data (Lighthouse, etc.) is a controlled test. It's not what Google uses for ranking, but it's essential for debugging. You use this to figure out why you have a problem.

Here is a quick guide to the essential tools:

Improving the Largest Contentful Paint

Optimizing LCP requires a systematic approach that addresses the four phases. Anything that happens before the LCP element is painted, whether network-related or CPU-intensive, can impact the LCP score. Don't just chase one fix; understand the entire chain. Here is the high-level strategy:

• Optimize TTFB: Your server needs to be fast. If your TTFB is slow, nothing else matters. This involves server-side caching, using a CDN, and efficient backend code. Read more in our guide to optimizing TTFB.
• Eliminate Resource Load Delay: Ensure the LCP element is in the initial HTML so the browser's preload scanner can find it instantly. Avoid CSS background images for LCP. Preload critical images that are discovered late. Learn how in our guide to fixing Resource Load Delay.
• Reduce Resource Load Time: Make the LCP file smaller. This means using modern image formats like AVIF, responsive images, and proper compression. See our complete guide on how to Optimize the LCP Image. You can also read about how we lowered LCP by 70% on a real project.
• Shorten Element Render Delay: Stop blocking the main thread. Defer non-critical JavaScript, break up long tasks, and minimize render-blocking CSS. This is covered in our guide to fixing Element Render Delay.

Related Deep Dives

This hub page covers the Largest Contentful Paint at a high level. For detailed, actionable guidance on each aspect of LCP optimization, explore these dedicated guides:

• Fix &amp; Identify LCP Issues: A step-by-step diagnostic guide to finding exactly what is causing your slow LCP, using Chrome DevTools, WebPageTest, and CoreDash.
• Optimize the LCP Image: Everything about image formats, responsive images, compression, and serving the optimal image for every device.
• Resource Load Delay: How to ensure the browser discovers your LCP resource as early as possible, including preloading, fetchpriority, and avoiding CSS background images.
• Resource Load Duration: Reducing the actual download time of the LCP resource through file size optimization, CDN configuration, and modern compression.
• Element Render Delay: Eliminating the delay between resource download and screen render by reducing main thread blocking from JavaScript and CSS.