Largest Contentful Paint (LCP)

Table of Contents

  1. Definition
    1. Why it matters for marketing
  2. How it works
    1. The threshold
  3. How to utilize LCP
  4. Best practices
  5. Future trends
  6. FAQs
  7. Related Terms
  8. Sources

Definition

Largest Contentful Paint measures how long it takes for the largest visible piece of content to render in the viewport, timed from when the page first starts loading. That element is usually a hero image, a big heading, or a block of text — whatever’s physically biggest in the part of the screen a visitor sees before scrolling. LCP is one of the three Core Web Vitals, and it’s the one that answers a simple question: how fast does the page feel like it’s loaded?

Google’s “good” threshold is 2.5 seconds or less, scored at the 75th percentile of real visits. It’s a field metric, drawn from the Chrome User Experience Report, and it only counts elements inside the viewport — the top ten images on a page of fifty are what get measured, because they’re what the visitor actually sees first.

Disambiguation: LCP is a Google-defined metric, and it’s easy to confuse with First Contentful Paint (FCP), which marks when the first visible element appears. FCP can flash a header or a spinner and look fast while the real content is still loading; LCP waits for the largest, most meaningful element. LCP replaced older, murkier markers like onload time and First Meaningful Paint precisely because those didn’t line up with what people perceive.

Back to Top

Why it matters for marketing

LCP is the closest thing in the Core Web Vitals set to a proxy for “does this page make a good first impression.” Visitors don’t care how many scripts finished; they care when the thing they came to read or buy shows up. Slow LCP pushes up bounce and abandonment, and it does so most on the mobile, mid-connection users who make up the bulk of many audiences.

Because Core Web Vitals are a Google ranking signal, LCP also carries SEO weight — as a tiebreaker in competitive results rather than a magic lever. And it tends to be the most fixable of the three: LCP problems trace back to a handful of predictable causes (a slow server, a heavy image, render-blocking code), which makes it a sensible first target when a team is deciding where to spend performance effort.

See also: Core Web Vitals (CWV) · Interaction to Next Paint (INP) · Cumulative Layout Shift (CLS) · AI Overviews

Back to Top

How it works

LCP isn’t one slow thing. It’s the end of a chain of steps that all have to finish before the browser can paint your biggest above-the-fold element. Google’s engineering docs break the timeline into four phases:

  1. Time to First Byte (TTFB) — how long the server takes to send the first byte of HTML. Aim for under about 800 ms.
  2. Resource load delay — the gap between TTFB and when the browser starts fetching the LCP element.
  3. Resource load duration — how long the LCP resource (often an image) takes to download.
  4. Element render delay — the time between the resource finishing and the element actually appearing on screen.

Diagnosing LCP means figuring out which of these four phases is eating the time, because the fix is different for each. A slow TTFB points at your server or hosting; a long render delay points at render-blocking CSS or JavaScript.

Back to Top

The threshold

RatingLCP value (at 75th percentile)
Good≤ 2.5 seconds
Needs improvement2.5 – 4.0 seconds
Poor> 4.0 seconds

Source: Google Search Central and web.dev (see Sources). Measured from real Chrome users, segmented across mobile and desktop.

Back to Top

How to utilize LCP

Find the element first. In PageSpeed Insights or Chrome DevTools, the “Largest Contentful Paint element” callout tells you exactly which piece of content Google is timing — sometimes a hero image, sometimes a headline, sometimes a video poster. You can’t optimize what you haven’t identified.

Then read the phase breakdown. Chrome DevTools shows LCP split by phase as a percentage, so you can see whether the delay is mostly server response, load delay, download, or render. That’s the difference between guessing and fixing.

Common use cases:

  • Ecommerce landing pages. The hero image is almost always the LCP element, and it’s almost always heavier than it needs to be. Compressing and prioritizing it is high-leverage work.
  • Content and publisher sites. Where the LCP element is a text block, web-font loading is the usual bottleneck — the text can’t paint until the font arrives.
  • JavaScript-heavy apps. Client-side rendering ships an empty shell that fills in later, which can wreck LCP. Server-side rendering or a hybrid approach often fixes it, though it’s a real project, not a toggle.
Back to Top

Best practices

  • Prioritize the LCP image. Preload it and set fetchpriority="high" so the browser fetches it early instead of treating it like any other asset.
  • Compress and modernize images. Serve WebP or AVIF, resize to the actual display dimensions, and lean on a CDN to cut geographic latency. A 3 MB hero is a self-inflicted wound.
  • Kill render-blocking resources. Split CSS into critical (above-the-fold) and non-critical, inline the critical part, and defer the rest. Load only what the first paint needs.
  • Cache aggressively. On WordPress and similar stacks, a caching layer stops the server from rebuilding the page for every visitor, which trims TTFB.
  • Handle fonts deliberately. If your LCP element is text, use font-display: swap and preload the font so text isn’t held hostage.
  • Consider server-side rendering for heavy client-side apps — but weigh it. It’s the right call for content and commerce sites, and often overkill for a genuinely app-like interface.
Back to Top

Google keeps refining what LCP covers. Support for measuring LCP across soft navigations in single-page applications has been a work in progress, and the Chrome team has floated adding element types (like SVG) that currently don’t count toward the score. The stable “good” threshold of 2.5 seconds has held, but the mechanics underneath it move.

The AI-search dimension applies here too. A fast-rendering LCP element helps answer engines and crawlers get to your main content quickly, which supports visibility in AI Overviews alongside classic search. Speed that helps a human see your hero image faster helps a machine parse it faster.

Back to Top

FAQs

What is a good LCP score? 2.5 seconds or less, measured at the 75th percentile of real visits. Between 2.5 and 4 seconds needs improvement; above 4 seconds is poor.

What element counts as the “largest contentful paint”? The biggest visible content element in the viewport when the page loads — commonly a hero image, a large heading, a text block, or a video poster image. It only counts what’s above the fold.

What’s the difference between LCP and First Contentful Paint? FCP marks when the first visible element appears; LCP marks when the largest, most meaningful one does. A page can score a fast FCP while the real content is still loading, which is why LCP is the stronger signal of perceived speed.

Why is my LCP slow even though the page looks fast to me? LCP is graded on field data from real users, many on mid-range phones and slower connections. Your own fast device isn’t representative. Check the field score in Search Console or PageSpeed Insights, not just your local test.

What are the most common causes of poor LCP? Slow server response (high TTFB), oversized or unoptimized images, render-blocking CSS and JavaScript, and heavy client-side rendering. The phase breakdown in DevTools tells you which one is dominating.

How do I find my LCP element? Run the page through PageSpeed Insights or open Chrome DevTools; both surface the specific “Largest Contentful Paint element” so you know what to optimize.

Does LCP affect Google rankings? Yes, as part of Core Web Vitals and page experience signals — but as a tiebreaker between comparable pages, not something that outranks stronger, more relevant content.

Is LCP measured differently on mobile and desktop? Yes. The viewport differs, so the LCP element can differ too, and Google reports separate scores. Mobile is usually the harder score to pass.

Will preloading the hero image always fix LCP? It helps when resource load delay or duration is the bottleneck, which is common. If the real problem is a slow server (TTFB) or render-blocking scripts, preloading alone won’t be enough — fix the dominant phase.

Back to Top
  1. Core Web Vitals (CWV)
  2. Interaction to Next Paint (INP)
  3. Cumulative Layout Shift (CLS)
  4. AI Overviews
  5. First Contentful Paint (FCP) (no dedicated entry yet — internal-link candidate)
  6. Time to First Byte (TTFB) (no dedicated entry yet — internal-link candidate)
  7. Render-blocking resources (no dedicated entry yet — internal-link candidate)
  8. Image optimization (no dedicated entry yet — internal-link candidate)
  9. PageSpeed Insights (no dedicated entry yet — internal-link candidate)
  10. Server-side rendering (SSR) (no dedicated entry yet — internal-link candidate)

Freshness note: LCP is a Google-defined metric; its “good” threshold of 2.5 s is current as of July 2026 but is set and revised by Google’s Chrome team.

Back to Top

Sources

Back to Top

Tags:

Was this helpful?

Previous

Key Success Indicator (KSI)

Next

Lead Velocity Rate (LVR)