Challenge 1: Diagnose Which Sub-Part Is Slow — Possible Solution ==================================================================== GIVEN: TTFB 0.3s, resource load delay 2.1s, resource load duration 0.4s, render delay 0.1s (total LCP ≈ 2.9s) THE REAL PROBLEM: Resource load delay (2.1s) ------------------------------------------------ Every other sub-part is fast on its own: TTFB at 0.3s is quick, resource load duration at 0.4s means the actual image download itself is not slow once it starts, and render delay at 0.1s means painting happens almost immediately once the resource is ready. The 2.1 seconds sitting in "resource load delay" — the gap between TTFB and the browser actually STARTING to fetch the LCP resource — is, by a wide margin, the largest single contributor to the total LCP time, and is disproportionate compared to every other sub-part combined. A CONCRETE FIX ---------------- This specific pattern (fast TTFB, fast download once started, but a long delay before the fetch even begins) is a classic sign that the browser doesn't discover the LCP resource early enough — often because it's referenced deep in a stylesheet (a CSS background-image) or only inserted by JavaScript after other scripts have executed, rather than being directly visible in the initial HTML the browser can parse immediately. The chapter's own fix for exactly this situation is to add a tag in the document's , which tells the browser to start fetching that specific resource immediately, in parallel with everything else, rather than waiting until the parser or JS execution happens to discover it later. WHY THIS WORKS AS AN ANSWER ------------------------------ The four-part breakdown exists precisely so a fix can be targeted at the ACTUAL bottleneck rather than guessing — trying to optimize TTFB further (e.g. moving to a faster CDN) here would barely move the total LCP time at all, since TTFB was never the problem. Reading the breakdown correctly points directly at "the browser isn't discovering this resource early enough," which is a load-DELAY problem, not a load-DURATION or server-response problem — and preload is specifically the tool built for closing that particular gap.