Largest Contentful Paint (LCP): The Complete Guide

Largest Contentful Paint is one of the three Core Web Vitals Google uses to judge real-world page experience. It answers a simple question a visitor cares about: how long until the main thing on this page actually shows up? This guide explains exactly what LCP measures, the official thresholds you must hit, which element usually counts, the four time segments that make up LCP, the most common causes of a slow score, and the fixes that move the needle.

What LCP Measures

LCP records the render time of the largest image or text block visible within the viewport, measured relative to when the page first started loading. The browser keeps updating its LCP candidate as the page paints, and locks in the final value once the user interacts with the page or it finishes loading. The result is a single number, in seconds, that approximates the moment a visitor perceives the page's main content as loaded.

LCP replaced older, easier-to-game proxies for load speed. Earlier metrics could report a page as "loaded" while the visitor still stared at a blank or half-painted screen. By focusing on the largest element in the viewport, LCP tracks something much closer to the human experience of waiting for a page.

The Official LCP Thresholds

Google defines three bands for LCP, and these are the numbers you should design around. They are measured at the 75th percentile of page loads, split across mobile and desktop. In plain terms, 75 percent of your visits need to meet the target before the page is judged as passing.

The 75th percentile matters. A median (50th percentile) score hides the experience of a quarter of your audience, who may be on slower devices or networks. Optimizing to the 75th percentile means you are accounting for the slower end of your real traffic, not just the fastest visits.

Which Element Is Usually the LCP Element

The browser considers a specific set of elements as LCP candidates: images, the poster image of a video, a background image loaded through CSS, and block-level elements containing text. The largest of these within the viewport, by rendered size, wins.

In practice, the LCP element is most often one of these:

• A hero image or large banner near the top of the page
• A main product photo on an ecommerce page
• A large headline or opening paragraph of text
• A video poster frame

Identifying your actual LCP element is the first step in any optimization. The fix for a slow image LCP is very different from the fix for a slow text LCP, so never assume. Tools like PageSpeed Insights and Chrome DevTools will name the exact element for you.

The Four Subparts of LCP

LCP is not a single event. It is the sum of four consecutive time segments. Understanding which segment dominates tells you where to focus. The four subparts are:

1. Time to First Byte (TTFB)

The time from when the user starts loading the page until the browser receives the first byte of the HTML response. This covers DNS lookup, connection setup, redirects, and server processing time. Everything else in LCP happens after this, so a slow TTFB caps how fast LCP can ever be.

2. Resource Load Delay

The gap between TTFB and the moment the browser actually starts loading the LCP resource. If the LCP element is a text node rendered with a system font, this is zero. For images, a long load delay usually means the browser discovered the image late, often because it was referenced by CSS or JavaScript rather than directly in the HTML. On many slow pages this delay is larger than the download itself.

3. Resource Load Time

How long the LCP resource itself takes to download. This depends on file size, image format, compression, and the visitor's connection. For text LCP elements, this is zero. This is the segment you reduce by optimizing and compressing images.

4. Element Render Delay

The time between the LCP resource finishing its download and the element actually painting to the screen. Render-blocking CSS or JavaScript, or a framework that needs to hydrate before painting, push this number up.

The goal is for most of the LCP time to be spent in resource load time, the part that does useful work, and as little as possible in the delays. When a page has poor LCP, the resource load delay is frequently the largest culprit.

Common Causes of a Slow LCP

Slow LCP scores usually trace back to a handful of recurring problems:

• Slow server response. A high TTFB from slow hosting, missing caching, or expensive backend queries delays everything downstream. Server errors compound this, so it is worth understanding how 5xx server errors affect SEO when your origin struggles under load.
• Render-blocking CSS and JavaScript. Stylesheets and scripts in the document head can stop the browser from painting until they are downloaded and processed, inflating render delay.
• Large or unoptimized images. Oversized dimensions, uncompressed files, and legacy formats make the LCP resource load time far longer than it needs to be.
• Client-side rendering. Pages that ship a near-empty HTML shell and build content in the browser force visitors to wait for JavaScript to download, parse, and execute before the LCP element can appear.
• Late resource discovery. When the LCP image is set via CSS background or injected by script, the browser finds it late and starts the download too slowly.

How to Fix LCP

Preload the LCP image and set fetchpriority

Images are assigned a low priority by default, so the browser may not fetch the LCP image early enough. Add fetchpriority="high" to the LCP image tag so the browser treats it as urgent. If the image is discovered late, also add a preload link in the head and give that the same high priority, since preload alone does not raise priority. This pairing attacks the resource load delay directly and is one of the highest-leverage fixes available.

Optimize your images

Serve images at the dimensions they are actually displayed at, compress them, and use modern formats. Use responsive image markup so phones do not download desktop-sized files. This shrinks the resource load time segment. Just as importantly, never lazy-load the LCP image: lazy loading the first visible image delays the very thing you are trying to speed up.

Reduce render-blocking resources

Inline the critical CSS needed for the above-the-fold view and defer the rest. Defer or async non-essential JavaScript so it does not hold up the first paint. Minimizing render-blocking work cuts the element render delay.

Improve TTFB and caching

Use a CDN to serve content closer to visitors, enable full-page and object caching, and reduce expensive server-side work. Lowering TTFB raises the ceiling for every other LCP segment, because nothing can start until the first byte arrives.

Prefer server-side rendering

If your site is built on a JavaScript framework, server-side rendering or static generation sends meaningful HTML in the first response, so the LCP element can paint without waiting for client-side hydration. This is especially important for crawlability too, which is why a solid JavaScript SEO and rendering strategy pays off for both LCP and indexing.

How to Measure LCP: Field vs Lab

There are two ways to measure LCP, and they answer different questions.

Field data reflects what real visitors experienced. The Chrome User Experience Report (CrUX) aggregates anonymized data from actual Chrome users and is the source Google uses to assess Core Web Vitals at the 75th percentile. You can see field data in PageSpeed Insights, Search Console's Core Web Vitals report, and the CrUX dashboards. This is the data that determines whether your page passes.

Lab data comes from a controlled, simulated load in a tool like Lighthouse or Chrome DevTools. It is repeatable and great for debugging because it gives you the element breakdown and the four subparts on demand. But it runs on one simulated device and network, so it will not always match what real users see.

The practical workflow: watch field data to know if you have a problem and whether fixes are working over time, and use lab data to diagnose the cause and test changes before they ship. The same lab-versus-field distinction applies to the other Core Web Vitals, including Interaction to Next Paint (INP).

Frequently Asked Questions