How to Fix Largest Contentful Paint (LCP) in 2026

You ran PageSpeed Insights, saw a green Lighthouse score, and assumed LCP was handled. Then Search Console flagged the same page as "needs improvement" a month later. Confusing, right?

That gap is the single most common reason people struggle with Largest Contentful Paint. They optimize for the lab test and ignore the field data that Google actually uses for ranking. This guide fixes the number that counts.

Quick Answer: Largest Contentful Paint measures how long it takes for the biggest visible element (usually a hero image, heading, or block of text) to render. Google treats 2.5 seconds or less as good, measured at the 75th percentile of real visits. To fix a slow LCP, break it into its four parts (time to first byte, resource load delay, resource load duration, and element render delay), find which part is largest, and attack that one. The highest-leverage fixes are preloading the LCP image with high fetch priority, never lazy-loading it, cutting render-blocking CSS and JavaScript, and lowering server response time with caching or static generation.

What Is a Good LCP Score in 2026?

Google's threshold has not moved. An LCP of 2.5 seconds or less is good, between 2.5 and 4 seconds needs improvement, and anything over 4 seconds is poor.

The part people miss is how it's measured. Google does not use your average load time. It uses the 75th percentile of loads across real users over a rolling 28-day window. That means a quarter of your visitors can be slower than the number you see, and the slow quarter is often mobile users on mid-tier phones and patchy networks.

So a page that feels instant on your MacBook can still fail. Your machine is not the 75th percentile. A three-year-old Android on a congested network is much closer to it.

This is also why LCP is one of the three Core Web Vitals that Google ships as a ranking signal. It's a proxy for whether the page felt loaded to a real person, not whether it passed a synthetic test.

Why Your Lighthouse Score and Field Data Disagree

Lighthouse runs a single simulated load on a throttled connection in a controlled lab. Field data, pulled from the Chrome User Experience Report, aggregates millions of real loads across every device and network your visitors actually use.

They measure different things, so they disagree constantly. Lab data is repeatable and great for debugging. Field data is messy and the only thing Google ranks on.

Here's the practical rule. Use lab tools to find and reproduce a problem, then confirm the fix landed by watching field data move over the following weeks. If you only ever look at the green Lighthouse gauge, you're optimizing a rehearsal, not the show.

You can pull field data from the Core Web Vitals report in Search Console, from the CrUX data shown at the top of PageSpeed Insights, or from a real-user monitoring script on your own site. Real-user monitoring is the most honest because it segments by device, template, and country, which is where the slow 25 percent usually hides.

What Are the Four Parts of LCP?

This is the concept that turns LCP from a mystery into a checklist. Every LCP is the sum of four consecutive phases, and one of them is almost always the villain.

The four sub-parts are time to first byte, resource load delay, resource load duration, and element render delay.

Chrome DevTools and web.dev's diagnostic breakdown will show you the split for a given load. Before you change anything, find which of the four is eating the most time. If your image downloads fast but the paint is still late, the problem is render delay and no amount of image compression will help.

How Do You Actually Fix a Slow LCP?

Start with the sub-part that's largest. Here are the fixes that move each one, ordered roughly by leverage.

Fix a slow time to first byte first, because every other phase stacks on top of it. Serve the page from a static build where you can, since a pre-rendered HTML file has almost nothing to compute. Put a CDN in front so bytes travel from an edge near the user. Add full-page caching for anything that doesn't need to be personalized. For deeper background, the TTFB primer covers the server-side side of this.

Cut the resource load delay next. The classic mistake is lazy-loading the hero image, which tells the browser to wait before fetching the one element LCP depends on. Never lazy-load the LCP element. Instead, preload it and mark it high priority.

<link rel="preload" as="image" href="/hero.avif" fetchpriority="high" />
<img src="/hero.avif" fetchpriority="high" alt="..." />

Shrink the resource load duration by serving the right image. Use AVIF or WebP instead of PNG or JPEG, ship a responsive srcset so phones don't download a desktop-sized file, and compress aggressively. A hero that drops from 800 kilobytes to 90 kilobytes changes the whole picture. The site speed tools roundup lists the analyzers that flag oversized images automatically.

Attack element render delay last, and it's often the sneakiest. Render-blocking CSS in the head holds up the first paint, so inline the small amount of critical CSS and defer the rest. Web fonts block text rendering, so self-host them and use font-display: swap so text paints immediately in a fallback. If your hero is rendered by client-side JavaScript, the browser can't paint it until the bundle downloads, parses, and runs, which is why server-rendered or static hero content wins almost every time.

Here's the short version of the whole process:

1. Pull field data and confirm the page really fails at the 75th percentile
2. Reproduce it in a lab tool and read the four-part breakdown
3. Identify the largest sub-part
4. Apply the matching fix from above
5. Ship, wait two to four weeks, and watch the field number move

What About Third-Party Scripts?

Here's the LCP tax nobody puts on the invoice. Analytics, chat widgets, A/B testing tools, ad scripts, and consent banners all compete for the main thread while your hero is trying to paint.

The damage is usually to render delay. A tag manager that loads a dozen scripts synchronously can block the browser from painting even when your image downloaded ages ago. The page is ready to show and the third-party code is holding the door shut.

The fixes are mostly about timing and restraint. Load non-critical scripts with async or defer so they don't block rendering, delay anything that isn't needed for the first paint until after the page is interactive, and audit the list ruthlessly, because most sites carry two or three tags nobody remembers adding. A consent banner that renders above the fold deserves special scrutiny, since it can become the LCP element itself or shove the real one down.

The uncomfortable truth is that a marketing team can undo an engineer's LCP work in one afternoon by pasting in a new script. Treat the third-party budget as part of the performance budget, not a separate concern.

The Static Site and Astro Angle

Static and islands-based frameworks have a structural advantage on LCP, and it's worth naming because it's easy to squander.

A pre-rendered page ships real HTML with the hero already in the markup. Time to first byte is tiny because there's no server computation, and render delay is small because there's no client-side framework standing between the download and the paint. That's most of LCP handled by architecture alone.

You can still ruin it. Import a heavy component that hydrates above the fold, lazy-load the hero out of habit, or pull in a render-blocking font stylesheet, and the static advantage evaporates. The discipline is to keep the above-the-fold content in static HTML and hydrate only what genuinely needs interactivity.

LCP also doesn't live alone. It sits alongside Cumulative Layout Shift and Interaction to Next Paint in the Core Web Vitals set, and a page that paints fast but jumps around or feels sluggish to tap still fails the wider bar.

FAQ

How long until an LCP fix shows up in Search Console? The Core Web Vitals report uses a rolling 28-day field window, so a fix rarely shows full effect for two to four weeks. If you need faster confirmation, use real-user monitoring, which reflects new visits immediately.

My LCP element is a block of text, not an image. Does that change anything? Yes. When text is the LCP element, the bottleneck is usually web fonts and render-blocking CSS, not image weight. Self-host the font, use font-display: swap, and inline critical CSS so the text paints without waiting.

Does preloading everything help? No. Preload is a priority hint, and if you preload ten things you've prioritized nothing. Preload only the single LCP resource. Over-preloading can actually slow the page by competing for bandwidth with the resource that matters.

Is a good LCP enough to rank? Core Web Vitals are a real but modest ranking factor and mostly act as a tiebreaker between comparable pages. Fix LCP for the user experience and the ranking nudge, but relevance and content quality still do the heavy lifting.

Should I chase a perfect Lighthouse 100? Not for its own sake. Lighthouse is a diagnostic. A page can score 100 in the lab and still fail field LCP for real mobile users. Optimize the field number and treat the lab score as a debugging aid.

Why did my LCP get worse after a redesign? Redesigns commonly add a larger hero, a new font, or a client-rendered component above the fold. Any of those can push the paint later. Re-run the four-part breakdown after any significant front-end change.

Does a carousel or hero slider hurt LCP? Often, yes. Sliders tend to load multiple large images and a JavaScript library up front, and the browser may pick a slide image as the LCP element while the script delays its render. If you keep the carousel, make sure the first slide is optimized and preloaded, and lazy-load the later slides.

My mobile LCP is fine but desktop is poor, or vice versa. Why? The LCP element and its size often differ between layouts, so a hero that's tiny on mobile can be huge on desktop, or a desktop sidebar script can drag one down. Always check field data split by device, since Google evaluates mobile and desktop separately.

Where to Go Next

Pull up your slowest template in Search Console, confirm it fails at the 75th percentile, and run the four-part breakdown before you touch a single line of code. Fixing the largest sub-part first is the difference between a week of guessing and an afternoon of real progress.

For the surrounding performance picture, Google's own Optimize LCP guide on web.dev is the canonical reference, and the page speed overview covers how LCP fits the broader speed story. Astro SEO Blog publishes Core Web Vitals worked examples throughout the technical SEO category.