LCP (Largest Contentful Paint) is a web performance metric that reports the time from the start of navigation until the largest image, video or text block visible in the viewport is rendered. It approximates the moment a visitor perceives that the main content has loaded, and it is one of the three Core Web Vitals, alongside INP for responsiveness and CLS for visual stability.
A page has good LCP at 2.5 seconds or less, measured at the 75th percentile of real page loads, separately for mobile and desktop. Because it reflects server speed, resource discovery, download time and rendering together, LCP is often the most useful single number for diagnosing a slow page.
How LCP is measured
The browser measures LCP by emitting a largest-contentful-paint entry each time a new, larger content element is painted during page load. The value that counts is the last entry before the user interacts with the page by tapping, scrolling or pressing a key, or before the page is hidden, because later content changes are usually caused by the user rather than by loading.
Size means the visible area inside the viewport, not the intrinsic size: an image clipped by its container or partly off screen counts only for its visible portion, and an upscaled image counts at its intrinsic size if that is smaller. Elements removed from the DOM remain valid candidates if they were painted.
Only certain element types qualify as candidates, as the table shows.
| Element type | Counts when | Notes |
|---|---|---|
| `img` element | The first frame of the image is painted | Most common LCP element on content sites |
| `image` inside SVG | The image is painted | Inline SVG shapes alone do not count |
| `video` poster or first frame | The poster image or first frame is painted | Autoplay video can therefore set LCP |
| CSS background image | Loaded through url() and painted | Harder for the browser to discover early |
| Block-level text | Text nodes in a block element are painted | Web font swapping can update the entry |
Browsers apply heuristics that exclude elements unlikely to be content, such as elements with zero opacity and low-information placeholder images. The exact heuristics are implementation details and have changed over time, so a measured LCP element should always be verified in a trace.
LCP thresholds and the four subparts
LCP results are classified into three bands, and a page passes the Core Web Vitals assessment for this metric only when at least 75% of real visits fall in the good band.
| Rating | LCP at 75th percentile | Interpretation |
|---|---|---|
| Good | 2.5 s or less | Main content appears promptly |
| Needs improvement | Above 2.5 s up to 4.0 s | Noticeable wait, typically on mobile networks |
| Poor | Above 4.0 s | Visitors often abandon or reload |
For diagnosis, the total time is split into four sequential subparts. Identifying which subpart dominates directs the fix far better than generic advice.
| Subpart | Spans | Typical cause when large |
|---|---|---|
| Time to first byte | Navigation start to first byte of HTML | Slow server, redirects, no CDN caching |
| Resource load delay | First byte to start of the LCP resource download | Late discovery, lazy loading, low priority |
| Resource load duration | Download of the LCP resource | Oversized image, no modern format, slow network |
| Element render delay | Download end to the element being painted | Render-blocking CSS or JavaScript, client-side rendering |
As a rough guide, a well-optimized page spends most of its LCP in TTFB and resource download, with load delay and render delay close to zero. When text is the LCP element, the two resource subparts are zero and the remaining time is TTFB plus render delay.
LCP compared with related metrics
LCP belongs to a family of loading metrics that capture different moments of the same page load. It replaced earlier metrics such as First Meaningful Paint because it is simpler to define and correlates better with perceived loading.
| Metric | What it marks | Relationship to LCP |
|---|---|---|
| TTFB | Arrival of the first response byte | Lower bound and first subpart of LCP |
| FCP | First paint of any text or image | Always at or before LCP |
| LCP | Paint of the largest visible content element | Main perceived-load signal |
| Speed Index | How quickly the viewport fills visually | Lab-only; summarizes progress, not one moment |
A large gap between FCP and LCP usually means the main image or hero content is discovered or rendered late, while a large TTFB means the problem sits on the server or network, before any front-end optimization can help.
How to improve LCP
Improving LCP means shortening whichever subpart dominates, and the decision table maps common findings to effective fixes.
| Finding | Fix | Effect |
|---|---|---|
LCP image has loading="lazy" | Remove lazy loading from the hero image | Download starts immediately |
| Image discovered late (CSS or JavaScript) | Use an img tag or a preload hint | Eliminates resource load delay |
| Image competes with other downloads | Add fetchpriority="high" | Browser fetches it first |
| Large image file | Serve AVIF or WebP with srcset and correct sizes | Shorter download |
| High TTFB | Cache HTML at a CDN edge, remove redirects | Every later subpart starts sooner |
| Content rendered by JavaScript | Use server-side rendering or static generation | Removes render delay |
Web fonts deserve separate attention when text is the LCP element: preloading the critical font and using font-display: swap or optional prevents invisible text from delaying the paint.
Common mistakes in measuring and optimizing LCP
- Relying only on lab data. Lab tools run one device and network profile; field data from real users decides the Core Web Vitals assessment.
- Lazy loading every image, including the hero, which delays the most important download on the page.
- Optimizing the wrong element. The LCP element differs between mobile and desktop layouts and must be identified per viewport.
- Hiding content until JavaScript runs, for example with A/B testing scripts that blank the page, which adds render delay to every visit.
- Ignoring the back/forward cache. Pages restored from it report near-instant LCP, so blocking it removes many fast visits from the distribution.
LCP is not supported in every browser, so field data from browsers without the API is missing; the sample therefore reflects mainly Chromium-based and, more recently, Firefox users.
Understanding it simply
LCP measures how long a visitor waits to see the main thing on a page. That is usually the big photo at the top or the first large block of text. The clock starts when the visitor opens the page. It stops when that main piece appears.
Think of a restaurant. Bread may come quickly, but the meal is what matters. LCP times the meal. A good page shows its main content in two and a half seconds or less, and faster pages keep more visitors.
Applied in practice
A regional travel agency finds that its destination pages have a mobile LCP of 4.6 seconds at the 75th percentile in field data. A trace shows that the LCP element is a full-width hero photo set as a CSS background image, discovered only after the stylesheet loads and delivered as a 900 KB JPEG.
The developers replace the background with an img element using srcset, AVIF files of about 120 KB for phones, and fetchpriority="high". They also remove loading="lazy" from that image and configure the CDN to cache the HTML, which cuts TTFB from 900 ms to about 250 ms.
After four weeks of new field data, mobile LCP settles at about 2.1 seconds, and the pages move into the good band of the Core Web Vitals assessment.