What Is Largest Contentful Paint (LCP)?

How Largest Contentful Paint Works

Largest Contentful Paint measures one moment: when the biggest piece of visible content finishes rendering, timed from the instant the user navigated to the page. The logic is that once the largest element is on screen, a visitor almost certainly perceives the page as loaded — the hero has arrived, the headline is readable, the article has begun.

The browser doesn’t know the final answer up front, so it keeps a running candidate. As each element paints, it checks whether that element is now the largest contentful one in the viewport and updates the LCP timestamp. It stops updating at the first user interaction — scroll, tap, or keypress — because after that the “loading” experience is over. Only elements visible in the viewport count; something huge below the fold is ignored until the user brings it into view.

Eligible LCP elements are a defined set: <img> elements, <image> elements inside an <svg>, the poster image of a <video>, elements with a CSS background image loaded via url(), and block-level elements containing text. In practice the LCP element is usually a hero image or the main heading and opening text block.

The Four Phases of LCP

Every LCP time, no matter the page, decomposes into four consecutive phases. Knowing them turns “the page is slow” into a specific diagnosis:

• Time to First Byte (TTFB) — from navigation start until the first byte of the HTML arrives. Ideally around 40% of LCP.
• Resource load delay — the gap between TTFB and the browser starting to fetch the LCP resource. Ideally under 10%; a large value means the resource was discovered too late.
• Resource load duration — how long the LCP resource itself takes to download. Ideally around 40%.
• Element render delay — from when the resource finishes loading until it actually paints. Ideally under 10%; a large value usually points to render-blocking CSS or JavaScript.

The healthy shape is clear: the two “delay” phases should be small, and the time should be spent genuinely loading the document and the LCP resource. When a delay phase balloons, you have found your fix.

Example of Largest Contentful Paint

Consider a page whose LCP element is a hero image and whose field LCP is a poor 4.5 seconds, broken down per Google’s own guidance: TTFB of 0.6s, a resource load delay of 2.5s, a load duration of 1.2s, and a render delay of 0.2s. The load delay — the browser sitting idle before it even starts fetching the hero — is more than half the total, which is the textbook symptom of an image discovered late because it lives in CSS or is injected by JavaScript rather than sitting in the initial HTML.

This is exactly the scenario web.dev’s Optimize LCP guide is built around, and the documented remedy is precise: make the LCP resource discoverable in the initial HTML and preload it, so the browser starts the download immediately after the HTML arrives instead of waiting to parse a stylesheet. Collapsing that 2.5-second delay toward zero pulls LCP from 4.5s down near 2.0s — from poor to good — without touching the image’s size or the server. The other levers only matter after you have located which phase dominates: compressing the image attacks load duration, faster hosting attacks TTFB, and removing render-blocking code attacks render delay.

The lesson generalizes to every LCP problem. Because the metric is defined as four measurable phases, optimization is never a vibe. You measure the real LCP element, split its time into TTFB, load delay, load duration, and render delay, and fix whichever phase is out of proportion. A team that skips the diagnosis and compresses images at random will often leave a 2.5-second delay phase completely untouched.

Largest Contentful Paint and the Rest of Core Web Vitals

LCP owns loading, but it is only one leg of Core Web Vitals. A page can render its hero in 2 seconds and still fail on responsiveness if a heavy script blocks interactions, or on stability if that same hero shifts the layout as it pops in. In fact the two often connect: an image without width and height attributes both loads late (hurting LCP) and pushes content around when it arrives (hurting Cumulative Layout Shift). Fixing LCP well — reserving space, preloading, trimming render-blocking resources — tends to help the other vitals rather than trade against them, which is why it is usually the right place to start.

Frequently Asked Questions

The Bottom Line

Largest Contentful Paint times how long a visitor waits to see the main event on a page — the hero image, headline, or video that dominates the screen. Keep it under 2.5 seconds for the bulk of your users and you have cleared the loading half of Core Web Vitals. The path there runs through four measurable phases, so optimization is diagnosis, not guesswork.