How to Improve LCP (Largest Contentful Paint): The Complete 2026 Guide

Your LCP Score Is Costing You Rankings

Here's something most site owners don't realize: of the three Core Web Vitals that Google uses for rankings, Largest Contentful Paint (LCP) is the one that fails most often. According to the Chrome User Experience Report, over 40% of websites don't meet Google's LCP threshold.

If your pages take more than 2.5 seconds to show the main content, Google considers that a poor experience. And poor experience means lower rankings.

The good news? LCP is also the most fixable Core Web Vital. Unlike CLS (which can be tricky to reproduce) or INP (which depends on complex JavaScript interactions), LCP problems usually come down to a handful of common causes with clear solutions.

Let's break down exactly what LCP is, how to find your score, and how to fix it.

What Is Largest Contentful Paint?

Largest Contentful Paint measures how long it takes for the biggest visible element on the page to fully render. That's usually a hero image, a video thumbnail, a large heading, or a background image.

Think about it from the user's perspective: they click a link and see a blank page. Then the navigation loads. Then some text appears. Finally, the hero image loads and the page looks "done." That moment when the main content appears? That's LCP.

Google's thresholds:

Good: 2.5 seconds or less

Needs Improvement: 2.5 to 4.0 seconds

Poor: Over 4.0 seconds

These thresholds apply to the 75th percentile of page loads. That means 75% of your real users need to experience an LCP of 2.5 seconds or less for Google to consider your LCP "good."

How to Check Your LCP Score

Before you can fix LCP, you need to know where you stand. There are two types of LCP data, and understanding the difference matters:

Lab data (Lighthouse, PageSpeed Insights bottom section): This simulates a page load on a throttled connection. It's useful for debugging but doesn't reflect real user experience. Your lab LCP might be 1.8 seconds while real users on slow phones see 4+ seconds.

Field data (CrUX, PageSpeed Insights top section): This comes from real Chrome users visiting your site over 28 days. This is what Google actually uses for rankings. It's the number that matters.

How to check both at once: Run your URLs through BulkAudit. You'll see both your Lighthouse lab LCP and your CrUX field LCP side by side. If you have multiple pages, audit them all at once — LCP can vary dramatically between pages.

Pay special attention to mobile LCP. Google uses mobile-first indexing, so your mobile LCP is what matters for rankings. Run audits with the "Mobile" setting to see what Google sees.

The 4 Root Causes of Slow LCP

Every slow LCP comes down to one or more of these four bottlenecks. Understanding which one is affecting you is the key to fixing it efficiently.

1. Slow Server Response Time (TTFB)

Before the browser can even start rendering your page, it needs to receive the HTML from your server. If your server takes 2 seconds to respond, your LCP can't possibly be under 2.5 seconds.

Symptoms:

Time to First Byte (TTFB) over 800ms

Slow LCP across all pages, not just image-heavy ones

LCP element is text, not an image

Common causes:

Shared hosting with limited resources

No server-side caching

Slow database queries

Server located far from your users

No CDN

2. Render-Blocking Resources

Even after the browser receives the HTML, it might have to stop and download CSS and JavaScript files before it can render anything. Every render-blocking resource adds delay.

Symptoms:

Big gap between TTFB and First Contentful Paint (FCP)

Lighthouse flags "Eliminate render-blocking resources"

Multiple large CSS or JS files in the head

Common causes:

Large CSS files loaded synchronously

JavaScript in the head without async or defer

Third-party scripts blocking render (analytics, chat widgets, ad scripts)

Too many font files loading upfront

3. Slow Resource Load Time

If your LCP element is an image (which it is on most pages), the time to download that image directly affects LCP. A 2MB hero image on a 3G connection will kill your LCP.

Symptoms:

LCP element is an image or video poster

Good FCP but slow LCP (big gap between the two)

Lighthouse flags "Properly size images" or "Serve images in next-gen formats"

Common causes:

Uncompressed or oversized images

Images served in old formats (PNG/JPEG instead of WebP/AVIF)

No CDN for static assets

No responsive images (serving desktop-size images on mobile)

4. Client-Side Rendering Delays

If your LCP element is only rendered after JavaScript executes (common in React, Vue, and other SPA frameworks), the browser has to download, parse, and execute JavaScript before it can even start rendering the main content.

Symptoms:

Very slow LCP on JavaScript-heavy sites (React SPAs)

LCP element doesn't appear in the initial HTML source

Good performance on fast devices but terrible on mid-range phones

Common causes:

Single-page application rendering everything client-side

LCP element loaded dynamically via JavaScript

Heavy JavaScript bundles delaying render

No server-side rendering or static generation

12 Proven Techniques to Fix Slow LCP

Now let's get practical. Here are the specific fixes, ordered by impact. Start with the ones that match your root cause.

1. Optimize Your LCP Image

This single fix improves LCP for most websites. If your LCP element is an image (check Lighthouse to confirm), do all of these:

Convert to WebP or AVIF. WebP is 25-35% smaller than JPEG at the same quality. AVIF is even smaller but has less browser support. Use WebP as a safe default.

Resize to the actual display size. If your hero image displays at 800px wide, don't serve a 2400px original. Use responsive images with the srcset attribute.

Compress aggressively. For hero images, quality 75-80% is usually indistinguishable from 100%. Use tools like Squoosh, Sharp, or ImageOptim.

Set explicit width and height on the img tag to prevent layout shifts while loading.

Target: Get your LCP image under 100KB for mobile, under 200KB for desktop.

2. Preload the LCP Image

The browser discovers images by parsing HTML and CSS. If your LCP image is a CSS background image or buried deep in the HTML, the browser finds it late. Tell it to start downloading immediately:

Add a preload link in the head: link rel="preload" as="image" href="/hero.webp"

For responsive images, use the imagesrcset attribute on the preload link

Only preload the LCP image — preloading too many resources defeats the purpose

This alone can cut 200-500ms off your LCP.

3. Use a CDN for All Static Assets

A CDN serves your images, CSS, and JavaScript from servers close to your users instead of from a single origin. If a user in Tokyo is loading images from a server in Virginia, the round-trip latency adds hundreds of milliseconds.

Cloudflare (free tier) handles most sites and auto-optimizes images

Vercel and Netlify include global CDN by default

AWS CloudFront or Google Cloud CDN for larger deployments

Make sure both your HTML and your static assets are served from edge locations

4. Implement Server-Side Caching

Every time a user requests a page, your server shouldn't have to rebuild it from scratch. Caching saves the result and serves it instantly.

Full page caching: Use Redis, Varnish, or your framework's built-in caching to serve pre-built HTML

Database query caching: Cache expensive queries that don't change often

CDN caching: Set proper Cache-Control headers so the CDN caches your pages at the edge

Stale-while-revalidate: Serve cached content immediately while refreshing in the background

A well-configured cache can drop TTFB from 2 seconds to under 100ms.

5. Eliminate Render-Blocking CSS

The browser won't render anything until all CSS in the head is downloaded and parsed. Reducing this bottleneck directly improves LCP.

Inline critical CSS. Extract the CSS needed for above-the-fold content and inline it directly in the HTML. Tools like Critical or Critters automate this.

Defer non-critical CSS. Load below-the-fold stylesheets asynchronously using the media="print" trick or loadCSS pattern.

Remove unused CSS. Most sites ship 80-90% unused CSS. PurgeCSS or the Coverage tool in Chrome DevTools can identify dead CSS.

Minify CSS. Remove whitespace and comments. Most build tools do this automatically.

6. Defer Non-Critical JavaScript

JavaScript in the head without async or defer blocks rendering. Third-party scripts are the biggest offenders.

Add defer to your own scripts. This lets the browser parse HTML while downloading JavaScript.

Add async to independent scripts. Analytics and tracking scripts usually don't need to block anything.

Move third-party scripts below the fold. Chat widgets, social embeds, and ad scripts should load after the main content.

Lazy-load heavy third-party scripts. Load intercom, hotjar, or similar tools only after user interaction or after a delay.

7. Optimize Font Loading

Custom fonts can delay text rendering, which hurts LCP when your largest element is a heading.

Use font-display: swap. This shows a fallback font immediately while the custom font loads, so text is visible right away.

Preload your primary font. Add a preload link for the font file used in your LCP element.

Self-host fonts instead of loading from Google Fonts. This eliminates an extra DNS lookup and connection.

Subset your fonts. If you only need Latin characters, don't load the full Unicode range.

8. Use Server-Side Rendering or Static Generation

If you're using a JavaScript framework like React, Vue, or Angular, and your pages render entirely on the client, your LCP will suffer. The browser has to download your JS bundle, parse it, execute it, fetch data, and then render — all before the user sees content.

Static Generation (SSG): Pre-build pages at deploy time. Best for content that doesn't change per-request (blogs, marketing pages, documentation).

Server-Side Rendering (SSR): Render on the server for each request. Better for dynamic content (dashboards, user-specific pages).

Streaming SSR: Start sending HTML to the browser before the full page is ready. Next.js and React Server Components support this.

Switching from client-side rendering to SSG/SSR typically cuts LCP by 40-60%.

9. Optimize Largest Contentful Paint for Mobile Specifically

Mobile devices have slower CPUs, less memory, and often slower connections. A page that loads in 1.5 seconds on your MacBook might take 5 seconds on a mid-range Android phone.

Test on real devices. Chrome DevTools throttling doesn't perfectly simulate real phone performance.

Serve smaller images on mobile using responsive images with srcset and sizes attributes.

Reduce JavaScript. Mobile CPUs take 3-5x longer to parse and execute JavaScript compared to desktop.

Consider separate mobile optimizations. Sometimes a simpler mobile layout with fewer resources is better than a responsive design that tries to do everything.

10. Reduce DOM Size

A large DOM (lots of HTML elements) slows down rendering because the browser has to calculate styles and layout for every element.

Remove unnecessary wrapper divs. Many frameworks and component libraries add extra nesting.

Virtualize long lists. If you show 100+ items, only render the visible ones.

Lazy-load below-the-fold content. Don't render content that's not visible until the user scrolls to it.

Target: Keep your DOM under 1,500 elements. Pages with 3,000+ elements see measurable rendering delays.

11. Avoid Lazy-Loading the LCP Image

This is a common mistake. Lazy loading is great for images below the fold, but if you lazy-load your hero image, you're adding unnecessary delay. The browser won't start downloading it until it's in the viewport.

Never add loading="lazy" to your LCP image. This includes any above-the-fold hero images, featured images, or large headings.

Set fetchpriority="high" on the LCP image to tell the browser to prioritize it.

Check your framework defaults. Some image components (like Next.js Image) automatically lazy-load all images. Override this for your LCP image.

12. Monitor LCP Continuously

LCP regressions happen gradually. A developer adds a larger image, a new script gets added, a CDN config changes. Without monitoring, you won't notice until rankings drop.

Set up scheduled audits in BulkAudit to run daily or weekly checks across all your important pages.

Monitor both lab and field LCP. Lab tells you when you've introduced a problem. Field tells you when real users are affected.

Track trends over time. A single snapshot doesn't tell you much. Trends show you whether things are getting better or worse.

Set up alerts for LCP regressions so you catch problems before Google does.

Common LCP Mistakes to Avoid

After auditing hundreds of sites, here are the patterns I see over and over:

Mistake 1: Optimizing the wrong element. People optimize random images without checking which element is actually the LCP. Use Lighthouse to identify your LCP element first, then optimize that specific element.

Mistake 2: Over-relying on lazy loading. Lazy loading everything, including above-the-fold content, hurts rather than helps LCP. Be surgical with lazy loading.

Mistake 3: Ignoring mobile. Your desktop LCP might be 1.5 seconds while mobile is 4.5 seconds. Google uses mobile for rankings. Always check mobile first.

Mistake 4: Fixing lab scores but not field scores. Your Lighthouse LCP might look great, but if real users on slow connections are seeing 5-second LCP, your CrUX data will still show a failing score. Monitor real user metrics.

Mistake 5: Adding more JavaScript to fix JavaScript problems. Performance monitoring scripts, A/B testing tools, and optimization libraries all add weight. Sometimes removing things is more effective than adding things.

A Practical LCP Improvement Workflow

Here's the exact process to follow when fixing LCP:

Step 1: Measure. Audit your pages with BulkAudit to get both lab and field LCP scores. Identify which pages have the worst LCP.

Step 2: Identify the LCP element. Run Lighthouse and look at the "Largest Contentful Paint element" diagnostic. This tells you exactly which element to focus on.

Step 3: Identify the bottleneck. Is it slow server response (high TTFB)? Render-blocking resources? A huge image? Client-side rendering? The Performance tab in Chrome DevTools shows you the full loading waterfall.

Step 4: Apply targeted fixes. Don't try to fix everything at once. Address the biggest bottleneck first, then re-measure.

Step 5: Verify improvement. Run the audit again. Check that both lab and field LCP improved. Field data takes 28 days to fully update in CrUX, but you should see lab improvements immediately.

Step 6: Set up monitoring. Schedule recurring audits to catch regressions early. LCP can degrade over time as content and code changes accumulate.