Largest Contentful Paint (LCP)
LCP is the moment the biggest image or block of text in the viewport finishes rendering — the point where a visitor feels "the page is here". Google counts 2.5 seconds or less as good.
Watch the LCP candidate change
HTML arrives
The first bytes are here, but CSS is still blocking rendering. Nothing is painted.
How LCP works
The browser reports a new LCP candidate every time a larger element paints: first maybe a heading, then a hero image. The last candidate before the user interacts or scrolls is the page's LCP.
Elements that count: <img>, <image> inside SVG, <video> poster images, elements with a CSS background-image loaded via url(), and block-level elements containing text. Size is the visible area in the viewport, not the file's pixel size.
Web.dev breaks LCP into four sub-parts: time to first byte, resource load delay (how late the LCP image was discovered), resource load duration (downloading it) and element render delay. On a waterfall you can see all four.
Common causes of a poor LCP
- Slow server response
- Everything starts after TTFB. A 1.5 s server response leaves 1 s for everything else.
- Late discovery
- The hero image is set in CSS or injected by JavaScript, so the browser only finds it after downloading and running those files. It appears far down the waterfall.
- Lazy-loading the hero
- loading="lazy" on the LCP image tells the browser to wait until layout — a common self-inflicted delay.
- Render-blocking CSS and JS
- Even when the image has arrived, it can't paint until blocking stylesheets and scripts finish.
- Heavy images
- A 600 KB JPEG takes seconds on a mobile connection. Size it for the viewport and use AVIF/WebP.
How to improve LCP
- Put the LCP image in the HTML as a plain <img> with fetchpriority="high"; never lazy-load it.
- If it must come from CSS, add <link rel="preload" as="image" href="…" fetchpriority="high">.
- Serve it from your own origin (or preconnect to the image CDN) to skip extra connection setup.
- Compress and size it: AVIF/WebP with srcset so phones download phone-sized files.
- Cut render-blocking CSS/JS and reduce TTFB — both push every paint later.
See your page's request order, TTFB and render-blocking files in the waterfall speed test, or check the render-blocking resources on their own.
Enter your field numbers in the Core Web Vitals checker to see whether you pass.
LCP questions
What is a good LCP score?
2.5 seconds or less is good, 2.5 to 4 seconds needs improvement, and over 4 seconds is poor. Google evaluates the 75th percentile of page loads, separately for mobile and desktop, using real Chrome user data (CrUX).
How do I find my LCP element?
In Chrome DevTools open the Performance panel; the live metrics view names the LCP element as the page loads. Lighthouse also shows it under "LCP element" or the LCP breakdown insight. You can paste the snippet on the Core Web Vitals page into the console to log it too.
Does LCP include content below the fold?
No. Only the part of an element that is visible in the viewport counts towards its size, and elements that are completely off-screen are ignored.
Why is my lab LCP different from field LCP?
Lab tools test one load on one simulated device and network. Field data reflects real visitors: many devices, cached visits, different locations and pages that were opened in background tabs. Use field data to decide if there is a problem and lab data to diagnose it.