What is LCP in Core Web Vitals? A plain-English guide to faster loading

Largest Contentful Paint (LCP) is a Core Web Vitals metric that measures how long it takes for the largest visible piece of content on your screen to finish rendering. If you open a web page and have to wait several seconds staring at empty whitespace before the main heading or hero photo finally appears, you are dealing with a slow LCP.

Google uses LCP as its primary benchmark for perceived loading speed. Visitors do not care when the background tracking scripts or footer links finish loading; they care about when the primary message above the fold becomes readable and useful.

Google scores LCP in seconds based on real user visits recorded over 28-day periods. A good LCP score is 2.5 seconds or faster. A score between 2.5 and 4.0 seconds needs improvement, while anything over 4.0 seconds is classified as poor. Maintaining a score under 2.5 seconds is critical to passing page experience audits, as detailed in my guide where I have Core Web Vitals explained.

What counts as an LCP element?

The browser determines the LCP element by scanning the viewport—the visible area of the screen before a visitor scrolls down. It calculates the physical pixel area of every visible element, and whichever single block of content takes up the most space is designated as the LCP candidate.

As the page loads, this candidate can change. For example, a paragraph of text might render first and temporarily hold the title of LCP element. Half a second later, a large hero image finishes downloading right beside it; because the image is physically larger, the browser updates the LCP measurement to match that image's final render time.

In most projects I work on, the LCP element is almost always one of four things:

• A large hero image or banner graphic at the top of a landing page.
• An image element used inside an SVG container.
• A video poster image or background video preview frame.
• A large block of typography, such as an H1 main heading or introductory paragraph.

The four sub-parts of LCP time

Many website owners assume that fixing a slow LCP just means compressing an image. In practice, LCP is made up of four distinct phases that happen sequentially. To fix the score, you need to identify which specific phase is eating up your budget.

Time to First Byte (TTFB): This is the time your visitor spends waiting for your web server or hosting provider to respond with the first byte of HTML. If your server is slow, database queries lag, or your hosting lacks edge caching, your LCP is delayed before the browser even receives the code.

Resource load delay: This is the gap between when the browser receives the HTML and when it actually discovers and requests the LCP element. If an image is hidden inside an external CSS file or injected dynamically by JavaScript, the browser will not request it immediately, wasting precious seconds.

Resource load duration: This is the actual time it takes for the browser to download the file over the visitor's network connection. Large uncompressed images, unoptimized video assets, and slow content delivery networks inflate this phase directly.

Element render delay: This is the gap between when the asset finishes downloading and when it finally renders on screen. If heavy JavaScript tasks are tying up the browser's main thread, or if custom fonts cause invisible text flashes, the asset sits in memory waiting to be drawn.

Common causes of poor LCP scores

When running a speed and Core Web Vitals fix, slow LCP times usually trace back to a few recurring technical issues. Identifying these bottlenecks helps pinpoint where performance optimization should focus.

• Lazy loading above-the-fold media: Native lazy loading is great for pictures down the page, but adding lazy attributes to your main hero photo actively delays its download.
• Client-side rendering without pre-rendering: Frameworks that wait for client JavaScript to execute before requesting API data and building the DOM introduce massive render delays.
• Oversized image formats: Serving raw JPEG or PNG files that weigh several megabytes instead of modern AVIF or WebP formats forces mobile visitors to download unnecessary data.
• Render-blocking CSS and fonts: External stylesheets and web fonts imported late in the document block the browser from drawing content even after the text files are ready.

Practical steps to bring your LCP under 2.5 seconds

Improving your LCP score requires addressing both server response times and asset delivery. You can check your baseline right away using a free website speed test to see where your delays occur.

First, prioritize the LCP asset in your HTML. Use a link tag with rel="preload" in the document head for your primary hero image. This instructs the browser to download the image in parallel with stylesheets rather than discovering it late during DOM parsing.

Second, adopt modern responsive image handling. Serve images in WebP or AVIF formats sized specifically for mobile and desktop screens. Next.js does this automatically through its built-in Image component, but any modern stack can generate responsive srcset attributes to avoid serving desktop resolutions to phones.

Third, eliminate server lag with static generation or edge caching. When pages are pre-built to static HTML or cached close to visitors on a global content delivery network (CDN), server response times drop to tens of milliseconds, leaving more than two full seconds for the visual assets to download and render.

Practical takeaway

Largest Contentful Paint measures when the primary piece of content on your page is fully visible to real visitors. To stay comfortably within Google's 2.5-second threshold, identify your largest above-the-fold asset, preload it early in your HTML, optimize its file weight, and keep server response times fast.

Want help with this? See my Speed & Core Web Vitals fix service, or send me your site for a free review.