Largest Contentful Paint, or LCP, measures how long it takes for the biggest visible element on a page to load: Google's main proxy for how fast a page feels to a real visitor.
Largest Contentful Paint, or LCP, measures how long it takes for the biggest visible element on a page to load: Google's main proxy for how fast a page feels to a real visitor. That element is usually the hero image, a large heading block, or a background image, whatever occupies the most space in the viewport when the page first settles.
It is timed from the moment navigation starts to the moment that element finishes rendering. It is one of the three Core Web Vitals, and Google's thresholds are clear: 2.5 seconds or less is 'good', up to 4 seconds 'needs improvement', and anything slower counts as 'poor'. As with the other vitals, you are judged at the 75th percentile of real visits, not on a single test run.
When LCP is slow, the cause is usually one of a short list: a slow server response before anything can even start, render-blocking CSS or JavaScript that holds up the paint, or a large hero image that is unoptimised or, ironically, lazy-loaded when it should load first. The fixes follow the same list, compress and correctly size that main image, serve it in a modern format, preload it, strip render-blocking resources, and host on something quick. This is bread-and-butter web design work, and it is where most of the real speed gains hide.
One honest caveat: LCP is a proxy, not the whole experience. A page can paint its hero in under two seconds and still feel awful if it then jumps around or freezes when you tap it. Treat LCP as one dial among three, and where you have field data, read it over the lab number, because that is the score Google counts, on lower-traffic pages you may only have the lab result to go on.
Key points
- LCP times how long the largest visible element takes to render, usually the hero image or main heading.
- It is one of the three Core Web Vitals, standing in for loading speed.
- The 'good' threshold is 2.5 seconds or less at the 75th percentile of real visits.
- The usual culprits are slow server response, render-blocking code, and heavy hero images.
- Preloading and correctly sizing that main image is often the single biggest win.
- It is a proxy for perceived speed, not a complete measure of how the page behaves.
Frequently asked questions
Common questions about largest contentful paint.
2.5 seconds or less is Google's 'good' band, 2.5 to 4 seconds is 'needs improvement', and over 4 seconds is 'poor'. The catch is that this is measured at the 75th percentile of real visitors, so you are aiming for most of your traffic to come in under 2.5 seconds, not just your own quick test. A fast desktop number means little if your mobile visitors on slower connections are sitting well above the line.
In my experience it is nearly always the hero. Either the main image is too large and unoptimised, or the code has helpfully lazy-loaded the one element that should load first. The other big one is a slow server response, if the page takes a second to even start arriving, LCP is already behind before a pixel is drawn. Compressing and preloading the hero image, serving a modern format, and cutting render-blocking scripts fixes the majority of cases. I go through the full method in my piece on scoring 100 on Lighthouse without a framework.
Total load time is when everything finishes, every last script, tracking pixel and below-the-fold image. LCP is narrower and more useful: it is the moment the main content a visitor came to see has appeared. A page can keep quietly loading things for several more seconds after LCP without the visitor caring, because the part they wanted is already on screen. That is why Google leans on LCP rather than raw load time, it is a closer match to how fast the page actually feels.
Want a site that is genuinely fast?
Tell me what you are building or fixing and I will show you what is possible.
Start a conversation