Largest Contentful Paint (LCP) is a Core Web Vitals metric for loading speed. It reports the render time of the largest image, text block or video visible in the viewport, measured from the moment the user starts navigating to the page (web.dev). The value is in seconds. Lower is better.
At a glance
- Measures
- Render time of the largest image, text block or video visible in the viewport, from the start of navigation
- “Good” threshold
- 2.5 seconds or less
- Assessment
- 75th percentile of page loads, mobile and desktop separately
- Data source
- Field (CrUX, PageSpeed Insights, Search Console) and lab (Lighthouse, Chrome DevTools)
- Core Web Vital
- Yes, one of the three Core Web Vitals
Last checked:
What are the thresholds?
Assessed at the 75th percentile of page loads, mobile and desktop separately. Source: web.dev: Largest Contentful Paint (LCP). Last checked: .
web.dev recommends judging a page by the 75th percentile of page loads, with mobile and desktop reported separately.
| Metric | Measures | Core Web Vital? | Field or lab | “Good” per web.dev |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) (this term) | Render time of the largest image, text block or video visible in the viewport, from the start of navigation | yes (loading) | field and lab | 2.5 s or less |
| INP (Interaction to Next Paint) | Latency of interactions across the whole visit until the next paint; one value that all (or nearly all) interactions fall below | yes (interactivity), since 2024-03-12 | field; in the lab only with simulated interactions, Lighthouse does not measure INP | 200 ms or less |
| CLS (Cumulative Layout Shift) | Largest burst of unexpected layout shifts during the entire lifecycle of the page | yes (visual stability) | field and lab | 0.1 or less |
| TTFB (Time to First Byte) | Time from the start of navigation until the first byte of the response arrives | no (helps diagnose LCP) | field and lab | 0.8 s or less |
| FCP (First Contentful Paint) | Time from the start of navigation until any part of the page's content is rendered | no (helps diagnose LCP) | field and lab | 1.8 s or less |
| TBT (Total Blocking Time) | Total time after FCP during which the main thread was blocked long enough to prevent input responsiveness | no (lab proxy for INP) | lab; web.dev does not recommend field measurement | less than 200 ms on average mobile hardware |
| Speed Index | How quickly content is visually displayed during page load (from a video of the load) | no | lab (Lighthouse) | Threshold according to Lighthouse: mobile up to 3.4 s “fast” (web.dev gives no value) |
| FID (First Input Delay), historical | Time from the first interaction until the browser can begin processing event handlers | until 2024-03-12, replaced by INP | field only | 100 ms or less |
According to web.dev, the 75th percentile of page loads is assessed, mobile and desktop separately. A page passes the Core Web Vitals when LCP, INP and CLS are “good” at the 75th percentile. Chrome tools ended FID support on September 9, 2024. Sources: web.dev: Web Vitals; web.dev: Largest Contentful Paint (LCP); web.dev: Interaction to Next Paint (INP); web.dev: Cumulative Layout Shift (CLS); web.dev: Time to First Byte (TTFB); web.dev: First Contentful Paint (FCP); web.dev: Total Blocking Time (TBT); web.dev: First Input Delay (FID); web.dev Blog: Interaction to Next Paint is officially a Core Web Vital (2024-03-12); Chrome for Developers: Lighthouse – Speed Index. Last checked: .
What counts as the LCP element?
<img> elements, images inside <svg>, <video> elements, elements with a background image loaded through url(), and block-level elements that contain text. Invisible elements and images that cover the whole viewport are excluded. The browser updates the candidate while the page loads and stops when the user first interacts with the page.
What makes up LCP time?
web.dev splits LCP into four parts with typical shares:
| Part | Typical share |
|---|---|
| Time to first byte | about 40% |
| Resource load delay | under 10% |
| Resource load duration | about 40% |
| Element render delay | under 10% |
Example
A page with a large hero photo has an LCP of 3.4 seconds in field data. The photo has loading="lazy" and is not discovered until late. web.dev says never to lazy-load the LCP image and recommends fetchpriority="high" for likely LCP images. After the change the browser starts the download earlier, which shortens the load delay.
Common improvements
- Reduce server response time and redirects.
- Compress images and use current formats.
- Remove render-blocking resources.
Common mistakes
loading="lazy"on the LCP image. web.dev says to never lazy-load the LCP image, since that always leads to unnecessary resource load delay.- Resource not in the initial HTML. Images added by JavaScript, using
data-srcinstead ofsrc, or present only as CSS backgrounds are found late by the browser. - No priority for the LCP image. Images do not have high priority by default.
fetchpriority="high"helps for likely LCP elements but loses effect when it is set everywhere. - Render-blocking files. Large stylesheets or synchronous scripts can delay rendering even after the resource has loaded.
Sources
Last updated: