Largest Contentful Paint: how to actually fix it

What LCP measures

Largest Contentful Paint is when the biggest visible element (usually the hero image or headline block) finishes rendering. Google grades it per real-user visit: good under 2.5s, poor above 4s. Failing it costs rankings on competitive queries and shows up in Search Console’s Core Web Vitals report.

The causes, ranked by how often they are the cause

The hero image itself. Too large (a 4MB banner), wrongly encoded (PNG where WebP belongs), lazily loaded (lazy-loading your LCP image is self-sabotage: it is the one image that must NOT wait), or discovered late (buried in CSS backgrounds the browser cannot preload).

Slow server response upstream. When the HTML itself takes 1.8s (TTFB), nothing else can start: no image optimization rescues a slow origin. Cache layers, hosting tier, page complexity.

Render-blocking head. CSS and synchronised scripts delaying the first paint of everything, hero included.

CDN misses. Every visitor fetching the hero from one distant origin instead of an edge cache.

Fix order

Measure with real data first (Search Console CWV report, PageSpeed Insights field data - not lab scores alone). Preload the hero image explicitly, serve it in WebP/AVIF at exactly the rendered size, never lazy-load it, cache the page at the edge. Then attack TTFB. Retest with field data after a week; LCP moves with real traffic, not with lab optimism.

When to bring us in

A site-wide LCP failure is a build problem, not a settings tweak: we fix the critical path (hero delivery, cache architecture, render order) and verify with field data over weeks. That is a website performance engagement, scoped, with before/after numbers published in the quote.