Largest Contentful Paint (LCP): What It Is and How to Fix It
Short answer: LCP is the time until the biggest image or text block in the first screen is shown. Good is 2.5 seconds or less for at least 75% of visits; over 4 seconds is poor. To fix it, find the LCP element, then see which of four steps is slow: the server response, the delay before the browser starts fetching the LCP image, the download itself, or the delay before it’s drawn. The most common fixes are a faster server, putting the main image straight in the HTML with fetchpriority="high", and not lazy-loading it.
Which element is your LCP?
web.dev lists the elements that can count: <img>, an <image> inside SVG, a <video> (its poster or first frame), an element with a CSS url() background image, and block-level elements with text. Chrome ignores elements with opacity 0, elements that cover the full viewport (treated as background), and low-detail placeholder images. LCP stops updating once the user taps, scrolls or presses a key.
To see yours: run the URL in PageSpeed Insights and open the LCP diagnostic, or record a page load in Chrome DevTools’ Performance panel. On most content pages it’s the hero image or the first heading and paragraph.
The four parts of LCP time
web.dev’s LCP guide breaks the time into four parts that add up to the total, with rough targets:
| Part | What it covers | Rough share |
|---|---|---|
| Time to First Byte | Until the first byte of HTML arrives | ~40% |
| Resource load delay | From TTFB until the browser starts fetching the LCP image | under 10% |
| Resource load duration | Downloading the LCP image | ~40% |
| Element render delay | From download finished until it’s on screen | under 10% |
If your LCP is text, the two middle parts are zero. web.dev calls these shares guidelines, not rules. The point is to find which part is too big, not to hit exact numbers.
Fixes for each part
1. Slow server response (TTFB)
- Serve cached HTML from a CDN where you can.
- Cut redirects before the page (http to https to www to a slash variant can add several round trips).
- Avoid unique URL parameters that stop the CDN from caching.
More in our TTFB guide.
2. The browser finds the LCP image late
This is often the biggest easy win. The image should be in the HTML the server sends, not added later by JavaScript or set as a CSS background the browser finds late.
<!-- LCP hero image: in the HTML, high priority, NOT lazy -->
<img src="/hero.webp" width="1200" height="600"
fetchpriority="high" alt="...">
<!-- if it must be a CSS background, preload it -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">Use fetchpriority="high" on one or two images at most. And never put loading="lazy" on the LCP image: web.dev flags that as a mistake.
3. The image takes long to download
- Use modern formats (WebP, AVIF) and serve the right size for the screen with
srcset. - Serve images from a CDN or image CDN close to the visitor.
- Don’t let other high-priority downloads compete with it.
4. The image is ready but not drawn
- Reduce render-blocking CSS, and defer scripts in the
<head>. See render-blocking resources. - Render the main content on the server instead of waiting for JavaScript.
- Break up long JavaScript tasks that keep the main thread busy.
- For text LCP, avoid
font-display: blockso text isn’t hidden while a web font loads.
Check the result
Re-run PageSpeed Insights for a quick lab check. The real verdict comes from field data: Search Console’s Core Web Vitals report and the field section of PageSpeed Insights, which cover the past 28 days, so give it a few weeks. Our free sitemap checker flags sitemap URLs that take over 3 seconds to respond, which points at a TTFB problem; it doesn’t measure LCP itself.
Frequently asked questions
What is a good LCP score?
2.5 seconds or less for at least 75% of page visits, measured separately on mobile and desktop. Over 4 seconds is poor.
How do I find my LCP element?
In PageSpeed Insights, open the LCP diagnostic; it names the element. In Chrome DevTools, record a load in the Performance panel and select the LCP marker.
Should I lazy-load images to improve LCP?
Lazy-load images further down the page, but never the LCP image. web.dev lists lazy-loading the LCP image as a mistake, because it delays the very element being measured.
Does a CDN fix LCP?
It helps with two of the four parts: a faster server response (TTFB) and shorter image download time. It doesn’t fix an LCP image that the browser discovers late, or rendering blocked by scripts and CSS.
Why is my LCP fine in Lighthouse but poor in Search Console?
Lighthouse runs one simulated load on a fast machine. Search Console uses real visits, including slow phones and networks, over the past 28 days. Trust the field data.