What is LCP? | Search OS

LCP is the time it takes for the largest content element in the viewport to be painted to the screen, a Core Web Vitals metric that captures perceived loading speed.
A value at or below 2.5 seconds is rated "Good," while anything above 4 seconds is "Poor," assessed at the 75th percentile of real users.
The main contributors are slow server response (TTFB), delays in discovering and loading the LCP resource, and render-blocking resources; you improve it with image optimization, preloading, and a CDN.

Overview

Largest Contentful Paint (LCP) measures the time from the start of page load until the largest content element within the viewport is rendered. Because this "largest element" usually corresponds to the page's core content, a fast LCP lets users quickly recognize that the page is useful. In other words, LCP stands in for the loading speed users actually feel, and it is one of the three Core Web Vitals defined by Google.

Elements eligible to be the LCP candidate include <img>, an <image> inside an SVG, <video>, elements with a background image set via CSS url(), and block-level elements that contain text nodes. The browser stops reporting new LCP entries the moment a user interacts with the page through a tap, scroll, or keypress.

Thresholds

LCP is evaluated against the 75th percentile of page loads, measured separately for mobile and desktop. The goal is for three out of every four users to have a good experience.

Rating	LCP value
Good	2.5 seconds or less
Needs improvement	More than 2.5 seconds, up to 4 seconds
Poor	More than 4 seconds

Main Causes

web.dev breaks total LCP time into four sub-parts. Knowing how much each part contributes helps you decide where to focus your efforts first.

Sub-part	Description	Typical share
TTFB (Time to First Byte)	Time from the start of page load until the first byte of the HTML document arrives	~40%
Resource load delay	Time after TTFB until the browser begins loading the LCP resource	Under 10%
Resource load time	Time spent downloading the LCP resource itself	~40%
Element render delay	Time after the resource finishes loading until the LCP element is fully rendered	Under 10%

Optimization

Reduce TTFB: Cut unnecessary redirects and use an efficient caching policy so repeat visits can be served from cache.
Eliminate resource load delay: Make sure the LCP resource is discoverable by the browser's preload scanner within the initial HTML response, and assign fetchpriority="high" to the key image. Never apply lazy-loading to the LCP image.
Shorten resource load time: Use a CDN to reduce the distance to users, and adopt modern image formats and compression.
Reduce element render delay: Minimize render-blocking stylesheets and synchronous scripts, and use server-side rendering so image resources are discoverable in the HTML source.

Evidence

The 2.5-second and 4-second thresholds and the measurement methodology are specified in Google's official web.dev LCP documentation (web.dev/articles/lcp). The sub-part breakdown and optimization recommendations follow web.dev's LCP optimization guide (web.dev/articles/optimize-lcp). The fact that Core Web Vitals factor into Google Search rankings is documented in Google Search Central (Understanding Core Web Vitals and Google search results).

Implementation Checklist

Use a measurement tool first to confirm which element is the actual LCP element in the viewport.
Expose the LCP image directly in the initial HTML and remove lazy-loading.
Apply fetchpriority="high" or preload to the key image.
Convert images to modern formats such as WebP or AVIF and compress them appropriately.
Use a CDN and caching policy to reduce the distance and time for resource delivery.
Inline or defer render-blocking CSS and JS.
Periodically check that the 75th-percentile LCP of real-user (field) data stays at or below 2.5 seconds.

LCP