What is Largest Contentful Paint (LCP)?
What counts as the LCP element, the four parts of the timing, and the fixes in order — starting with the most common self-inflicted cause: lazy-loading the hero image.
Largest Contentful Paint (LCP) measures loading speed as a person actually perceives it: the moment the largest content element visible in the viewport — usually a hero image, a heading, or a large block of text — has finished rendering. It is one of the three Core Web Vitals, and a good LCP is 2.5 seconds or less.
What counts as the LCP element
The browser watches the largest element painted within the viewport as the page loads and reports the render time of whichever ends up largest. In practice that is a hero or featured image, a large background image, a video poster frame, or the main headline and opening paragraph. Elements below the fold do not count — only what is visible without scrolling. Identifying your LCP element is the first step, because everything else is about making that element appear sooner.
The four parts of LCP
Google breaks LCP into four consecutive sub-parts, and knowing which one is largest tells you what to fix:
Time to First Byte (TTFB). How long the server takes to send the first byte of the page. If this is slow, nothing else can start — see how to reduce TTFB. Resource load delay. The gap between the page starting to load and the browser beginning to fetch the LCP image — usually caused by the image being discovered late or deprioritized. Resource load time. How long the LCP image itself takes to download, which is a function of its file size and your connection. Element render delay. The gap between the resource arriving and it actually painting, often caused by render-blocking scripts or client-side rendering.
The most common causes
Lazy-loading the LCP image. The single most frequent self-inflicted cause. Blanket loading="lazy" on every image, or a lazy-load library applied site-wide, tells the browser to delay the one image it should be rushing. The above-the-fold hero must load eagerly. A slow server. High TTFB pushes every later stage back. Render-blocking CSS and JavaScript. The browser will not paint until it has processed blocking resources in the <head>. Large, unoptimized images. An uncompressed multi-megabyte hero in the wrong format. Client-side rendering. If the content is drawn by JavaScript after load, the LCP element cannot paint until that JavaScript has run.
How to improve it
Work in the order LCP happens. Get the server responding quickly (caching, a CDN, less work per request). Make sure the LCP image is discovered and fetched early: do not lazy-load it, and add fetchpriority="high" or a <link rel="preload"> so the browser prioritizes it. Serve the image in a modern format (WebP or AVIF), sized to the space it occupies rather than the original dimensions. Remove or defer render-blocking resources so nothing stands between the image arriving and it painting. Then re-measure — LCP responds well to targeted fixes because it comes down to one element.
How to check yours
Our Core Web Vitals checker shows your real-user LCP from field data — the number Google uses. The page speed checker runs a Lighthouse lab test that identifies your LCP element and breaks down the timing, which is what you re-run after each change to confirm it worked. Because field data is aggregated over 28 days, expect the real-user score to catch up a few weeks after you deploy the fix.
Frequently asked questions
- What is Largest Contentful Paint (LCP)?
- LCP is a Core Web Vital that measures loading speed as a user perceives it — the time until the largest content element visible in the viewport, such as a hero image or headline, has rendered. A good LCP is 2.5 seconds or less, measured at the 75th percentile of real visitors.
- What is a good LCP score?
- 2.5 seconds or less is good, between 2.5 and 4 seconds needs improvement, and over 4 seconds is poor. The threshold is measured at the 75th percentile of your page loads in field data, so at least three-quarters of real visits must render the largest element within 2.5 seconds for the page to pass.
- Why is my LCP slow?
- The most common cause is accidentally lazy-loading the above-the-fold LCP image, which tells the browser to delay the one image it should rush. Other frequent causes are a slow server response (high TTFB), render-blocking CSS or JavaScript, large unoptimized images, and client-side rendering that draws the content only after JavaScript runs.
- How do I fix a slow LCP?
- Work in the order LCP happens: speed up the server response, ensure the LCP image is not lazy-loaded and is prioritized with fetchpriority='high' or a preload link, serve it in a modern format sized to its display space, and remove render-blocking resources. Because LCP usually comes down to a single element, targeted fixes to that element move the number quickly.
- Should I lazy-load my hero image?
- No. Lazy-loading is for images below the fold that a visitor may never scroll to. Applying it to the above-the-fold hero — which is usually the LCP element — delays exactly the image the browser should load first, and it is one of the most common causes of a poor LCP. Load the hero eagerly and lazy-load only what is off-screen.
- What is the difference between LCP and page load time?
- Traditional page load time measures when every resource has finished, including things the user never sees. LCP measures something more useful: when the largest element the visitor actually came to see has rendered. A page can keep loading assets in the background long after its LCP, and that is fine — LCP captures the moment the page feels ready.