Largest Contentful Paint
Largest Contentful Paint records the moment the biggest piece of content in the viewport finishes rendering. On most pages that is the hero image, a background image, a video poster or the headline block. It is the closest single number to the question a visitor is actually asking, which is "has this page loaded yet".
Good
Under 2.5s
Needs work
2.5s to 4s
Poor
Over 4s
Why it matters
LCP is one of the three Core Web Vitals Google uses as a ranking signal, and it correlates strongly with whether people stay. A visitor rarely notices that a page took 2.1 seconds instead of 1.8. They very much notice a blank rectangle where the hero should be, four seconds after they arrived. Because LCP measures the largest element rather than the first, it captures the moment the page stops feeling broken.
How it is measured
The browser watches for the largest contentful element painted in the viewport and keeps updating the candidate as the page loads. It stops updating at the first user interaction, which is why LCP can differ between a real visit and a lab run. Only elements in the initial viewport count, so an enormous image far down the page is irrelevant to LCP even though it still costs bandwidth.
What makes it slow
The LCP element is discovered late
If the hero image is set by CSS as a background, or injected by JavaScript after hydration, the browser cannot begin fetching it until it has parsed the stylesheet or run the script. That discovery delay is often larger than the download itself. A plain img tag in the initial HTML is found by the preload scanner immediately.
The image is far larger than it is displayed
A 3840px wide photograph rendered into a 1280px slot downloads roughly nine times the pixels needed. Every one of them has to arrive and be decoded before the paint can happen. This is the single most common cause of a slow LCP and usually the easiest to fix.
Slow server response
Nothing can render until the HTML arrives. If Time to First Byte is 1.2 seconds, LCP cannot be better than that plus the time to fetch and paint the element. A slow origin puts a floor under every other number on the page.
Render blocking CSS and fonts
The browser will not paint until it has the CSS it needs. A large stylesheet, or a webfont without font-display, delays the first paint of everything including the LCP element.
Client side rendering
When the meaningful content is produced by JavaScript, the browser must download the bundle, parse it, execute it and then paint. On a mid tier phone that chain routinely adds two seconds before anything appears.
How to improve it
Ordered roughly by return on effort. The quick wins are usually worth doing first even when the deeper problem is elsewhere.
Serve the LCP image at its displayed size
Quick winGenerate variants at the widths you actually render and let the browser choose with srcset and sizes. An image CDN can do this per request without a build step. This alone frequently removes more than a megabyte from the critical path.
Add fetchpriority="high" and never lazy load it
Quick winBrowsers assign images a low priority by default until layout proves they are in the viewport. Marking the hero as high priority moves it ahead of the queue. Equally important, loading="lazy" on an LCP image actively delays it and is a common accidental regression.
Preload the image if CSS reveals it
Quick winIf the hero is a CSS background, the preload scanner cannot see it. A link rel="preload" as="image" in the head restores the early discovery that a plain img tag would have given you.
Convert to AVIF or WebP
ModerateAVIF typically lands 40 to 60 percent smaller than JPEG at matching visual quality, WebP around 25 to 35 percent. Serve with a picture element so older clients still get something they understand.
Inline the critical CSS and defer the rest
ModerateShip the styles needed for the first screen in the document, and load the remainder without blocking. This lets the first paint happen while the rest of the stylesheet is still in flight.
Render the hero on the server
InvolvedIf the largest element depends on client side JavaScript, no amount of image tuning will fix it. Server rendering or static generation puts the content in the initial HTML, where the browser can paint it without waiting for a bundle.
How Pulse reports this
Pulse reports LCP against the 2.5 and 4 second boundaries and shows where your value falls on that scale. When the largest element is an image that is oversized or late discovered, the opportunity appears in the report with the intrinsic dimensions, the painted dimensions and the measured saving.
Common questions
What is a good LCP score?
Under 2.5 seconds is good, 2.5 to 4 seconds needs improvement, and over 4 seconds is poor. Google expects 75 percent of real visits to a URL to meet the good threshold before it counts as passing.
Why is my LCP different in the lab and in the field?
A lab run uses one device, one connection and no interaction. Field data aggregates real visitors across many devices and networks, and LCP stops updating at the first interaction, which never happens in a scripted run. Lab data is for finding causes, field data is for knowing where you stand.
Does LCP include images below the fold?
No. Only elements rendered inside the initial viewport are candidates. An image further down the page still costs bandwidth and may harm other metrics, but it does not affect LCP.
Related metrics
Measure LCP on your own page
An audit runs in a real Chromium browser and reports LCP alongside every other metric, with the measured saving behind each recommendation.