What LCP measures
LCP answers one question: how long does a visitor wait before the main content of the page appears? It times the render of the largest image, video or text block visible in the viewport, counting from the moment the visitor started navigating to the page. It's one of the three Core Web Vitals, alongside INP (responsiveness) and CLS (visual stability).
Google confirms that its ranking systems use Core Web Vitals. It also says good scores don't guarantee top rankings: Search still favors the most relevant content, even when its page experience is weaker.
How LCP is calculated
Which elements count
The browser picks the largest element among images (including an image inside an SVG), videos, elements with a CSS background image, and blocks of text. It stops updating LCP as soon as the visitor interacts with the page with a tap, a scroll or a keypress.
Google's thresholds
Image: web.dev, by Philip Walton and Barry Pollard, licensed under CC BY 4.0.
Google assesses the 75th percentile of page loads, separately for mobile and desktop. In other words, three visits out of four need to come in under 2.5 seconds for the page to pass.
The four parts of LCP
web.dev breaks LCP into four subparts: time to first byte (TTFB), resource load delay, resource load duration and element render delay. The two delays should each stay under 10% of the total. Server response and the download itself should account for most of the time.
How to measure LCP
Field data comes from real Chrome users, through the Chrome UX Report. You'll find it in Search Console's Core Web Vitals report and in PageSpeed Insights, which uses a rolling 28-day window. This is the number that reflects what your visitors actually experience.
Lab data comes from a simulated load (Lighthouse, PageSpeed Insights, Chrome DevTools) on one device with fixed network conditions. It's what you debug with, and it can differ from field data.
The Pushrank SEO audit records LCP for your main pages on mobile and desktop, using Chrome field data when Google has it, alongside a Lighthouse test.
Common causes of a slow LCP
- Lazy-loading the hero image.
loading="lazy"on the LCP image delays its download. web.dev recommends the opposite:fetchpriority="high". - Hiding the image in CSS or JavaScript. The browser discovers it late. Make sure it's referenced in the initial HTML.
- A slow server. A long TTFB pushes everything back. Redirect chains and unique URL parameters that bypass your CDN cache make it worse.
- Trusting one Lighthouse run. A green lab score means little if your field data stays poor.
Example
A homepage opens with a large hero photo. Field data on mobile puts LCP at 4.2 seconds, which is poor. A Lighthouse run shows the photo is lazy-loaded and weighs 900 KB as a JPEG. The team removes loading="lazy", adds fetchpriority="high" and serves a compressed WebP sized for each screen. The lab result drops under 2.5 seconds. Field data follows over the next few weeks, as the 28-day window rolls over.
