Largest Contentful Paint (LCP)

Quick definition

Largest Contentful Paint, usually shortened to LCP, measures how long it takes until the largest visible content element in the viewport has been rendered. The clock starts when the user begins navigating to the page. The element can be an image, a video poster or first video frame, a background image loaded through CSS, or a block of text.

LCP is one of the three Core Web Vitals, next to Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). It describes loading from the user's point of view: not "when did the server answer" or "when was the whole page done", but "when did the thing I came for become visible".

The thresholds that count

Google and the Chrome team publish three ranges for LCP:

• Good: 2.5 seconds or less
• Needs improvement: more than 2.5 seconds and up to 4 seconds
• Poor: more than 4 seconds

The evaluation does not use an average. A page or URL group meets the threshold when at least 75 percent of page visits reach the good range. Mobile and desktop are assessed separately. A page can therefore pass on desktop and fail on mobile, which is a common pattern because phones have slower CPUs and less stable networks.

The 75th percentile is a deliberate choice. It keeps a few extreme visits from dominating the result, but it still forces you to care about the slower part of your audience instead of the best case on an office connection.

Which element becomes the LCP element

The browser does not know in advance which element will be the largest. While the page loads, it reports a new LCP candidate each time a larger element is painted. The last candidate before the user interacts with the page is the final value. A tap, a click, a key press, or a scroll ends the observation, because interaction usually changes what the user is looking at.

These element types can become LCP candidates:

• <img> elements, including the first frame of an animated image
• <image> elements inside an SVG
• <video> elements, using the poster image or the first rendered frame
• elements with a background image loaded through url(), but not CSS gradients
• block-level elements that contain text

Only the part of an element that is visible in the viewport counts toward its size. Margins, padding, and borders do not. For a scaled image, the browser uses the smaller of the displayed size and the intrinsic size, so an upscaled thumbnail does not get extra credit.

Chrome also applies a few heuristics. Elements with zero opacity are ignored, elements that cover the whole viewport are treated as background rather than content, and low-information placeholder images are excluded. This is why the LCP element is sometimes not the element you expected. On many sites it is a headline or an intro paragraph, and on some it is the text of a cookie consent banner.

Field data and lab data

LCP exists in two worlds, and mixing them up causes most of the confusion around the metric.

Field data decides the status

Field data comes from real visits. The Chrome User Experience Report (CrUX) collects it from Chrome users who have opted in, aggregated over a rolling 28-day window. PageSpeed Insights shows this data for a URL or the whole origin when enough traffic exists, and the Core Web Vitals report in Google Search Console groups similar URLs and labels them good, needs improvement, or poor.

Two consequences matter in practice. First, a fix shows up in the field only gradually, because the 28-day window has to fill with new visits. Second, CrUX only reflects Chrome users. If a large share of your audience uses Safari on iPhones, the field data tells you nothing direct about their experience.

Lab data explains the cause

Lab data comes from a controlled test, for example Lighthouse, the Lighthouse run inside PageSpeed Insights, or the Performance panel in Chrome DevTools. A lab test loads the page once under defined conditions, usually with an emulated mid-range phone and a throttled network.

Lab values are reproducible and they show the waterfall, the LCP element, and the blocking resources. They do not show what returning visitors with a warm cache, users behind a consent banner, or people on a fast fiber line experience. A lab LCP of 3.1 seconds and a field LCP of 2.2 seconds are not a contradiction. They describe different visits.

A workable rule: use field data to decide whether there is a problem and where, then use lab data to find out why.

The four LCP subparts

The web.dev guidance on optimizing LCP breaks the metric into four consecutive subparts. Thinking in these phases turns "the page is slow" into a specific question.

1. Time to First Byte (TTFB): from the start of navigation until the first byte of the HTML response arrives. Slow servers, missing caching, redirects, and long distances to the user show up here.
2. Resource load delay: the time between TTFB and the moment the browser starts loading the LCP resource. A large delay means the browser discovered the image late, for example because JavaScript inserts it or CSS references it.
3. Resource load duration: how long the LCP resource itself takes to download. Oversized files, missing compression, and a congested network connection drive this up.
4. Element render delay: the time between the finished download and the actual paint. Render-blocking stylesheets, long JavaScript tasks, or a client-side framework that has not yet rendered the component cause this delay.

For a text LCP element, the two resource phases are close to zero, and the time splits between TTFB and render delay. web.dev suggests as a rough orientation that most of the time should go to TTFB and the download, with load delay and render delay kept small. Treat that as a diagnostic heuristic, not a fixed budget.

What usually causes a slow LCP

The same patterns appear across very different sites:

• The hero image is discovered late. A slider script, a CSS background, or a client-side component adds the image only after JavaScript runs, so the download starts seconds after the HTML arrived.
• The LCP image is lazy-loaded. loading="lazy" makes sense for images further down the page. On the main above-the-fold image it delays exactly the resource the user waits for.
• The image is far larger than needed. A 2,400 pixel wide JPEG for a 390 pixel wide phone screen wastes most of the transfer.
• The server answers slowly. Uncached pages, slow database queries, and chains of redirects push everything back before the browser can even start.
• Client-side rendering delays the content. If the HTML is an empty shell and a JavaScript bundle builds the page, the LCP element cannot appear before the bundle has loaded and run.
• Render-blocking CSS and fonts. Large stylesheets in the <head> and web fonts that hide text until they load can keep a finished element from painting.

How to improve LCP

Start with the subpart that takes the most time. Fixing render delay does little when TTFB eats two seconds.

For TTFB, cache HTML where possible, serve from a CDN close to your users, remove redirect hops, and look at the slowest backend work on the template. Server-rendered or static HTML usually beats a client-side shell, which is one reason teams look at server-side rendering for content pages.

For resource load delay, make the LCP image discoverable in the initial HTML. Use a normal <img> with src or srcset instead of a JavaScript-inserted element. If the image has to come from CSS, a <link rel="preload"> can help. Add fetchpriority="high" to the LCP image so the browser does not queue it behind less important resources, and remove loading="lazy" from it.

html<img
  src="/images/hero-800.avif"
  srcset="/images/hero-400.avif 400w, /images/hero-800.avif 800w, /images/hero-1600.avif 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="450"
  fetchpriority="high"
  alt="Team reviewing a crawl report">

For resource load duration, serve modern formats such as AVIF or WebP, deliver responsive sizes through srcset and sizes, and compress properly. Our guide to image optimization covers formats and sizing in more detail.

For render delay, reduce render-blocking CSS, defer non-critical JavaScript, keep long tasks out of the critical path, and make sure web fonts do not hide text for long. If the LCP element is text, render delay is usually where the time goes.

Two browser features can make LCP close to instant for repeat or predicted navigations: the back/forward cache, which restores a page from memory, and speculative prerendering through the Speculation Rules API. Both depend on how your site is built, so test them before you rely on them.

A worked example

A travel publisher sees poor mobile LCP for its article template in Search Console. PageSpeed Insights confirms a field LCP of about 4.3 seconds at the 75th percentile. The lab run identifies the LCP element as the article's header image.

The waterfall shows the real problem. The HTML arrives after 600 milliseconds, but the header image only starts downloading after 2.1 seconds, because a gallery script injects it. The image itself is a 380 KB JPEG at desktop size.

The team changes three things: the first gallery image becomes a plain <img> in the server HTML with fetchpriority="high", the image is delivered in responsive AVIF sizes, and the gallery script loads after the first image. In the next lab runs, resource load delay drops to a few hundred milliseconds and LCP falls below 2.5 seconds. Search Console needs several weeks of new visits before the URL group moves, which is normal.

LCP and SEO

Google states that Core Web Vitals are used by its ranking systems as part of page experience, and recommends achieving good values. Google also says that good page experience does not override relevance. A fast page that answers the wrong question will not outrank a slower page that answers the right one.

That makes LCP a tiebreaker and a usability issue rather than a primary ranking lever. The more practical argument is the user. Visitors who wait for the main content bounce or lose patience, and that affects conversions regardless of rankings. Because Google indexes the mobile version of most sites, the mobile LCP of your important templates deserves the first look.

A sensible diagnostic order

1. Open the Core Web Vitals report in Search Console and separate mobile from desktop.
2. Identify the URL groups with poor or needs-improvement LCP, and note which page templates they belong to.
3. Check field data for a representative URL and the origin in PageSpeed Insights.
4. Run a lab test and identify the LCP element. Is it the element you expected?
5. Break the lab LCP into the four subparts and find the largest one.
6. Fix the largest subpart on the template, not just on the example URL.
7. Verify the change in the lab after deployment.
8. Wait for new field data before you call the problem solved.

Common mistakes

• optimizing the Lighthouse score instead of the field LCP of real users
• lazy-loading the main above-the-fold image
• preloading many images at once, which dilutes the priority of the one that matters
• assuming the LCP element is the hero image without checking
• judging a fix after one day, while CrUX still reflects the previous 28 days
• testing only on desktop when Google and most visitors use the mobile version
• treating a green LCP as proof that the page experience is fine, while INP or CLS are poor

The Crawl Foundry perspective

For performance measurement, Crawl Foundry's Site Audit uses the official Lighthouse runner (Lighthouse 13) on our own servers, with each measurement running as an isolated task. The Site Audit itself is a paid data action with the price shown before you start, and the Lighthouse measurement itself costs you nothing extra on top. You get lab values for the URLs you test, under consistent conditions.

Those values are lab data. They help you find the LCP element and the slow phase, but they do not replace CrUX field data or the Core Web Vitals report in Search Console, which remain the sources for how real users experience your pages. Because the same crawl also records status codes, indexability, and internal links, the Site Audit for technical SEO helps you put LCP work where it counts: on indexable URLs that are meant to rank, and not on pages that should not be in search anyway.

Related terms

• Page speed
• Page experience metrics
• Web performance optimization
• JavaScript rendering SEO
• Mobile-first indexing

Review sources

• web.dev: Largest Contentful Paint (LCP)
• web.dev: Optimize Largest Contentful Paint
• web.dev: How the Core Web Vitals metrics thresholds were defined
• Google Search Central: Understanding Core Web Vitals and Google search results
• Chrome for Developers: CrUX methodology
• W3C: Largest Contentful Paint specification
• MDN Web Docs: LargestContentfulPaint