Largest Contentful Paint (LCP) · Definition & Explanation 2026

Largest Contentful Paint (LCP) is a Core Web Vitals metric that reports the render time of the largest image, video poster, or text block visible within the viewport, relative to when the page first started loading. LCP is designed to measure perceived loading speed — when a user feels the page has 'loaded' because the main content is visible.

Google decomposes LCP into four sub-parts, each representing a phase of the loading process:

• •Time to First Byte (TTFB) — Server processing + network transit time. Ideally < 800ms.
• •Resource Load Delay — Time between TTFB and when the browser starts downloading the LCP resource (e.g., hero image). Caused by render-blocking resources or late discovery.
• •Resource Load Duration — Time to download the LCP resource itself. Affected by file size, CDN proximity, and connection speed.
• •Element Render Delay — Time between resource download completion and the element actually painting on screen. Caused by render-blocking JS, pending stylesheets, or heavy main-thread work.

Understanding these four phases is critical for diagnosis: a high LCP can be caused by problems in any phase, and the fix differs dramatically. For example, if TTFB is 2.0 seconds, no amount of image optimization will achieve good LCP — the server must be fixed first.

LCP was introduced by Google in May 2020 as part of the original Core Web Vitals trio (LCP, FID, CLS). It replaced earlier loading metrics like First Meaningful Paint (FMP) and First Paint (FP) which were unreliable and inconsistent across page types.

Key milestones:

• •May 2020 — LCP announced as a Core Web Vital, replacing FMP.
• •June 2021 — LCP becomes a ranking signal as part of the Page Experience Update (mobile).
• •February 2022 — Page Experience signals (including LCP) expand to desktop search.
• •2023–2024 — Google publishes the 'four sub-parts of LCP' framework, helping developers diagnose which phase causes slow LCP.
• •2025–2026 — The 2.5-second threshold remains unchanged. Google has signaled no plans to tighten it.

LCP was designed to be more intuitive than its predecessor (FMP) because it measures a single, identifiable element rather than an algorithmic 'meaningful' paint heuristic.

LCP is measured from navigation start to when the largest content element finishes rendering. The browser continuously updates the LCP candidate as larger elements render and stops recording after user interaction.

Field Data (What Google Uses):

• •Google Search Console — Core Web Vitals report
• •PageSpeed Insights — CrUX section
• •CrUX API — Programmatic access

Lab Data (For Debugging):

• •Lighthouse (25% of performance score)
• •Chrome DevTools Performance panel — identifies the LCP element and timing
• •WebPageTest — filmstrip view shows exactly when LCP renders

Best Practice: Check field data first (PSI or Search Console) to know where you stand. Use lab tools (Lighthouse, DevTools) to diagnose the specific sub-part causing delay.

The four sub-parts of LCP and their common problems:

1. 1Slow TTFB (> 800ms): Poor hosting, missing CDN, uncached dynamic pages, redirect chains, slow database queries.

1. 1High Resource Load Delay: LCP image not discovered until CSS is parsed (background-image), render-blocking scripts delaying resource discovery, missing preload hint.

1. 1Slow Resource Load Duration: Unoptimized images (2-5MB JPEGs), no WebP/AVIF conversion, missing responsive srcset (sending 2000px image to 400px screen), slow or missing CDN.

1. 1High Element Render Delay: Client-side rendering (React/Vue building content after JS executes), render-blocking CSS delaying paint, web fonts blocking text rendering (FOIT), heavy main-thread JavaScript work.