What Is LCP?

Largest Contentful Paint measures the moment the largest visible content element finishes rendering. The clock starts when the user begins loading the page and stops at that one element, not at the last thing to arrive.

Google counts only a fixed set of candidates: <img> images, images inside an <svg>, the poster frame of a <video>, any element carrying a CSS background image, and block elements containing text. The browser keeps noting the largest candidate as it paints, and the value locks in as soon as the user first interacts.

That has a practical consequence people rarely expect: the element setting your LCP is seldom the one you assume. On a product page it is usually the main photo, in an article the headline or the lead image, on a video homepage the poster frame. Look it up before optimising rather than guessing.

Two questions get mixed up here. One is how long the whole page takes to load, which is the territory of page speed in general. The other is when the visitor sees something they recognise as the page, and that is what LCP measures. A site can keep pulling scripts through Google Tag Manager for several more seconds without moving the value, as long as the main element is already painted.

That distinction explains why LCP entered Core Web Vitals rather than a total-load metric. What it tries to capture is perception, not the browser's workload. For traffic arriving from search, the moment the page looks usable weighs more than the moment it stops working.

Google sets three bands: up to 2.5 seconds LCP counts as good, between 2.5 and 4.0 seconds it needs improvement, above 4.0 seconds it is poor. The thresholds are the same for mobile and desktop, though the actual values are collected separately.

The part most often misread is the aggregation. It is not an average but the 75th percentile of all visits over the past 28 days: the value three out of four loads stay below. A mean hides slow users behind fast ones. The 75th percentile forces the fourth-worst case to still be usable.

That is why a site can feel quick in the office and fail anyway. The team laptop on fibre sits in the 20th percentile, not the 75th. The numbers that count come from the Chrome User Experience Report, gathered from real browsers, and show up in Google Search Console or PageSpeed Insights.

LCP is not an opaque number. It breaks into four consecutive sub-parts, and knowing which one dominates tells you exactly where the work sits.

1. Time to first byte: how long the server takes to start responding.
2. Resource load delay: the gap between the first byte and the moment the browser even requests the LCP element's image or font.
3. Resource load duration: how long that download takes.
4. Element render delay: the time between having the resource and actually painting it, usually blocked by CSS or JavaScript.

On most sites measured, the first two sub-parts account for the bulk of the total. That shifts the work away from the image and towards the server and the load order, which is technical SEO rather than design.

The last two sub-parts are the ones most often mistaken for an image problem. If render delay dominates, the cause sits in the stylesheet or a blocking script, not in the file. Swapping the JPEG for WebP then moves nothing, and that is the most common reason a team decides the metric is broken.

This diagnosis belongs to the technical side of on-page SEO and overlaps with the crawler's work: what holds up the human browser usually holds up the robot too, and on a tight crawl budget that shows in indexing.

The same four or five causes come back in audit after audit.

• Lazy loading on the hero image. A blanket loading="lazy" across every image also hits the one setting your LCP, and the browser then requests it late on purpose.
• Slow server with no caching. If the first byte lands after a second, 1.5 remain for everything else.
• Render-blocking CSS and JavaScript. The resource is there and the browser is not allowed to paint it.
• Client-side rendering. The page arrives empty and the content shows up once the JavaScript has run.
• Unsized, uncompressed images. A three-megabyte JPEG takes as long as it takes, however good the connection.

Lazy loading deserves its own explanation, because it is the most frequent cause and the easiest to fix. The loading="lazy" attribute tells the browser not to download an image until the user scrolls near it. For everything below the first screen that is a clear win: it saves data and frees bandwidth for what is actually visible.

The trouble starts when the CMS applies it to every image by default, hero image included. The browser then stops requesting the very file that sets the LCP early and waits to learn where it lands in the layout. In a template using responsive design that decision comes late, and the value gets worse without anyone touching the content. The rule of thumb: lazy load every image except the first visible one, which should also carry fetchpriority="high".

Order matters: identify the element first, measure which sub-part dominates second, and only then change anything.

• Remove loading="lazy" from the LCP element and give it fetchpriority="high" so the browser asks for it sooner.
• Preload the image or font that sets the LCP if the browser discovers it late because it lives in CSS.
• Serve the image in a modern format at the size it actually occupies, with width and height declared.
• Cut time to first byte with page caching, a delivery network, and less work per request on the server.
• Take CSS and JavaScript that the first screen does not need out of the critical path.

After each change, wait. Field data is computed over 28 days, so a genuine improvement takes weeks to show up fully in Search Console, even when a lab test shows it at once.

It helps to separate what gets measured from what gets decided. LCP is a technical KPI: it says how long something takes, not whether the page convinces. A landing page that loads in two seconds and misses the search intent still will not convert, and no millisecond fixes that. So speed work is planned alongside CRO, not instead of it.

Whether the change worked shows in two readings together. Field data in Search Console confirms the actual assessment; a heatmap or metrics from web analytics show whether behaviour really changed, looking at bounce rate and dwell time before and after.

• Optimising an image that is not the LCP element, then wondering why the value will not move.
• Treating a tool's lab score as reality; the assessment runs on real user data.
• Looking only at desktop when most visits arrive on mobile, where mobile-first indexing decides.
• Applying lazy loading to every image as a blanket rule, the first one included.
• Re-measuring the next day and drawing conclusions from a window that still holds 27 days of old data.

One last misunderstanding, costlier than it looks: treating LCP as a grade you have to pass. The bands are not an exam, they are a description. Going from 4.2 to 3.8 seconds improves the experience for half your visitors even while the label still reads "needs improvement", and in an e-commerce shop that shows in conversion long before the report changes colour.