Largest Contentful Paint, Explained: Find the Element Slowing Your Page

Largest Contentful Paint, usually shortened to LCP, is the moment when the largest visible piece of content on a page finishes rendering. It might be a hero image, a large heading, or a banner video poster. Search engines treat it as a core loading signal because it approximates the moment a visitor feels the page has actually arrived, rather than the moment the first byte or the first pixel appeared. The commonly cited good threshold is 2.5 seconds, and pages that regularly exceed it feel sluggish even when everything else is fast. The LCP Element Analyzer summarises pasted load timings and identifies which element is responsible, so you can aim your fix at the right thing instead of optimising blindly.

LCP is about one element, and that is the key to using it well. A page can load dozens of resources, but only the largest visible element sets the score. That element is usually the hero image or the main heading, and it is identified by its rendered size, not its file size: a small file stretched to fill the viewport counts as large, and a huge file rendered as a thumbnail does not. The timing also depends on when the element becomes visible, which is why an image that loads late, or a heading whose font arrives late, can set a slow LCP even on a page whose other resources are quick. Knowing the element changes the fix completely: a slow hero image calls for image optimisation, while a slow heading calls for font or rendering fixes.

Four delays feed into LCP, and separating them is how you diagnose a slow score. Time to first byte is how long the server takes to respond. Resource load delay is how long the browser waits before it starts fetching the LCP element, which grows when render-blocking scripts or stylesheets sit ahead of it. Resource load time is how long the fetch itself takes, which grows with file size and slow connections. Element render delay is the gap between the resource arriving and the element actually painting, which grows when the main thread is busy with JavaScript or when a web font swap holds up text. A slow LCP caused by server response needs a different fix from one caused by a 2 megabyte hero image, and the breakdown tells you which one you have.

The element type matters too. If the LCP element is an image, the usual fixes are compression, modern formats, responsive sizing, preloading, and a content delivery network. If it is text, the usual fixes are font loading strategy, such as preloading the font or using a fallback with a swap display, and removing render-blocking work ahead of it. If the LCP element changes as the page loads, for instance a heading that is replaced by a larger image a second later, the score is set by the later, larger element, so stabilising what appears first can itself improve the score. Lazy loading deserves a warning here: never lazy-load the LCP element, because lazy loading by definition delays it, and the largest element is the worst candidate for delay.

A worked example you can follow

Suppose a product page reports an LCP of 3.4 seconds, and the analyzer identifies the hero image as the LCP element. Its timing breakdown is: time to first byte 0.4 seconds, resource load delay 0.6 seconds, resource load time 1.8 seconds, and element render delay 0.6 seconds. Add them: 0.4 + 0.6 + 1.8 + 0.6 = 3.4 seconds, which matches the reported score, so the breakdown accounts for the whole delay. Against the 2.5 second good threshold, the page is 3.4 − 2.5 = 0.9 seconds over, which is 0.9 ÷ 2.5 = 0.36, or 36 percent over budget.

Now read the breakdown for the fix. The largest single part is the resource load time at 1.8 seconds, more than half the total, which points at the image file itself: it is 1.4 megabytes served as a JPEG. Compressing it and serving a modern format cuts it to 380 kilobytes, roughly a quarter of the size, and if load time scales with size, 1.8 × (380 ÷ 1400) = 0.49 seconds, saving about 1.3 seconds. Preloading the hero image removes most of the 0.6 second load delay, saving perhaps 0.5 seconds. Together the new estimate is 0.4 + 0.1 + 0.49 + 0.6 = 1.59 seconds, comfortably inside the 2.5 second threshold. The estimate is approximate, because real networks do not scale perfectly, but it shows why the breakdown matters: without it, you might have spent the same effort on the server response and gained only a fraction of the improvement.

Verify the fix the same way you found the problem. Re-run the analyzer on fresh timings, confirm the LCP element is still the hero image or has changed to something faster, and confirm the new score. If the score improved but a different element is now the largest, that element becomes the next target, and the cycle repeats. Also check on a slower connection, because a fix that passes on fast office broadband can still fail on a mobile network, and the users who feel slow LCP most are usually on the slowest connections.

Common mistakes to avoid

The most common mistake is optimising everything except the LCP element: shrinking footer images and deferring analytics while the hero image stays untouched. A second mistake is lazy-loading the hero image, which directly worsens LCP. A third mistake is judging LCP only on desktop, when mobile viewports often pick a different, larger element and slower networks stretch every delay. A fourth mistake is chasing a single measurement: LCP varies between runs, so compare medians across several runs rather than celebrating one fast result. A fifth mistake is ignoring render delay: a page with a fast image but a busy main thread can still paint late, and the fix there is less JavaScript, not a smaller image.

LCP work also connects to the rest of page performance. The same hero image that sets LCP often dominates bandwidth, so compressing it helps every visitor, not just the metric. The same render-blocking scripts that delay LCP also delay interactivity, so removing them improves more than one score. Treat LCP as a diagnostic lens: it points at the single element a visitor notices most, and fixing that element usually improves the whole experience.

Frequently asked questions

Is LCP the same as page load time? No. Page load waits for nearly everything; LCP stops at the largest visible element, which is why a page can have a good LCP and a long total load, or vice versa.

Why does my LCP element change between runs? Because the largest visible element depends on viewport size, font loading and timing: a heading may be largest first, then an image overtakes it. Test at the viewports your visitors actually use.

What is a realistic LCP target? 2.5 seconds or less is the widely cited good threshold for the 75th percentile of visits, not for a single fast test run.

For the wider loading picture, see Website SEO Audit Guide, and pair this analyzer with the Resource Waterfall Analyzer and the Image Format Converter when working through a slow page. Find the element, split the delay, fix the biggest part first.