What Is LCP and How to Optimize Largest Contentful Paint

Largest Contentful Paint (LCP) measures how long it takes for the largest visible content element — usually a hero image, banner, or big block of text — to fully render in the viewport after a user starts loading your page. It is one of Google's three Core Web Vitals, and Google considers an LCP of 2.5 seconds or less to be good. In plain terms: LCP is how long your visitor stares at a half-blank screen before the main thing they came to see actually appears.

If your hero image takes eight seconds to show up, the user has already opened the page, gotten bored, and bounced — and Google has quietly filed your site under "slow." This guide explains what LCP is, why it matters for rankings, exactly which element on your page is the culprit, and how to fix it with copy-paste code.

What Is LCP? The Definition

LCP stands for Largest Contentful Paint. It records the render time of the largest content element visible within the viewport, measured from the moment the page starts loading. It does not care about the whole page finishing — only about the single biggest piece of content the user sees.

The "largest content element" is typically one of these:

• A hero image or banner
• A large block of text (a heading or paragraph)
• A <video> poster image
• A background image applied via CSS

Google classifies LCP into three bands, measured at the 75th percentile of real page loads (so three out of four visitors must hit the target):

These thresholds are published by Google on web.dev's LCP guide. If your LCP exceeds 2.5 seconds at the 75th percentile, you fail the metric, and that becomes a competitive disadvantage in search. LCP is one of three Core Web Vitals — see our full breakdown of LCP, CLS, and INP explained if you want the whole picture.

Why LCP Matters for SEO and User Experience

Since the Page Experience update rolled out in 2021, Core Web Vitals have been a confirmed Google ranking signal. LCP is arguably the most consequential of the three because it measures perceived load speed — the moment your visitor decides whether your site feels fast or broken.

Two things are happening at once when LCP is slow:

• Users leave. A blank screen is the fastest way to lose a visitor before they ever read a word.
• Google notices. When two pages have comparable content and relevance, the faster page wins the tiebreaker. Core Web Vitals are the deciding nudge, not the main course — but at competitive positions, the nudge decides.

Google has been explicit that Core Web Vitals are a real ranking factor in its Page Experience documentation. When you understand LCP and fix it, you satisfy the algorithm and give people a faster, less frustrating experience — the two goals point in the same direction. Run a free SlapMyWeb audit to see exactly which element is driving your LCP and how slow it really is.

LCP also rarely travels alone. A page with poor LCP usually has the other two vitals struggling too, so it pays to read this alongside how to fix CLS issues and INP optimization.

1. Identify Your LCP Element

Before you optimize anything, you need to know which element is your LCP. Optimizing the wrong asset wastes hours. To find it:

• Open Chrome DevTools → Performance tab, record a page load, and look for the LCP marker in the timings track. Clicking it highlights the element in the DOM.
• Run Lighthouse (built into DevTools) — the LCP audit names the element directly.
• Use the SlapMyWeb scan tool, which reports your exact LCP element and the time it took.

Common LCP elements by page type:

• Homepage — hero image or main heading
• Blog posts — featured image or the first paragraph
• Product pages — the main product image
• Landing pages — the above-fold banner

Once you know the element, the fix becomes obvious: an image needs different treatment than a text block, which needs different treatment than a CSS background.

2. Optimize the Hero Image

The number-one LCP killer is an unoptimized hero image. If your LCP element is an image, do all of this:

• Convert to WebP or AVIF — these formats are typically 30–50% smaller than JPEG at the same visual quality.
• Resize to the exact display dimensions — never serve a 4000px image into a 1200px container.
• Compress aggressively — quality 75–80 is visually lossless for most photos.
• Serve responsive images with srcset so phones download a smaller file than desktops.

<!-- Responsive hero image with modern formats -->
<picture>
  <source
    srcset="/images/hero-800.avif 800w,
            /images/hero-1200.avif 1200w,
            /images/hero-1600.avif 1600w"
    type="image/avif"
    sizes="100vw"
  />
  <source
    srcset="/images/hero-800.webp 800w,
            /images/hero-1200.webp 1200w,
            /images/hero-1600.webp 1600w"
    type="image/webp"
    sizes="100vw"
  />
  <img
    src="/images/hero-1200.jpg"
    alt="Main banner showcasing product features"
    width="1200"
    height="600"
    fetchpriority="high"
    decoding="async"
  />
</picture>

The fetchpriority="high" attribute is the single most impactful line here — it tells the browser this image is critical and should be fetched before lower-priority resources. The width and height attributes also reserve space so the image doesn't cause a layout shift while it loads.

For a deeper walkthrough of formats, compression, and tooling, see our image optimization for SEO guide.

3. Preload Critical Resources

If your LCP element depends on a resource the browser discovers late — like a CSS background image or a custom font — the browser won't even know to fetch it until it has parsed the CSS. Preloading moves that discovery to the instant the HTML arrives.

<head>
  <!-- Preload hero image so the browser fetches it immediately -->
  <link
    rel="preload"
    href="/images/hero-1200.webp"
    as="image"
    type="image/webp"
    fetchpriority="high"
  />

  <!-- Preload critical font to prevent text rendering delay -->
  <link
    rel="preload"
    href="/fonts/heading.woff2"
    as="font"
    type="font/woff2"
    crossorigin
  />

  <!-- Preconnect to a CDN if images are served externally -->
  <link rel="preconnect" href="https://cdn.example.com" />
</head>

This is especially powerful for CSS background images, which are invisible to the browser's preload scanner until stylesheets are downloaded and parsed. A <link rel="preload" as="image"> skips that delay entirely.

4. Eliminate Render-Blocking CSS and JavaScript

Every external stylesheet and every synchronous <script> in your <head> blocks the browser from rendering anything until it is downloaded and parsed. That delay lands directly on your LCP. To clear the path:

• Inline critical CSS — extract only the styles needed for above-fold content and put them in a <style> tag.
• Defer non-critical CSS — load the rest asynchronously.
• Defer JavaScript — add defer (or async where order doesn't matter) to script tags.
• Remove unused CSS — tools like PurgeCSS strip dead styles your page never uses.

<head>
  <!-- Critical CSS inlined for instant rendering -->
  <style>
    .hero { position: relative; min-height: 60vh; }
    .hero img { width: 100%; height: auto; object-fit: cover; }
    .hero-text { position: absolute; top: 50%; transform: translateY(-50%); }
  </style>

  <!-- Non-critical CSS loaded asynchronously -->
  <link
    rel="stylesheet"
    href="/css/main.css"
    media="print"
    onload="this.media='all'"
  />

  <!-- JavaScript deferred so it does not block rendering -->
  <script src="/js/app.js" defer></script>
</head>

If your scores are still poor after this, your problem may be broader than LCP alone — work through how to improve website speed and check what your PageSpeed score actually means.

5. Serve Static Assets From a CDN

A Content Delivery Network serves your images and files from edge servers physically close to your users. If your origin server is in Europe and your visitor is in Karachi, you're paying 150ms+ of latency on every request — and that latency compounds on the LCP image.

Solid options:

• Cloudflare — generous free tier
• AWS CloudFront — deep ecosystem integration
• Bunny CDN — excellent value
• Vercel Edge Network — built in for Next.js sites

Moving static assets to a CDN typically trims a meaningful chunk of LCP for geographically distant users — the further your audience, the bigger the win.

6. Reduce Server Response Time (TTFB)

Time to First Byte (TTFB) is the time before the browser even receives the first byte of HTML, and it sets a floor under your LCP. If your server takes 2 seconds to respond, no amount of front-end tuning gets you under 2.5 seconds.

Bring TTFB down by:

• Enabling server-side caching (Redis, Varnish, or full-page caching)
• Using HTTP/2 or HTTP/3 for multiplexed connections
• Optimizing slow database queries
• Upgrading to a faster hosting provider
• Rendering at the edge (SSR served from the CDN layer)

A slow TTFB is invisible in most front-end checklists, which is why it's a frequent cause of "I optimized everything and LCP is still bad."

7. Lazy Load Below-Fold Images — Never the LCP Element

Lazy loading is excellent for images below the fold, but applying it to your LCP element is one of the most common and most damaging mistakes. If your hero image has loading="lazy", the browser deliberately waits to load it — wrecking your LCP score.

<!-- WRONG: never lazy load the hero / LCP image -->
<img src="/hero.webp" loading="lazy" alt="Hero banner" />

<!-- CORRECT: hero loads immediately, below-fold images are lazy -->
<img src="/hero.webp" fetchpriority="high" alt="Hero banner" />
<img src="/section-2.webp" loading="lazy" alt="Feature section" />
<img src="/section-3.webp" loading="lazy" alt="Testimonials" />

The rule is simple: above-fold critical content loads eagerly with fetchpriority="high"; everything below the fold gets loading="lazy". Our lazy loading guide covers the edge cases, including videos and iframes.

Common LCP Mistakes

These are the issues we see most often when auditing real sites:

• Lazy loading the LCP image — pulls it out of the critical path entirely
• Serving oversized images — a 5MB hero will never render in 2.5 seconds
• Too many render-blocking resources — 15 stylesheets in the <head> is a guaranteed fail
• Missing image dimensions — causes layout shifts that also hurt CLS
• Third-party scripts in the head — analytics, chat widgets, and ads stealing bandwidth from your content
• Client-side rendering with no SSR — SPAs that ship empty HTML and paint nothing until JS executes
• Unoptimized web fonts — large font files that delay text rendering when the LCP element is text

If you're running an online store, the stakes are higher and the patterns differ slightly — read Core Web Vitals for e-commerce for storefront-specific fixes.

Tools to Measure and Monitor LCP

Understanding LCP is only half the job — you need to measure it continuously, because real-world LCP (field data) often differs from lab tests:

• SlapMyWeb Audit — our scan tool reports LCP with the exact element causing the delay
• Google PageSpeed Insights — combines lab and field (CrUX) data in one view
• Chrome DevTools Performance panel — frame-by-frame analysis of what painted when
• Google Search Console — the Core Web Vitals report shows page-level field data grouped by issue
• Web Vitals Chrome Extension — a live LCP overlay as you browse

LCP is part of any serious technical health check. For the full sweep — crawlability, indexing, structured data, and performance together — work through our complete technical SEO guide or follow the step-by-step SEO audit.

Frequently Asked Questions

What is a good LCP score?

A good LCP score is 2.5 seconds or less, measured at the 75th percentile of real page loads. That means at least 75% of your visitors must experience LCP under 2.5 seconds for the page to pass. Anything above 4 seconds is classified as "poor" by Google.

Does LCP affect mobile and desktop rankings separately?

Yes. Google measures Core Web Vitals separately for mobile and desktop. Because Google uses mobile-first indexing, your mobile LCP carries the most weight — and mobile LCP is usually worse, thanks to slower networks and less powerful processors. Always optimize for the mobile experience first.

Can a text element be the LCP?

Absolutely. If a large heading or paragraph occupies more viewport area than any image, that text block becomes your LCP element. When text is your LCP, the priority shifts to fast font loading (preloading the font, using font-display: swap) and eliminating render-blocking CSS rather than image work.

How do I fix LCP on a JavaScript framework like React or Vue?

Implement Server-Side Rendering (SSR) or Static Site Generation (SSG). Client-rendered SPAs ship near-empty HTML, so LCP cannot even begin until the JavaScript downloads, parses, and executes. Frameworks like Next.js and Nuxt provide SSR and SSG out of the box, which lets the browser paint meaningful content immediately.

What is the difference between LCP and TTFB?

TTFB (Time to First Byte) is how long the server takes to send the first byte of HTML; LCP is how long until the largest visible element finishes rendering. TTFB is a component of LCP — it sets the earliest possible moment LCP can occur. A fast LCP is impossible if TTFB is slow, which is why server response time is a prerequisite, not an afterthought.