Diagnosing LCP: The Four Sub-Parts

The plain-language idea

You already know LCP measures how long until the biggest visible element renders. What that single number doesn't tell you is why it's slow — and "make the hero image smaller" is a guess, not a diagnosis. Chrome's own tooling (the Performance panel, and the web-vitals library's attribution build) breaks LCP into four sequential sub-parts that always sum to the total:

• Time to First Byte (TTFB) — how long the server takes to respond to the very first navigation request. A slow backend, a cold serverless function, or a distant origin with no CDN all show up here.
• Resource Load Delay — the gap between TTFB and the browser actually starting to fetch the LCP resource (usually an image). This is pure waste: the browser was ready to fetch, but didn't know it needed to yet.
• Resource Load Time — how long the LCP resource itself takes to download once the fetch starts. A large, unoptimized, or poorly-compressed file shows up here.
• Render Delay — the gap between the resource finishing download and the browser actually painting it. Render-blocking CSS/JS or a busy main thread show up here.

Each sub-part points to a completely different fix. That's the entire diagnostic value: the largest sub-part tells you which category of problem you have, so you stop guessing.

See it in a real thing: a hero image discovered late

// Slow: the browser can't discover this image until JS runs and mounts it
function Hero() {
  const [src, setSrc] = useState(null);
  useEffect(() => {
    fetchHeroImageUrl().then(setSrc);
  }, []);
  return src ? <img src={src} alt="" /> : null;
}

LCP is one number, but it's really four sub-parts laid end to end on a timeline.

BackNext

This component has a near-zero TTFB and a fast Resource Load Time once the fetch starts — but a large Resource Load Delay, because the browser's preload scanner (the fast HTML parser that looks ahead for images and scripts before the main JS even runs) has nothing to find. The <img> tag doesn't exist in the initial HTML at all; it only shows up after React mounts, which only happens after JS downloads, parses, and executes. The fix isn't "optimize the image" — the image was never the bottleneck. It's making the resource discoverable earlier: render the <img src> directly in the initial HTML (or add a <link rel="preload" as="image"> hint) so the preload scanner finds it on the very first pass, and add fetchpriority="high" so the browser fetches it ahead of lower-priority resources.

What people usually miss

Watch out

• A slow LCP with a fast TTFB and fast download is still a real bug — it just isn't a server or network problem. Teams often stop investigating once TTFB looks fine, missing Resource Load Delay or Render Delay entirely.
• Render Delay isn't about the image at all. It's about everything else competing for the main thread and the render pipeline at that moment — render-blocking <script> tags without defer/async, synchronous CSS, or a long JavaScript task that's holding the thread when the image is ready to paint.
• Loading the LCP resource via JavaScript (fetch-then-set-state) almost always adds Resource Load Delay, because it moves discovery from "the HTML parser finds it instantly" to "wait for JS to download, parse, execute, and run an effect."
• The four sub-parts are sequential and additive — fixing the largest one first gives the biggest win, but a page can have real, separate problems in more than one sub-part at once.

Why this matters in interviews

"LCP is slow — how do you find out why?" is a common senior-frontend question, and naming the four sub-parts (rather than listing generic fixes like "compress images") is exactly the difference between a candidate who's memorized advice and one who can actually diagnose a real page.