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

To improve Largest Contentful Paint, identify the element being measured and the part of its load sequence causing the delay. Use a waterfall or performance trace to separate server response time, resource discovery, downloading, and rendering.

What Largest Contentful Paint Measures

LCP reports the render time of the largest eligible image or text content visible in the viewport. The candidate can change as the page loads, so identify it in the trace instead of assuming it is the hero image.

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

Find the phase contributing the largest delay and address it first. Tools like Chrome DevTools Performance panel and WebPageTest waterfall views break LCP into these phases explicitly.

Fix the Delay Identified in the Trace

1. Never Lazy-Load the LCP Image

Lazy loading can delay discovery or fetching of an image needed for the initial viewport. Check the waterfall to see when its request starts.

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 server response time accounts for a large share of LCP, investigate it alongside image loading and rendering:

• 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

Set a TTFB budget appropriate to the page and measure it at the 75th percentile; investigate how much of the LCP delay comes before the first response byte.

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

A CDN can reduce the distance and response time for image requests. Measure cache hits, connection setup, transfer time, and rendering; a reduction in network latency does not translate directly into the same reduction in 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?
• Does TTFB meet the page’s budget, and how much does it contribute to LCP?
• 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. Check field performance by device type and prioritize the problems affecting your users.