Largest Contentful Paint: what it measures and how to improve it
Largest Contentful Paint is the time until the main content shows. What counts, why images and scripts cause most delay, and how to get under 2.5 seconds.
The short answer
Largest Contentful Paint, LCP, is how long a visitor waits from opening your page until the biggest thing in the first screen is visible: usually the hero image or the main heading. It is the closest single number to “how long until the page looks loaded”, and Google’s target is 2.5 seconds or less for three out of four real mobile visits.
Most pages that fail it fail for one of two reasons: the hero image is too heavy or loaded too late, or something blocks the browser from rendering until it has finished.
The four parts of the wait
| Part | What happens | Typical cause of delay |
|---|---|---|
| 1. Time to first byte | The server or network answers with the page | Slow server, far-away server, heavy server-side work |
| 2. Resource load delay | The browser discovers that the hero image exists and starts fetching it | Image hidden behind scripts or styles, lazy-loaded by mistake, injected by JavaScript |
| 3. Resource load time | The hero image downloads | Camera-resolution image, wrong format, not sized for the screen |
| 4. Render delay | The browser can finally paint it | Render-blocking scripts and stylesheets, fonts that hold up text |
A business site loses its time in parts 2 to 4. A static site on an edge network makes part 1 small by default, which is a large head start, and leaves the rest entirely in your control.
How to improve it
- Find the element. PageSpeed Insights names the LCP element for the page. Fix that element, not the page in general.
- Make the image right-sized. Serve it at the dimensions the slot needs, in a modern format, with responsive sizes so phones do not download the desktop version.
- Load it with priority. The hero image must not be lazy-loaded, and it should be discoverable in the HTML, not injected by a script. Mark it as high priority so the browser fetches it first.
- Stop blocking the render. Scripts and stylesheets that must run before anything paints are the classic cause of part 4. Defer scripts, inline the small critical style, load the rest after.
- Handle fonts. Self-host, preload the one used in the heading, and let text show in a fallback font while the web font arrives.
- Serve from close by. A page and its hero image from an edge location near the visitor removes distance from parts 1 and 3.
Where to look first
Open the Core Web Vitals report in Search Console, mobile view, and look at which page groups fail on LCP. Then open PageSpeed Insights for one page from the worst group and read the field data and the named LCP element. Fix that template; every page on it improves. Repeat for the next group. Chasing individual pages is slower than fixing templates.
What this means for you
If your site fails LCP on mobile, the cause is almost certainly the hero image or something blocking the render, and both are fixable without a rebuild. If you are commissioning a new site, ask for the hero to be built with LCP in mind from the start: right size, right format, high priority, nothing in its way. On a static site served from the edge, that combination lands under 2.5 seconds without a tuning project.
Frequently asked questions
What counts as the largest contentful element?
The largest image, video poster or block of text visible in the first screen when the page loads. On most business pages it is the hero image or the main heading. Google's tools tell you exactly which element was measured, which is the first thing to check.
Our LCP is fine on desktop and poor on mobile. Why?
A phone downloads the same hero image over a slower connection and renders it with a weaker processor, while any scripts that block rendering take several times longer. Mobile is where LCP fails and where Google measures it for your visitors. Optimise for the phone.
Does a faster server fix LCP?
It fixes the first of the four parts, the time to the first byte. If that is slow, everything after it is late, so yes. But on 85% of desktop pages and 76% of mobile pages the LCP element is an image, so the time is usually lost on that image or on a script that blocks the render. Check which part is slow before buying a faster server.
Can a static site have a bad LCP?
Yes, if the hero image is huge or a font or script blocks rendering. Static hosting removes the server delay, which is a large head start, but the page still has to be built with the hero element in mind. The good news is that on a static site the fixes are entirely in your control.
Sources
- HTTP Archive Web Almanac 2025: Performance (accessed 2026-09-14)
- Google web.dev: Largest Contentful Paint (LCP) (accessed 2026-09-11)
- Google web.dev: Optimize Largest Contentful Paint (accessed 2026-09-11)