What LCP Measures

Largest Contentful Paint measures the render time of the largest content element visible in the viewport, timed from when the page first starts loading. The key word is visible. LCP only cares about what is above the fold, in the initial viewport, because that is what the visitor sees while they wait. An enormous image far down the page does not count. The largest thing in the first screen does.

On most pages the LCP element is one of a few things: a hero image, a large background image, a prominent heading, or the main block of body text if the page has no large image above the fold. Video poster frames and large buttons can also qualify. The browser determines which element is largest by rendered size in the viewport, and that element becomes the one LCP times.

LCP exists because it captures the moment a page becomes useful. Other loading metrics measure technical milestones that do not map to human perception. First Contentful Paint, for example, fires when the first pixel of content appears, which might just be a logo or a navigation bar. LCP fires when the main content arrives, which is the moment the visitor actually came for. It is the closest single metric to answering “has the page loaded yet” the way a real person would judge it. It is one of the three the metrics that matter Google uses to measure page experience.

The LCP Threshold

Google’s threshold for good LCP is 2.5 seconds or less. Between 2.5 and 4 seconds is “needs improvement.” Above 4 seconds is “poor.” Like all Core Web Vitals, LCP is measured at the 75th percentile of real user page loads, which means the score reflects your slower quarter of visitors, not your average.

That percentile detail changes how you should read your own data. If a testing tool shows your LCP at 2.5 seconds, that is not the experience of a typical visitor. It is the experience at the boundary where 25 percent of your traffic is having a worse time. Your median visitor might be seeing 1.8 seconds while a meaningful slice is waiting four or five. Optimizing LCP means lifting that slower tail, not just improving the average, because the slower tail is what the score measures and what Google ranks on.

The Four Phases of LCP

The single most useful way to think about LCP, and the framing that makes fixing it tractable, is to break the total time into four sequential phases. Every millisecond of your LCP falls into one of these four buckets, and knowing which bucket holds most of your time tells you exactly where to work.

Time to First Byte. The time from the start of navigation to the moment the server sends the first byte of the HTML response. This is server and network time. If your TTFB is slow, every other phase starts late no matter how well optimized it is.

Resource load delay. The gap between when the HTML arrives and when the browser starts downloading the LCP element. If the LCP image is discovered late, or is blocked behind other resources, this phase grows.

Resource load time. The time it takes to actually download the LCP element once the browser starts fetching it. A large unoptimized image makes this phase long.

Element render delay. The gap between the LCP resource finishing its download and the element actually painting on screen. Render-blocking CSS and JavaScript inflate this phase because the browser cannot paint until it finishes processing them.

When you profile a page in a tool that breaks LCP into these phases, the fix becomes obvious. A long TTFB points at hosting or backend. A long resource load time points at image optimization. A long render delay points at render-blocking code. You stop guessing and start working on the phase that actually owns your time.

What Causes a Slow LCP

Mapped to the phases, the causes are predictable. Slow server response, usually from cheap shared hosting, an unoptimized backend, or no caching, inflates TTFB. We see this constantly on sites where the owner is paying eight dollars a month for hosting and wondering why the page is slow. The server is the foundation, and a slow one caps everything above it.

Render-blocking resources are the second major culprit. CSS in the document head blocks rendering by design, and JavaScript that is not deferred or made asynchronous blocks the parser. The browser has to download, parse, and execute these before it can paint the LCP element, which lands the delay in the render phase. A page loading a dozen render-blocking stylesheets and scripts will struggle to hit a good LCP no matter how small the images are.

Large unoptimized images are the third. A hero image saved as a 2 megabyte PNG when it could be a 150 kilobyte WebP is adding seconds to the resource load phase. This is the most common single cause we find, and it is also the easiest to fix. Client-side rendering is the fourth, where a JavaScript framework builds the page in the browser, so the LCP element does not exist in the initial HTML and cannot paint until the framework runs.

How to Improve LCP

Fix the phase that owns your time, in order of where the time actually is. For TTFB, the move is better hosting, server-level caching, and a content delivery network that serves your content from a location near the user. Cheap hosting is the most common bottleneck and the one people are most reluctant to spend on, but it is frequently the highest-leverage fix. A faster server improves every page on the site at once.

For render delay, eliminate render-blocking resources. Inline the critical CSS needed for above-the-fold content and defer the rest. Defer or async non-critical JavaScript so it does not block the parser. This is detailed work but it directly attacks the render phase, and on script-heavy sites it can cut a second or more off LCP.

For resource load time, optimize the LCP image. Serve it in a modern format like WebP or AVIF, compress it appropriately, size it correctly for the viewport rather than serving a desktop image to a phone, and preload it so the browser discovers it early. Adding a preload hint for the LCP image attacks the load delay phase by telling the browser to start downloading it immediately rather than waiting to discover it in the markup. One caution worth naming: preloading too many resources backfires, because it forces the browser to compete for bandwidth. Preload the LCP element and little else.

For client-side rendering, the fix is architectural: move to server-side rendering or static generation so the LCP element exists in the initial HTML. That is a bigger lift than the others and not always feasible, but on a framework-heavy site it is sometimes the only thing that brings LCP into range. A slow LCP often travels with poor layout stability, so it is worth checking both metrics together rather than fixing one in isolation.

FAQ

What is a good LCP score?

A good Largest Contentful Paint score is 2.5 seconds or less, measured at the 75th percentile of real user page loads. Between 2.5 and 4 seconds needs improvement, and above 4 seconds is poor. Because it is measured at the 75th percentile, the score reflects your slower quarter of visitors rather than your average.

What element is usually the LCP element?

The LCP element is the largest content element visible in the initial viewport, most commonly a hero image, a large background image, a prominent heading, or the main block of body text on pages without a large above-the-fold image. The browser determines it by rendered size within the viewport.

What is the most common cause of slow LCP?

The most common single cause we find is large unoptimized images in the above-the-fold area, often a multi-megabyte hero image that could be a fraction of the size in a modern format. After that, slow server response time and render-blocking CSS and JavaScript are the most frequent culprits.

How do I find what is slowing down my LCP?

Profile the page in a tool that breaks LCP into its four phases: time to first byte, resource load delay, resource load time, and element render delay. Whichever phase holds the most time tells you where to work. A long first byte points at hosting, a long load time points at image size, and a long render delay points at render-blocking code.

Does preloading the LCP image always help?

Preloading the LCP image helps when the image is being discovered late by the browser, which is common. But preloading too many resources backfires by forcing them to compete for bandwidth. Preload the LCP element specifically and little else, so the browser prioritizes the one resource that determines your score.

How is LCP different from page load time?

Traditional page load time measures when the entire page and all its resources finish loading, which can happen long after the page is usable. LCP measures when the largest visible content element renders, which is the moment the visitor can see and use what they came for. LCP maps to human perception of loading in a way total load time does not.