LCP (Largest Contentful Paint) measures the time it takes for the largest visible element in the viewport to fully render. It is one of the three core metrics in Google's Core Web Vitals and an official search ranking factor since 2021.
In practical terms, LCP answers the question: "When does the user actually see the most important thing on this page?"
Which Elements Can Become the LCP
The browser continuously evaluates which element takes up the most visible space as the page loads. Elements that can qualify as the LCP include:
- Images (
<img>elements) - Images inside
<svg>elements - Video poster frames (
<video>thumbnail) - Elements with a CSS background image (
background-image) - Large text blocks:
<p>,<h1>–<h6>,<li>, etc.
On most websites, the LCP element is the hero image or the largest headline in the header section.
LCP Thresholds: Good, Needs Improvement, and Poor
Google defines three ranges for LCP, measured at the 75th percentile of real users:
| Range | LCP Time | Assessment |
|---|---|---|
| Good | ≤ 2.5 seconds | Passes Core Web Vitals |
| Needs Improvement | 2.5 s – 4.0 s | Significant room to optimize |
| Poor | > 4.0 seconds | Potential ranking penalty |
The threshold is applied at the 75th percentile: 75% of your real visitors must experience an LCP under 2.5 s for your page to be rated "good."
Why LCP Matters for SEO
Google launched the Page Experience update in 2021 and made Core Web Vitals — including LCP — an explicit ranking factor. It isn't the heaviest signal, but it acts as a tiebreaker: between two pages with comparable content quality, the faster one earns higher positions.
Beyond SEO, a high LCP directly damages user experience: visitors stare at a partially blank page, lose patience, and leave. Bounce rates rise; conversions fall.
Explore all page experience metrics in the web performance section of this blog.
The 4 Main Causes of a Slow LCP
1. High Server Response Time (TTFB)
LCP can't start until the server delivers the HTML. A high TTFB — caused by slow hosting, unoptimized database queries, or absent caching — delays everything downstream. Bringing TTFB below 200 ms is the first step toward a good LCP.
2. Unprioritized LCP Image
If the LCP element is an image, the browser downloads it only after parsing the full HTML and processing any blocking CSS and JS. Adding fetchpriority="high" and removing loading="lazy" from the LCP image tells the browser to fetch it at top priority from the very first moment.
3. Render-Blocking JavaScript and CSS
Blocking resources delay the first render. Every millisecond spent processing JS or CSS before the screen paints adds to the LCP. Deferring non-critical JS with defer or async and removing unused CSS can cut LCP by one to two seconds.
4. Uncompressed or Outdated-Format Images
A 2 MB JPEG hero image will take far longer to download than the same image in WebP or AVIF at optimized size. Compressing and converting the LCP element has a direct, measurable impact on the metric.
How to Improve LCP Step by Step
- Reduce TTFB: upgrade your hosting, enable OPcache, implement full-page caching (Redis, Varnish, or your CMS's built-in cache).
- Prioritize the LCP image: add
fetchpriority="high"to the<img>tag, or preload the resource with a<link rel="preload">in the<head>. - Optimize the LCP element: convert to WebP/AVIF, resize to the actual display dimensions, and compress without visible quality loss.
- Eliminate render-blocking resources: audit with Chrome DevTools → Coverage to find unused CSS and JS; add
deferto any JS that isn't critical for the initial render. - Set up a CDN: bringing static assets closer to the user reduces download time, especially for the LCP image.
- Verify with field data: use Google PageSpeed Insights (CrUX data) to confirm improvements reach real users, not just the lab environment.
If LCP remains above the threshold after these optimizations, there may be deeper root causes — legacy code, conflicting plugins, or server architecture — that require a specialized audit. In that case, working with performance specialists like elenlace.com can save weeks of trial and error.
Key Takeaways
- LCP measures how long it takes for the largest visible element in the viewport to render; the "good" threshold is ≤ 2.5 s at the 75th percentile.
- It is a Core Web Vital and an official Google ranking factor since 2021.
- The most common causes of poor LCP are: high TTFB, an unprioritized LCP image, render-blocking resources, and unoptimized images.
- The most effective levers: faster hosting,
fetchpriority="high", WebP/AVIF images, eliminating blocking CSS/JS, and a CDN. - Always verify results with field data (CrUX in PageSpeed Insights), not just lab scores.
Is your LCP missing the 2.5 s threshold? Contact us for a Core Web Vitals audit and an improvement plan with measurable results.
FAQ
What exactly is LCP in Google Search Console?
In Search Console, the Core Web Vitals report shows LCP based on real field data (CrUX) from the past 28 days, grouped by page type. A "poor" status means more than 25% of your users are experiencing LCP above 4 seconds on those pages.
Is LCP the same as total page load time?
No. Total load time (Fully Loaded) accounts for every resource on the page. LCP is specific: it measures only when the largest visible element appears on screen, which typically happens before everything else has finished loading.
How do I find out which element is my page's LCP?
Open Chrome DevTools, go to the Performance tab, and record a page load. The Timings row will mark the LCP moment. Alternatively, the Web Vitals Chrome extension highlights the LCP element directly on the page with a visual border.
Can LCP vary by device or connection speed?
Yes. LCP can differ between desktop and mobile, and between fiber and 3G. Google evaluates the 75th percentile across all real users, so slow connections for a subset of visitors can push the aggregated LCP above the threshold even if the site feels fast under ideal conditions.
Compare providers
Other providers and guides worth comparing:
