What Is LCP (Largest Contentful Paint)?

Reviewed by Ionut Caval · Updated June 2026

Largest Contentful Paint is the loading-experience pillar of the Core Web Vitals. It marks the moment the largest image, video poster, or block of text in the initial viewport finishes rendering, which is a close proxy for when a visitor feels the page is usable. Browsers track LCP candidates as the page paints and report the largest one once the user first interacts or the page is backgrounded. Google's threshold is straightforward: an LCP of 2.5 seconds or less is "good", 2.5 to 4.0 seconds "needs improvement", and over 4.0 seconds "poor". Like every Core Web Vital, it is graded at the 75th percentile of real visits, so three out of four page loads must beat 2.5s before a site passes.

What drives LCP

LCP is the sum of several stages, and the two largest are usually outside the visible element itself. The first is TTFB (Time to First Byte): nothing can render until the server returns the document, so a slow backend, redirect chain, or unwarmed cache pushes every later stage back. The second is render-blocking resources: CSS and synchronous JavaScript in the document head must be downloaded and parsed before the browser paints anything, delaying the largest element even when the server was fast. The remaining time covers loading the LCP resource (typically a hero image) and painting it once styles are ready.

• TTFB and server response: cache the document, cut redirects, and reduce backend work.
• Render-blocking CSS/JS: inline critical CSS, defer non-critical scripts, and trim head weight.
• Resource load time: compress and right-size the hero image, preload it, and serve modern formats (WebP/AVIF).
• Client-side rendering: avoid painting the main content only after a large JS bundle hydrates.

How LCP fits with the other vitals

LCP measures loading; the two siblings measure different things and have their own "good" bars. INP (Interaction to Next Paint) measures responsiveness, with good at 200 ms or less, and CLS (Cumulative Layout Shift) measures visual stability, with good at 0.1 or less. A page must clear all three thresholds at the 75th percentile to pass Core Web Vitals overall.

Because these are field metrics, they come from real visitor sessions captured by real user monitoring rather than a single lab test, which can read very differently from what users on slow phones experience. Lab tools estimate LCP; RUM reports the distribution you are actually graded on. LCP cannot, however, tell you whether a page is reachable at all: a fully down site sends no field data. That availability signal comes from scheduled external checks instead, the distinction covered in synthetic monitoring vs real user monitoring. Pairing the two gives the full picture, and Pulsetic's uptime and API monitoring watches the TTFB and response health that LCP depends on from multiple regions.

See also: Synthetic vs real user monitoring