What is LCP? How to improve Largest Contentful Paint

What LCP measures

LCP is the render time of the largest image or text block visible in the viewport, counted from the moment the page started loading. It answers the question "when does the page look ready?" more honestly than older timings such as the load event, which fire at moments the visitor never sees. It is one of the three Core Web Vitals, together with INP and CLS.

The elements that can be the LCP element are:

• an <img> element, or an <image> inside an SVG;
• the poster image of a <video>, or the first frame of an autoplaying video or an animated image;
• any element with a background image loaded through CSS url();
• a block of text, such as a headline or a paragraph.

The browser skips elements that are probably not content: elements with zero opacity, elements that cover the whole viewport (probably a background), and placeholder images with very little detail.

Two details explain many odd readings. An element only counts once it has been drawn, so an image that is still downloading is not the LCP element yet, and neither is text that is invisible because a web font is still loading. And the size that counts is the visible size: for an image shown smaller than its file, the displayed size; for one stretched larger, the file's own size, whichever is smaller. Margins, padding and borders are not counted.

When LCP is reported

A page loads in stages, so the largest element can change. The browser reports a first candidate after the first frame, often a headline, then a new one each time something larger is drawn, such as the hero image. It stops reporting as soon as the visitor taps, scrolls or presses a key, because those change what is on screen. Your LCP is the last candidate before that.

What counts as good

A page passes when at least 75% of real visits are at or under 2.5 seconds, for mobile and desktop separately. Many pages do not yet: in the 2025 Web Almanac, 74% of desktop pages and 62% of mobile pages had a good LCP.

What is the LCP element on most pages

Mostly an image. The 2025 Web Almanac found an image as the LCP element on 85% of desktop pages and 76% of mobile pages; text accounts for most of the rest. Among LCP images, 57% were JPEG and 26% PNG, with WebP at 11%. About 16% of pages lazy-load their LCP image, which delays exactly the thing the metric is waiting for. If your page is typical, start with the main image.

The four parts of LCP

Every LCP time is the sum of four parts, one after the other. PageSpeed Insights and Chrome DevTools show them as the LCP breakdown.

1. Time to first byte. The wait until the server starts to send the page.
2. Resource load delay. The gap between that moment and the moment the browser starts downloading the LCP image. A long gap means the browser found the image late.
3. Resource load duration. How long the download takes. Large files and slow connections stretch it.
4. Element render delay. The gap between the end of the download and the element being drawn. Blocking CSS and JavaScript, and content that a script has to build first, cause it.

Google's guidance is that the two parts with "delay" in their name should be close to zero, and that most of the time should go to the two parts that involve the network. As a rule of thumb the LCP image should start downloading at about the same time as the first resource the page loads. The shares in the figure are guidelines, not rules: if your LCP is within 2.5 seconds, the proportions do not matter. If it is not, the breakdown shows where the time is lost.

When the LCP element is text there is no image to download, so the time is mostly the first and the fourth parts.

The breakdown tells you where to look. A slow first part is a server problem. A long second part is a discovery problem. A long third part is a file-size problem. A long fourth part is usually blocking code.

Find your LCP element and its breakdown

Run the page through PageSpeed Insights. In Lighthouse 13 the diagnostics include an LCP breakdown insight with the four parts (and, when real-user data exists, a column with the 75th percentile of real visits for each) and an LCP request discovery insight that checks three things about the LCP image:

• the request can be found in the initial HTML;
• fetchpriority="high" is applied;
• loading="lazy" is not used.

In Chrome DevTools, the Performance panel's live view shows the LCP element as you load the page, next to Google's real-user numbers for the same page when they exist.

Fix a slow first part: the server

Cache pages so the server does not rebuild them for every visitor, serve them through a CDN, move off overloaded hosting, and remove redirects. The time to first byte guide covers each one, and what a CDN is explains the second. If this part is more than 40% or so of your LCP, fix it before anything else, because the other fixes cannot start earlier than the first byte.

Fix a long load delay: make the image easy to find

• Put the main image in the HTML as an <img> tag with a src, so the browser finds it while it reads the page. An image that is set in CSS, or that a script adds later, is found late.
• Do not lazy-load it. loading="lazy" on the top image tells the browser to wait.
• Add fetchpriority="high" to the one image most likely to be the LCP element. Use it on one or two images at most; marking many images as high priority cancels the effect.
• If it has to be a CSS background image, add a preload hint for it, because the browser cannot see it early on its own.

<img src="/img/hero-1200.avif" width="1200" height="600" fetchpriority="high" alt="Description of the picture">

The 2025 Web Almanac found fetchpriority="high" on the LCP image of only 17% of mobile pages, so this is still an easy win on most sites.

Fix a long load duration: send fewer bytes

Resize the image to the size it is shown at, compress it, use a modern format such as WebP or AVIF, and serve it from a CDN. The image optimization guide goes through each step. Avoid a large autoplaying video as the first thing on the page.

Fix a long render delay: unblock the page

• Remove or defer CSS and JavaScript that blocks drawing. See critical CSS and render-blocking resources.
• Send the main content in the HTML. When a script has to run before the main content exists, LCP waits for that script.
• If the LCP element is text, make sure a web font does not hide it: use font-display: swap or optional, and preload the one font the top of the page needs.
• Look for long tasks on the main thread right before the element is drawn. A busy main thread delays the paint even when everything has downloaded.

Common mistakes

• A plugin or theme that lazy-loads every image, including the first one.
• A slider whose first slide is loaded by JavaScript.
• A photo saved 4,000 pixels wide and shown 800 pixels wide.
• A cookie banner or pop-up that is larger than anything else on the first screen and becomes the LCP element.
• Testing only on a fast desktop connection. Check mobile, where the same page is slower and judged separately.

After the fix

Run PageSpeed Insights again. The lab result changes at once. The real-user number follows over the next 28 days, because Google's data covers a rolling window of recent visits.

Check your own page

Run the free audit and look at the Largest Contentful Paint element and its breakdown. Write down which of the four parts is longest, and start with the fix for that part. If the element is an image and the report says it was found late or loaded lazily, that is the first thing to change.

Sources

• Largest Contentful Paint (LCP) on web.dev: the definition, the elements, the marks and when it is reported.
• Optimize Largest Contentful Paint on web.dev: the four parts and how to improve each.
• Performance chapter of the 2025 Web Almanac: the page counts and image figures above.
• fetchpriority on MDN.