How to Improve LCP (Largest Contentful Paint)

What is LCP?

Largest Contentful Paint records the moment the largest content element in the viewport becomes visible — the point at which the page looks "loaded" to a human. It is one of the three Core Web Vitals, and the one most tied to the first impression of speed.

Because it tracks the largest element, LCP is usually decided by one thing: a hero or cover image, or the main heading and opening text. Find that element and you have found your optimization target — everything else is secondary.

What is a good LCP score?

The thresholds from web.dev are 2.5 seconds or less for good, 2.5 to 4 seconds for needs improvement, and over 4 seconds for poor. As with all Core Web Vitals, the score is taken at the 75th percentile of visits and assessed separately on mobile and desktop.

LCP at 75th percentile	Rating
≤ 2.5 s	Good
2.5 – 4.0 s	Needs improvement
> 4.0 s	Poor

Mobile is where LCP usually slips, because slower networks and CPUs stretch every step. Test on a mid-range phone over a throttled connection, not just on office Wi-Fi.

Why is my LCP slow?

Google breaks a slow LCP into four sub-parts, and knowing which one dominates tells you exactly where to spend effort:

1. Time to First Byte (TTFB) — how long the server takes to start responding.
2. Resource load delay — the gap between the first byte and when the browser starts fetching the LCP image.
3. Resource load time — how long the LCP image itself takes to download.
4. Element render delay — the time between the resource arriving and the element actually painting.

For a text LCP there is no image to fetch, so TTFB and render delay dominate. For an image LCP, load delay and load time usually do. Profile the page in Chrome DevTools to see which slice is biggest before you change anything.

How do you improve LCP?

Work the four sub-parts in order of impact:

• Cut server time. Serve from a CDN, cache aggressively, and prefer static or server-rendered HTML so the first byte arrives fast. A slow TTFB caps everything downstream.
• Prioritize the LCP image. Add fetchpriority="high" to it, and preload it so the browser fetches it immediately instead of discovering it late. Do not lazy-load it.
• Right-size the image. Serve modern formats (WebP or AVIF), responsive srcset sizes, and explicit width/height. A hero that ships at 3000 px for a 800 px slot wastes seconds.
• Remove render-blocking resources. Inline critical CSS, defer non-critical JavaScript, and trim unused CSS so the browser can paint without waiting on a stylesheet or script.
• Tame web fonts. Preload the font used by a text LCP and use font-display: swap so text is not held back by a font download.

Start with whichever sub-part your profile says is largest. Preloading an image will not help a page whose TTFB is two seconds — fix the server first.

Does lazy-loading hurt LCP?

Yes, when it is applied to the LCP element itself. Lazy-loading tells the browser an image is not urgent, so it waits — which is perfect for images far down the page and actively harmful for the hero. The rule is simple: eager, prioritized loading for the above-the-fold LCP image; lazy-loading everywhere below.

While you are setting dimensions on images to speed loading, set them for stability too — explicit width and height also prevent the layout jumps that hurt Cumulative Layout Shift. Good alt text belongs on that hero as well; see writing alt text that helps.

How does LCP relate to INP and CLS?

LCP is one leg of the Core Web Vitals tripod: it covers loading, while INP covers responsiveness and CLS covers visual stability. They are measured independently, so a page can ace one and fail another — a fast-loading page can still feel laggy on tap.

That is why it pays to diagnose before you optimize. Pull your field data, confirm LCP is the metric you are failing, and then work the sub-part that dominates. For more, see the Web Development tag and the Technology section.