Largest Contentful Paint, or LCP, is the Core Web Vital for loading. It does not ask when the page started to appear or when it finished; it asks when the main content became visible. Google’s web.dev article on LCP defines it this way: “LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” This post covers the thresholds, which elements qualify, how to find yours, and the fixes that actually move the number.
The largest contentful paint thresholds
LCP is scored in three bands. As with every Core Web Vital, the figure that counts is the 75th percentile of page loads, segmented across mobile and desktop devices. A page passes only when three in four loads hit the threshold, so a quick result on your own connection says little about the visitors who matter.
| Rating | LCP at the 75th percentile | What it usually means |
|---|---|---|
| Good | 2.5 s or less | The main content appears promptly |
| Needs improvement | Between 2.5 s and 4.0 s | A visible wait on slower phones or connections |
| Poor | Over 4.0 s | Visitors stare at a half-built page |
The mobile and desktop split matters. A page can pass comfortably on desktop and fail on mobile, where the processor is slower and the network less reliable. Check both before deciding a page is fine, and treat the mobile figure as the one to beat.
Which elements count towards LCP
LCP does not consider every element on the page. The candidates are a defined list, and knowing it explains why the measured element is sometimes not the one you expected.
| Element type | Typical example |
|---|---|
<img> elements | A hero image or product photo |
<image> inside an <svg> | An illustration drawn in SVG with an embedded image |
<video> elements | The poster image or first frame of a video |
Elements with a background image loaded via url() | A banner styled with a CSS background |
| Block-level elements containing text | A headline or opening paragraph |
On most content and commercial pages the winner is either a large image above the fold or, on text-led pages, the first heading or paragraph. That second case surprises people: a blog post with no hero image can still have a slow LCP if the web font holds back the text or the server is slow to send the HTML.
How to find your largest contentful paint element
Start with field data, because the threshold applies to real visits. The Core Web Vitals report in Search Console groups URLs by status and shows whether LCP is the metric failing. If you are already looking at red, our guide to a failed Core Web Vitals assessment explains how to read the report and which URLs to start with.
Then find the element itself. Lighthouse and the performance panel in Chrome DevTools both name the LCP element for a test load. Run the test with mobile emulation and network throttling switched on, otherwise you are measuring your own fast machine rather than your visitors’ phones.
Once you know the element, the question becomes what stands in front of it. Every LCP is the sum of the server sending the HTML, the browser discovering the resource, the resource downloading and the browser painting it. A slow score is almost always one of those stages taking far longer than the others, and the fix depends on which.
Check whether the element is the same across templates. Product pages, category pages and articles often have different LCP elements, so one fix rarely covers the whole site. Group the failing URLs by template, find the element on one example of each, and work through them in order of traffic rather than trying to tune every page individually.
How to improve LCP
The usual advice is to compress your images and call it done. Compression helps, but on many slow pages the image is not the bottleneck. It is waiting behind a slow server, a stylesheet that blocks rendering, or a lazy-loading attribute that tells the browser not to hurry. Fix the order of events before you fix the file size.
Speed up the server response. Nothing renders until the HTML arrives. Caching full pages, using a CDN and trimming slow database work on the first request all shorten the time before the browser can even look for the LCP element.
Do not lazy-load the LCP image. Lazy loading is the right default for images below the fold and the wrong one for the hero. It deliberately delays the request. Our post on lazy loading and SEO covers where the attribute helps and where it hurts.
Make the image smaller. Serve it at the size it is displayed, compress it and use a modern format. Our guide to WebP for SEO covers the format choice. A hero image exported straight from a design tool is often several times heavier than it needs to be.
Clear the path to the first paint. Stylesheets and synchronous scripts in the head can hold the whole page back even when the image has arrived. Our post on how to eliminate render-blocking resources walks through which files Lighthouse flags and how to deal with each.
Watch for background images too. An element styled with a CSS background is a valid LCP candidate, but the browser only finds that image after it has downloaded and parsed the stylesheet. Moving the hero into an ordinary image element in the HTML lets the browser discover it much earlier.
How much LCP matters for rankings
LCP sits inside Core Web Vitals, alongside Interaction to Next Paint and Cumulative Layout Shift, and feeds Google’s page experience signals. That does not make it a big ranking lever. As our post on page speed and SEO sets out, Google treats Core Web Vitals as a small factor that relevance outweighs. A fast page that misses the query will not outrank a slower one that answers it.
The better argument is the visitor. A page whose main content arrives late gets abandoned before anyone reads it, and that cost lands on every page view whether or not it ever shows up in rankings. Loading speed is also the Core Web Vital most directly tied to infrastructure choices, so fixing it often improves the whole site, not a single template.
One limitation to bear in mind: field data needs volume. Pages with little traffic may have no LCP figure of their own, and Search Console may report a grouped or origin-level value instead. In that case your lab tests approximate what visitors see rather than measure it. Fix what you can reproduce, then watch the field figure over the following weeks instead of expecting it to change the day you deploy.
Frequently asked questions
What is a good LCP score?
2.5 seconds or less at the 75th percentile of page loads. Over 4.0 seconds is rated poor.
Can text be the LCP element?
Yes. Block-level elements containing text are candidates, so a headline or opening paragraph can be the LCP element on pages without a large image.
Should I lazy-load my hero image?
No. Lazy loading delays the request, which pushes LCP back. Keep it for images below the fold.
Is LCP measured separately on mobile and desktop?
Yes. The 75th percentile is segmented across mobile and desktop devices, so a page can pass on one and fail on the other.
The takeaway Find the LCP element, work out which stage is holding it back, and fix that stage first. Do it for visitors; rankings are a smaller reward.
