Largest Contentful Paint (LCP)
LCP is the moment the biggest image or text block in the visible part of the page finishes painting. It’s the closest single number to “when did this page look loaded?”.
What counts as the LCP element
The browser considers <img> elements, <image> inside SVG, the poster of a <video>, elements with a CSS background-image loaded via url(), and block-level elements containing text. It picks the largest one visible in the viewport, and it keeps updating the candidate until the user first interacts. Full-viewport images treated as backgrounds and low-entropy placeholders are ignored.
On most mobile pages the LCP element is the hero image or the article headline. Our checker prints the exact element Lighthouse picked.
Build an LCP out of its four parts
Drag the sliders. Google’s Chrome team breaks every LCP into these sub-parts; on well-optimised pages, TTFB and load time dominate, and the two delays are close to zero.
Server responds with the first byte of HTML.
Gap until the browser starts fetching the LCP resource.
Downloading the image or font itself.
Resource is there, but blocked from painting.
Biggest lever right now: load time. The file itself is heavy. Serve AVIF/WebP at the displayed size with srcset, and from a CDN close to visitors.
How to improve LCP, in priority order
- Make the LCP resource discoverable in the HTML. A real
<img src>orsrcsetin the server response, not a CSS background, a JS-rendered component or adata-srclazy-loader. - Never lazy-load the LCP image. Remove
loading="lazy"from above-the-fold images, and addfetchpriority="high"so it jumps the queue. - Cut TTFB. Cache HTML at a CDN edge, avoid redirect chains, and keep server rendering under ~200 ms. See TTFB.
- Shrink the file. AVIF or WebP, served at the displayed size through
srcsetandsizes. A 1600 px hero on a 400 px phone wastes most of the bytes. - Remove render blockers. Inline critical CSS,
deferscripts, and usefont-display: swaporoptionalwhen the LCP element is text. - Preconnect to third-party image hosts with
<link rel="preconnect">, or better, serve the hero from your own origin.
Why lab LCP and field LCP differ
Lighthouse loads the page once, cold, on a throttled connection, so its LCP is usually worse than field data for sites with returning visitors and warm caches. The reverse happens when real users land on pages with consent banners, A/B testing scripts or personalised heroes that the lab run never sees. Judge the page by the field value; use the lab run to find the cause.
Check it on your own page
Field and lab numbers for mobile and desktop, in about 30 seconds.
Questions people ask
What is a good LCP score?
2.5 seconds or less at the 75th percentile of page loads. Between 2.5 and 4 seconds needs improvement; over 4 seconds is poor.
What is the most common cause of a slow LCP?
Resource load delay: the browser finds the hero image late because it is lazy-loaded, set as a CSS background, or injected by JavaScript. Putting it in the HTML with fetchpriority="high" often saves more than a second.
Does LCP include images below the fold?
No. Only elements visible in the viewport during load are candidates.
Can text be the LCP element?
Yes. Headings and paragraphs are candidates. When text is the LCP element, web font loading and render-blocking CSS are the usual culprits.