What is LCP (Largest Contentful Paint)?
LCP measures how quickly the main content of a page loads. Learn what it means, what counts as the LCP element, what causes a slow LCP, and exactly how to fix it.
Largest Contentful Paint (LCP) measures the time from when a page starts loading to when the largest visible content element has finished rendering. In simpler terms: how long until the user can actually see the main thing on the page.
LCP is one of Google’s three Core Web Vitals and a direct ranking factor. More importantly, a slow LCP means users are staring at a blank or partially loaded page — which directly hurts engagement and conversions.
What Counts as the LCP Element?
The browser identifies the largest element that is visible in the viewport at any given point during loading. Eligible elements include:
<img>elements<image>inside an SVG<video>elements (using the poster image)- Elements with a CSS
background-image - Block-level elements containing text (
<p>,<h1>, etc.)
The LCP element often changes as the page loads. The final LCP is the largest element rendered before the user first interacts with the page.
In most cases, it’s your hero image or H1 heading.
LCP Thresholds
| Score | Time |
|---|---|
| Good | Under 2.5s |
| Needs improvement | 2.5s – 4.0s |
| Poor | Over 4.0s |
These are measured at the 75th percentile of page loads in field data — meaning 75% of your real users need to hit these thresholds.
What Causes a Slow LCP?
Slow server response (high TTFB) If the server takes too long to respond with the initial HTML, everything downstream is delayed. A TTFB over 800ms is a red flag.
Render-blocking resources
CSS and JavaScript in the <head> that block the browser from rendering the page. The browser can’t paint the LCP element until these finish downloading and executing.
Slow resource load times The LCP element itself (usually an image) is large, unoptimized, or loading from a slow origin. A 500KB hero image loaded from a shared hosting server will always be slow.
No fetch priority hint
By default, the browser treats images as lower priority than scripts and stylesheets. Without fetchpriority="high" on your LCP image, the browser might not start loading it until halfway through page load.
Client-side rendering If your LCP element is injected by JavaScript rather than present in the initial HTML, the browser has to download, parse, and execute the JS before it can even start loading the image.
How to Fix a Slow LCP
1. Optimize your LCP image Convert to WebP or AVIF (typically 30–50% smaller than JPEG/PNG). Serve at the actual display size — don’t load a 2400px image for a 600px container.
2. Add fetchpriority="high"
<img src="hero.webp" fetchpriority="high" alt="..." />This tells the browser to start loading the image immediately, before it finishes parsing the rest of the document.
3. Preload the LCP image
<link rel="preload" as="image" href="hero.webp" fetchpriority="high" />Add this in the <head> so the browser discovers and fetches the image as early as possible.
4. Use a CDN Serving static assets from a CDN reduces the physical distance between your server and the user, cutting download time significantly.
5. Reduce TTFB If your server is slow, nothing else matters. Enable caching, use edge computing, or switch to faster infrastructure.
6. Eliminate render-blocking resources
Defer non-critical JavaScript. Inline critical CSS or use <link rel="preload"> for stylesheets.
How to Identify Your LCP Element
Run a free test on debugutils.dev. The LCP section of your report shows exactly which element is your LCP, its render time, and a breakdown of where that time was spent (TTFB, resource load delay, resource load time).
This is the fastest way to know which optimization to tackle first.