Stop Optimising the Wrong LCP Asset

Every performance conversation eventually lands on LCP — Largest Contentful Paint. It is the metric that tells you how quickly the main content of a page becomes visible, and it is the one Google has tied most directly to user experience. But here is the uncomfortable truth: most teams optimise the wrong asset. They compress the hero image, only to discover the real LCP element was a font, a script, or a layout shift they never measured.

This post is a practical, visual guide to finding the asset that actually drives your LCP, connecting it to intent and conversion, and running a before/after diagnostic that separates evidence from opinion.

What LCP actually measures

LCP is the render time of the largest content element visible in the viewport — usually an image, a heading, or a block of text. It is not "how fast the page loads." It is "how fast the most important thing the user can see appears." That distinction matters, because it means the LCP element is not always the biggest file on the page. It is the biggest element that renders.

The practical consequence: you cannot know which asset to optimise by guessing. You have to measure which element is the LCP, then trace which resource delays it.

Find the real LCP asset

The fastest way to stop guessing is to look at the field data and the trace together. Three sources, in order of usefulness:

1. The LCP element in your RUM data. Real-user monitoring tells you which element was the LCP for real visitors, on real devices, on real networks. This is the ground truth.
2. The performance trace. A lab trace (from a tool like Lighthouse or a browser trace) shows the waterfall: which resource loaded when, and which one the LCP element waited on.
3. The waterfall itself. Read it left to right. The LCP element's render time is the sum of everything it depends on — the request that fetches it, the scripts that block it, the fonts that shift it.

The key insight is that the LCP asset is rarely the file you think. It is the file the LCP element actually waits for. A hero image that loads instantly can still have a slow LCP if a blocking script delays the render.

Reading the waterfall

The waterfall is the single most useful diagnostic once you know the LCP element. Read it as a dependency chain, not a list of files: the LCP element's render time is the sum of everything it waits on. A long bar for a script that sits before the LCP element in the critical path is often the real culprit, even when the image itself is small. If you want the canonical definition of the metric and how it is computed, the web.dev guide to LCP is the authoritative reference.

Connect performance to intent

Performance is not a vanity metric. It is a conversion lever, but only when you connect it to what the visitor is trying to do. A fast page that shows the wrong thing converts worse than a slower page that shows the right thing. So before you optimise, ask what the LCP element is for:

• On a landing page, the LCP is usually the hero — the first thing that must convince a visitor to stay.
• On a product page, the LCP is often the gallery image — the thing that builds buyer confidence.
• On a search or category page, the LCP is the result grid — the thing that proves the page answered the query.

The LCP asset is the one that carries the intent. Optimising it is not decoration; it is removing friction from the moment the visitor decides whether to engage.

A before/after diagnostic

The honest way to evaluate a performance change is a controlled before/after, and the honest way to present it is to distinguish what you measured from what you believe. Here is the shape of a diagnostic you can run on your own page:

The discipline is to change one thing at a time. If you optimise three assets at once and LCP improves, you do not know which one mattered — and you cannot repeat the win.

Analytics evidence is what you measured. Opinion is what you believe. A before/after diagnostic is only useful if you can tell the difference — and if you changed one variable at a time.

A founder-friendly performance checklist

You do not need to be a performance engineer to run this checklist. It is designed to be answered by anyone who owns a page:

• I know which element is the LCP on my most important pages.
• I know which resource that element waits on.
• I have a baseline measurement recorded before any change.
• I optimise one asset at a time and re-measure after each.
• I connect the LCP element to what the visitor is trying to do.
• I can tell the difference between what I measured and what I believe.

If you can answer all six, you are no longer guessing. You are running a performance program.

Where this leads

The goal is not a perfect score. It is knowing which asset matters, measuring it honestly, and improving it in a way you can repeat. That is what turns performance from a one-off sprint into a durable advantage.

If you want a partner who will measure the real LCP asset before touching a single image, our offers show how we scope performance work around evidence rather than assumptions.