How to Fix Slow Largest Contentful Paint (LCP): A Practical Guide

Your Lighthouse report shows a red LCP. Your PageSpeed score is sitting below 50. You have pushed optimizations before and still cannot get below that 2.5-second threshold. This guide walks through a systematic approach to diagnosing and fixing slow Largest Contentful Paint — the one Core Web Vital that most directly maps to how fast your page feels to a real visitor.

What Largest Contentful Paint Actually Measures

LCP marks the moment the largest visible element in the viewport finishes rendering. That element is almost always a hero image, a banner, or a large above-the-fold heading. The browser timer starts the instant the user navigates and stops the instant that element is painted.

The four phases that contribute to LCP time are:

1. Time to First Byte (TTFB) — how long the server takes to start responding
2. Resource load delay — how long before the browser discovers and begins fetching the LCP resource
3. Resource load duration — how long the actual download takes
4. Element render delay — how long after the download before the element appears on screen

Your goal is to find which phase dominates and attack that first. Tools like Chrome DevTools Performance panel and WebPageTest waterfall views break LCP into these phases explicitly.

How to Fix Slow LCP: The Highest-Impact Fixes

1. Never Lazy-Load the LCP Image

This is the single most common mistake. Adding loading="lazy" to a hero image tells the browser to defer the fetch until the image scrolls into view — but the hero is already in the viewport. The browser then waits for layout to stabilise before starting the download, adding hundreds of milliseconds for no reason.

Remove loading="lazy" from any image that is likely to be the LCP element. In its place, add fetchpriority="high":

fetchpriority="high"

Set this attribute on the img tag. It signals to the browser's preload scanner that this resource is critical and should be fetched at the highest network priority.

2. Preload the LCP Image

Even with fetchpriority="high", the browser still needs to parse the HTML before it discovers the image. Add a preload link in the document head so the browser starts fetching before it encounters the img tag:

rel="preload" as="image" fetchpriority="high"

For responsive images using srcset, include the imagesrcset and imagesizes attributes on the preload link to ensure the correct variant is fetched.

3. Reduce Time to First Byte

If TTFB is above 600ms, no amount of image optimisation will rescue your LCP. Fix TTFB first:

• Move compute-heavy work to edge functions or CDN workers so the response originates closer to the user
• Enable HTTP caching with proper Cache-Control headers for static HTML shells
• Use a CDN with anycast routing
• Eliminate server-side blocking queries on the critical path — defer analytics, recommendations, and personalisation to client-side after the initial render

A good TTFB target is under 200ms at the 75th percentile.

4. Serve Images in the Right Format and Size

Serving a 3,000-pixel-wide JPEG at 2 MB to a mobile device that displays it at 400px wide wastes bandwidth and LCP time. Steps to fix this:

• Convert hero images to WebP or AVIF. WebP is roughly 25–35% smaller than JPEG at equivalent quality. AVIF compresses even further but has slightly less universal support.
• Resize images server-side to the actual display dimensions. Use srcset to serve different sizes for different viewport widths.
• Enable compression at the CDN or origin. For raster images, quality settings around 80–85 in WebP produce negligible visual difference.

5. Eliminate Render-Blocking Resources

CSS in the head blocks rendering until it is downloaded and parsed. JavaScript with no defer or async attribute does the same. Both delay the moment the browser can paint anything, including the LCP element.

• Inline critical CSS — the styles needed to render above-the-fold content — directly in the style tag in the head.
• Load non-critical CSS asynchronously or defer it.
• Add defer to all non-essential scripts.
• Move third-party tag manager scripts to load after the page becomes interactive.

6. Use a CDN for Static Assets

LCP images served from your origin server in a single region add significant latency for users far away. A CDN caches assets at edge nodes globally. Serving a 150 KB hero image from a CDN node 20ms away versus an origin server 200ms away is a direct 180ms reduction in the resource load duration phase of LCP.

Diagnosing LCP in the Field vs. the Lab

Lab tools like Lighthouse and PageSpeed Insights run a simulated load under controlled conditions. Field data from the Chrome User Experience Report (CrUX) reflects real users on real devices and connections. The two often diverge.

Always validate LCP fixes against field data. The Search Console Core Web Vitals report and services like DebugBear, SpeedCurve, or RUM (Real User Monitoring) tools give you field-level LCP distribution. A fix that improves your Lighthouse lab score from 2.8s to 1.9s may only move field p75 from 4.1s to 3.6s — better, but still failing.

A Diagnostic Checklist

• Is the LCP element an image or a text block?
• If an image: is loading="lazy" present? (Remove it.)
• Is a preload link present in the head for the LCP image?
• Is TTFB under 200ms? (Check in WebPageTest.)
• Is the image served from a CDN?
• Is the image in WebP or AVIF format?
• Is the image sized to the actual display dimensions?
• Are there render-blocking scripts or stylesheets above the LCP image?

Work through this list top to bottom on both desktop and mobile. Google ranks based on mobile field data, so mobile LCP deserves priority attention.

When to Bring in Engineering Help

Some LCP problems are configuration issues that a developer can fix in an afternoon. Others are architectural — a monolithic server with no CDN, a CMS that serves uncompressed originals, a JavaScript-heavy framework that delays rendering. If your LCP field score is above 4 seconds and the quick wins above have not moved it, the underlying architecture likely needs a review.

Talk to the Clixo team if you want a focused web performance audit and a concrete fix plan — not a report, a working result.