What is Largest Contentful Paint (LCP)?

Largest Contentful Paint measures how long it takes for the biggest visible element — usually a hero image, video poster or headline block — to render in the viewport. Good is 2.5 seconds or less at the 75th percentile of real visits. It is the closest single metric to "did this page feel fast?"

Last updated 2026-07-28

Which element on the page counts as the LCP element?

The LCP element is the largest image or text block visible in the viewport during load — most often a hero image, a video poster frame or the main headline. Content below the fold is never eligible, because LCP only considers what is inside the viewport as the page renders.

The candidate changes as the page loads. The browser keeps nominating a new largest element until the user first interacts or loading finishes, and whichever element held the title at that moment is the one reported.

• An <img> element, including one used as a poster for a video.
• An image loaded via CSS background-image.
• A block-level element containing text nodes.
• The element can change during load: LCP is reported for the largest one at the moment loading finishes or the user first interacts.

What are the four parts of LCP, and which one is slowing my page?

LCP breaks into four sequential parts — time to first byte, resource load delay, resource load duration and element render delay — and only one of them is usually to blame on any given page. Find which part dominates before changing anything, because optimising the wrong part is why so much performance work produces no measurable change.

A useful rule of thumb: if time to first byte alone is over a second, no amount of image compression will save you, and the problem is hosting or caching rather than the front end.

How do I make LCP faster?

Serve the hero image at the size it is actually displayed, in a modern format, and make sure the browser discovers it early — that combination fixes most slow LCP on its own. Everything else on this list is a refinement of those two ideas: make the critical resource smaller, and stop anything from delaying it.

The single most common own goal is lazy-loading the hero image. A blanket loading="lazy" applied by a theme or plugin to every image on the page delays the very element being measured, and reliably makes the score worse.

• Serve the hero image at display size in a modern format — this alone often halves LCP.
• Add fetchpriority="high" to the hero image and preload it so discovery is not delayed.
• Never lazy-load the LCP element; lazy loading above the fold delays the very thing being measured.
• Inline critical CSS and defer the rest so the first paint is not blocked.
• Use font-display: swap so text renders immediately rather than waiting on a webfont.
• Cut render-blocking third-party scripts in the head — consent banners and tag managers frequently sit in front of the first paint.

Why does my LCP differ between Lighthouse and Search Console?

Because they measure different things: Lighthouse simulates one load on throttled mobile conditions, while Search Console reports the 75th percentile of real visits over the previous 28 days. Disagreement between them is normal, and when it happens the field number in Search Console is the one that counts.

Lab runs also miss things real visits include — a cookie banner that only appears in certain regions, an ad slot that fills late, a logged-in header that loads extra data. If the field figure is worse than the lab figure, look for content that only some visitors get.

The reverse case matters too. If the lab figure is worse, you are probably looking at CPU throttling on a simulated mid-range device, which is a fair warning rather than a false alarm. See how lab and field data relate for the full picture.

How do I find the LCP element on my own pages?

Run Lighthouse on the page and read the "Largest Contentful Paint element" entry in the diagnostics — it names the exact element, which turns a vague slowness complaint into a specific fix. Chrome DevTools shows the same thing on the performance panel timeline.

One page at a time is rarely enough, though. LCP problems tend to live in templates, so the same oversized hero appears on every landing page and the same webfont blocks text on every post. Auditing the whole site is what tells you whether you have one heavy page or one bad template.

Audra runs Lighthouse across every crawled page from a macOS app driving your own installed Chrome, so per-page LCP appears in one table alongside the SEO and accessibility checks, and repeated offenders are obvious at a glance. Because it runs locally it can measure staging builds before launch. If you would rather compare tools first, see how whole-site auditing differs from running Lighthouse by hand, or the platform-specific media advice for WordPress sites where media library originals are typically far larger than they need to be.