What actually moves Largest Contentful Paint on a real site

Largest Contentful Paint measures one thing: how long until the biggest visible element in the viewport has finished rendering. Usually that is a hero image, a heading, or the first block of text.

Because it is a single measurement with an obvious number attached, it attracts a lot of advice. Most of that advice is about things that are real but tiny. In practice, four things account for nearly all of the damage.

Find out what the element actually is first

Before changing anything, identify the LCP element on the page you care about. Chrome DevTools reports it in the Performance panel, and PageSpeed Insights names it directly.

This step is skipped constantly and it is the reason people optimise the wrong thing. If your LCP element is a heading rendered from HTML, then compressing your images will not move the number at all, however satisfying the file size reduction looks.

1. The server took too long to respond

If time to first byte is 800ms, your LCP cannot be better than 800ms plus everything after it. No amount of front-end work recovers that.

Common causes, in the order I find them: a server geographically distant from the visitors, a database query running on every page load that could be cached, and a hosting plan that is oversubscribed. The geography one is worth stressing. A site hosted in one region and read from another pays that round trip on every single request, and for a business selling into a different continent from where it is hosted, that alone can be most of the problem.

2. The LCP image is being discovered too late

If the hero image is referenced in CSS, or loaded by JavaScript, or sits inside a carousel that initialises on load, the browser does not know it needs it until quite late.

The fix is to make it discoverable in the initial HTML: a plain img tag with src and srcset, not a background image, and not lazy loaded. Lazy loading the LCP image is a specific and very common mistake, because a blanket lazy-load rule gets applied to every image on the site including the one that defines the metric.

Add fetchpriority="high" to that image. It is one attribute and it tells the browser to stop treating it as equal to everything else in the queue.

3. The image is much larger than it is displayed

An 8000 pixel wide photograph rendered into a 1200 pixel container is downloading roughly forty times the data it needs. This is the single most common issue on sites that were handed over with real photography.

Serve appropriately sized images with srcset, use a modern format, and compress. Then check the file sizes as delivered rather than as stored, because a build pipeline that was supposed to be optimising them often is not.

4. Render-blocking resources in the head

Every stylesheet in the head blocks rendering until it has downloaded and parsed. Every synchronous script does the same. A page with four stylesheets and three third-party tags in the head has told the browser to wait seven times before painting anything.

Practical version: keep your own CSS in one file, defer any script that is not needed for the first paint, and audit third-party tags ruthlessly. Analytics, chat widgets, tag managers and font hosts all sit in this path, and a chat widget that loads before your content is a priority inversion.

Fonts deserve a specific note. A webfont from an external host costs a DNS lookup, a connection and a download before text can be painted in the right typeface. Self-host the font files, use font-display: swap so text is readable while the font loads, and preload the one or two faces the first screen needs.

What to expect

If your LCP is bad, it is usually one of those four, and usually the fix is measured in hours rather than weeks. If your LCP is already around two seconds, further work has sharply diminishing returns and your time is better spent on the content.

One caution about measurement: a single test from a data centre on a fast connection is not what Google uses. Field data, collected from real visitors on real devices, is what counts, and it is generally worse than your lab test. Check the field data before concluding you have fixed it.

Speed and Core Web Vitals work is a fixed-scope item on the pricing page, and it is usually most worthwhile alongside the rest of a technical SEO pass rather than on its own.