LCP: four phases, one dominant cost

A team adds a CDN, compresses the hero image, and LCP barely moves. The problem was never the image size — the browser was discovering the image late, after a JavaScript bundle ran. The fix was one HTML attribute. LCP fails in four different ways, and only one fix works per phase.

What LCP measures and when it fires.

Largest Contentful Paint is the render time of the largest content element visible in the viewport during load. “Content” is a specific list: <img>, the poster of a <video>, a background image loaded via url(), and block-level elements containing text. The browser watches as elements paint, keeps updating its candidate for “largest”, and finalises the LCP value at the first user interaction (because once the user is interacting, further “loading” is not load anymore). On most pages the LCP element is the hero image or the main headline — the thing the user perceives as “the page has loaded.”

The four phases.

LCP time is the sum of four sequential sub-parts. The fix is different for each.

1. TTFB — time to the first byte from the server. Causes: slow SSR data fetch, no CDN, slow database query on the render path. Fix: cache, CDN, move slow data off the render path (streaming SSR with a Suspense boundary).

2. Resource load delay — the gap between TTFB and the browser starting to load the LCP image. Cause: the browser discovers the image late because it is referenced only in CSS or injected by JavaScript, not in the initial HTML — the preload scanner cannot find it. Fix: put the LCP image in the initial HTML as a plain <img> with fetchpriority="high" or a <link rel="preload">.

3. Resource load time — how long the LCP image itself takes to download. Cause: oversized file, wrong format, not compressed. Fix: correct format (AVIF, WebP), correctly sized for the viewport via srcset, compressed.

4. Element render delay — the gap between the image finishing download and it actually painting. Cause: render-blocking CSS or JavaScript still occupying the main thread after the image is ready. Fix: inline critical CSS, defer non-critical scripts.

The preload scanner — why discovery is everything.

Browsers run a secondary parser called the preload scanner that races ahead of the main HTML parser looking for resources to fetch, even while the main parser is blocked on a script. The preload scanner is why an <img> in the initial HTML loads early: the scanner sees it and kicks off the fetch immediately. It is also why an image referenced only in CSS (background-image) or injected by JavaScript loads late: the scanner cannot see it — the image is not discovered until the CSS is parsed or the JS runs.

This is the deep reason “put the LCP image in the HTML” works: it is the only place the preload scanner can find it without waiting. fetchpriority="high" then tells the browser to raise that fetch above other early resources; <link rel="preload"> is the heavier hammer for resources the scanner still cannot reach.

The most common self-inflicted LCP regression.

Adding loading="lazy" to the hero image. Lazy loading exists to defer images that are below the fold — images the user has not scrolled to yet. Applying it to the hero tells the browser to delay loading exactly the image the LCP metric is timing. The result is almost always a large resource load delay that did not exist before. Never lazy-load the LCP element.