The short answer
Largest Contentful Paint is the time it takes for the largest image or text block in the viewport to appear. A good LCP is 2.5 seconds or less, measured at the 75th percentile of real visits. To improve it, find the one LCP element, then work through four things: a faster server response (TTFB), getting the LCP resource discovered and fetched early, a smaller resource, and less render-blocking CSS and JavaScript.
The highest-leverage single fix on most pages: preload the hero image, give it fetchpriority high, and make sure it is never lazy loaded.
- Good LCP is 2.5s or less, measured on real users.
- Identify the one LCP element before optimising anything.
- Never lazy-load the LCP image. Preload it and set fetchpriority high.
The LCP Thresholds
Google rates LCP in three bands, scored at the 75th percentile of real page loads across mobile and desktop.
Good
2.5 seconds or less
Needs improvement
2.5 to 4.0 seconds
Poor
Over 4.0 seconds
LCP is one of the three Core Web Vitals, alongside INP and CLS. See measuring PageSpeed and Core Web Vitals for how the field and lab numbers differ.
First, Find the LCP Element
Every page has exactly one LCP element: the largest image or text block visible when the page first renders. You cannot improve LCP until you know which element it is, because that element is the one you optimise. Everything else is a distraction.
The element is usually one of these:
- An image tag, the most common case (a hero or banner)
- An image inside an SVG
- The poster frame of a video
- An element with a CSS background image loaded through url()
- A block-level text element, such as a large heading or paragraph
To find yours, run PageSpeed Insights and read the diagnostics, which name the element outright, or record a trace in the Chrome DevTools Performance panel and read the LCP marker. Once you know the element, the rest of this guide tells you how to make it appear sooner.
The Four Parts of Every LCP
Google breaks LCP into four consecutive stages. A slow LCP is always one or more of these taking too long. Diagnose which, then fix that one.
Time to First Byte
How long the server takes to start responding. Nothing renders until this finishes, so it sets the floor for LCP.
Resource load delay
The gap between the server responding and the browser starting to fetch the LCP resource. Late discovery and low priority cause this.
Resource load time
How long the LCP image or font actually takes to download. Oversized files and slow networks dominate here.
Element render delay
The gap between the resource arriving and it painting on screen, usually caused by render-blocking CSS and JavaScript.
The Fixes, in Priority Order
- 1
Cut TTFB first
Serve from a cache or a CDN, speed up the backend, and avoid slow redirects. Because TTFB is the first slice of LCP, every millisecond you save here flows straight through. Our guide to browser caching and compression covers the server side.
- 2
Make the LCP resource discoverable early
The browser cannot fetch what it has not found. Reference the LCP image directly in the HTML rather than injecting it with JavaScript or CSS, and add a preload so it starts downloading as soon as possible.
- 3
Raise the LCP image's priority, and never lazy-load it
Add fetchpriority="high" to the hero image and remove any loading="lazy" from it. Lazy loading the LCP image is one of the most common causes of a slow score. Keep lazy loading for images below the fold only.
- 4
Shrink the LCP resource
Serve the image in AVIF or WebP, size it correctly for the device with responsive images, and compress it. A smaller file downloads and paints sooner. For a text LCP element, make sure the web font is not blocking the paint.
- 5
Remove render-blocking CSS and JavaScript
Inline the critical CSS, defer non-critical styles and scripts, and split large bundles so the browser can paint the main content without waiting for everything else. This attacks the render-delay slice of LCP.
Related performance guides: browser caching and compression for TTFB, image SEO and modern formats for the resource itself, and removing unused JavaScript for render delay.
A Deep Dive from the Chrome Team
This talk from Chrome for Developers walks through the same four subparts in detail and shows how to attribute a slow LCP to the right stage with real traces. It is the most thorough free explanation of the metric.
A Worked Example
Illustrative scenario, not client data
A blog's article pages report an LCP of 4.1 seconds on mobile, in the poor band. Here is how the four-part model turns that into a short fix list.
- Identify the element: PageSpeed Insights names the LCP element as the article's hero image.
- Attribute the time: TTFB is a healthy 0.4s, but there is a long resource load delay. The image is set to loading="lazy" and is discovered late because a script injects it.
- Fix discovery and priority: reference the image directly in the HTML, remove the lazy attribute, add a preload, and set fetchpriority="high".
- Shrink the file: convert the hero from a 450KB JPEG to a right-sized WebP under 90KB.
The load delay collapses and the smaller file paints sooner. LCP moves from 4.1s into the good band. Note what did not need doing: the server was already fast, so touching the backend would have been wasted effort. The data pointed at discovery and file size, so that is where the work went.
Did the speed fix move the numbers?
Lighthouse tells you the page got faster. Your search data tells you whether it mattered. Murkuz connects Google Search Console, Analytics 4 and Bing to Claude or ChatGPT, read-only, so you can ask whether clicks, impressions and position for the fixed pages moved afterwards, and confirm Google recrawled the URL. It reads your data; it does not change your site or measure your speed.
See the Search Console connectorCommon LCP Mistakes
Optimising the wrong element
Teams compress every image on the page and wonder why LCP barely moves. Identify the one LCP element first, then spend your effort there. The rest is secondary.
Lazy-loading the hero image
A blanket loading="lazy" rule applied to all images will catch the LCP image and delay it. Exclude the above-the-fold hero from lazy loading.
Chasing the lab score only
Lighthouse gives a clean lab number, but ranking uses field data from real users on real devices and networks. Always confirm the fix in field data, not just the lab panel.
Ignoring TTFB
You can preload and prioritise perfectly and still be slow if the server takes a second to respond. A slow TTFB caps LCP before the page even starts to paint.
Further reading
The primary sources on Largest Contentful Paint, Google's own documentation first. Each one was read in full before it was listed here.
Official docsweb.dev, Philip Walton & Barry Pollard
Optimize Largest Contentful PaintThe definitive how-to: breaks LCP into four subparts, shows how to measure each, and lists the fixes in priority order. The backbone of this page.
Official docsweb.dev, Philip Walton & Barry Pollard
Largest Contentful Paint (LCP)The metric's formal definition: the exact Good, Needs improvement and Poor thresholds, the 75th-percentile rule, and which elements qualify as the LCP element.
Official docsweb.dev, Leena Sohoni & Addy Osmani
Optimize resource loading with the Fetch Priority APIExplains fetchpriority="high" and when to use it so the browser fetches your LCP image sooner instead of treating it as a low-priority resource.
ReferenceMDN Web Docs
LargestContentfulPaint APIThe browser-API reference behind the metric, useful if you want to read the LCP entry in your own code or understand exactly what the browser reports.
GuideDebugBear
Largest Contentful Paint (LCP) explainedA clear practitioner reference on how LCP is measured in lab and field, common causes of a slow LCP, and how to read it in real monitoring tools.
Frequently Asked Questions
What is a good LCP score?
A good Largest Contentful Paint is 2.5 seconds or less. Between 2.5 and 4.0 seconds needs improvement, and over 4.0 seconds is poor. The score Google uses is the 75th percentile of real page loads across mobile and desktop, so a quarter of your visitors can be slower than your reported number. Lab tools such as Lighthouse give you a single simulated figure to debug against, but the number that counts for ranking is the field data from real users.
What can be the LCP element on a page?
The LCP element is the largest image or text block visible in the viewport when the page first renders. Qualifying elements include image tags, an image inside an SVG, the poster frame of a video, an element with a CSS background image loaded through a url() function, and block-level text such as a heading or paragraph. On most content pages it is the hero image or the main headline. Whichever it is, that element is what you optimise.
How do I find my LCP element?
Run PageSpeed Insights on the URL and open the diagnostics: it names the LCP element directly. In Chrome DevTools, record a trace in the Performance panel and look at the LCP marker, or use the Lighthouse panel, which highlights the element. Once you know what it is, you know what to make load faster, whether that means prioritising an image or removing what blocks a text block from painting.
Why should I never lazy-load the LCP image?
Lazy loading tells the browser to wait before fetching an image, which is the opposite of what you want for the element that defines LCP. Applying loading="lazy" to your hero image delays its download and pushes LCP later, often by a large margin. Lazy loading is excellent for images below the fold, but the LCP image should load eagerly, and ideally with a high fetch priority.
What is fetchpriority and when should I use it?
fetchpriority is an HTML attribute that hints how urgently the browser should fetch a resource. Setting fetchpriority="high" on your LCP image tells the browser to request it sooner rather than treating it as a normal-priority image discovered late in the page. Use it on the single most important above-the-fold image, often alongside a preload, so the browser does not waste time on less important downloads first. Do not apply it to many images at once, which just spreads priority thin.
How much does TTFB affect LCP?
A lot, because Time to First Byte is the first part of LCP. Nothing can render until the server responds, so a slow TTFB sets a floor under your LCP no matter how well the rest of the page is optimised. A good TTFB is around 800 milliseconds or less. Caching, a content delivery network, and a faster backend all reduce TTFB, and the improvement flows straight through to LCP.
Do AVIF and WebP improve LCP?
Usually, yes, when the LCP element is an image. Modern formats such as AVIF and WebP produce much smaller files than JPEG or PNG at the same quality, so the image downloads faster and paints sooner. Pair the modern format with a correctly sized, responsive image so you are not shipping a desktop-sized file to a phone. Format alone will not fix an image that is also loaded late or at the wrong size.