A team added fourteen <link rel="preload"> tags to a page's head so that "everything arrives sooner", and the page's Largest Contentful Paint got worse. Explain how over-preloading slows a page down, and how you would decide which preloads to keep.

## Preload reorders; it does not add capacity The belief behind fourteen preloads is that hints make things faster. They do not. A hint changes **when** the browser learns about a resource and **what priority** the request gets. The pipe is the same size it was, and on a mobile connection it is a small pipe. Over HTTP/2 and HTTP/3 all those requests are multiplexed over a single connection and share its bandwidth, so starting fourteen transfers early does not make fourteen things arrive early — it makes all of them, including the LCP image, arrive later than if the browser had been left to sequence them by its own priority model. That is the core mechanism, and it is why over-hinting shows up as a *regression* rather than a wash. ## The three ways the fourteen tags hurt **1. They compete with the critical path.** A preload declared `as="style"` or `as="font"` is treated as urgent. Fourteen urgent requests, issued before the parser has even reached the body, contend with the render-blocking stylesheet and the hero image. Bytes spent on a route chunk are bytes not spent on the pixels the LCP measurement is waiting for. **2. Most of them buy no discovery.** The browser's preload scanner reads ahead through the raw HTML and starts fetching `<img src>`, `<script src>` and `<link rel="stylesheet">` before the parser gets there. A preload for something already visible in the markup near the top of the document adds a request the browser was about to make anyway — pure contention, zero discovery. The hint only earns its place when the resource's URL is *not* in the HTML. **3. Some fetch things the page does not need.** Below-the-fold images, a modal's assets, another route's chunk. These are the most damaging, because the bandwidth is not merely reordered — it is spent on something that contributes nothing to the current view. A fourth, quieter cost: unused preloads. Any hint whose consumer never appears produces a console warning that the resource was preloaded but not used, and in the mismatch cases (missing `crossorigin`, wrong `as`, an image the layout resolves differently) the file is fetched twice. ## The keep/drop test A preload has to pass **both** halves of one question: > Does the current viewport need this resource, *and* would the browser otherwise find it late? - **Needed and found late — keep.** An LCP image referenced only by a CSS `background-image`. A font whose URL appears inside the stylesheet. A JSON payload the app requests after boot. In each case the resource sits behind at least one other download, and the hint removes a round trip from the critical chain. - **Needed but found early — drop.** An `<img>` at the top of the body. A stylesheet already linked in the head. The scanner has it. - **Found late but not needed yet — drop.** The route the user might click next; this is prefetch's job, at idle priority, not preload's. - **Neither — drop, obviously.** Fourteen tags almost never survive this. A page with a handful of genuinely late-discovered critical resources is normal; a page with fourteen of them usually has a structural problem worth fixing instead — the critical assets are buried too deep, or the first screen depends on far too much. ## How to verify rather than argue Reasoning about priorities is how teams end up with fourteen preloads in the first place. Measure: 1. **Read the waterfall for the LCP resource specifically.** When was it requested, when did it finish, and what else was in flight during that window? If the answer is "nine other things", you have found your contention. 2. **Remove and compare.** Strip the hints, re-measure under identical conditions, then add back only the candidates that pass the test above, one group at a time. Lab runs vary, so compare repeated runs rather than single numbers. 3. **Confirm in the field.** Local conditions flatter you: a fast connection hides bandwidth contention almost completely, which is exactly why over-preloading survives code review and then shows up in real-user LCP. The regression lives at the slow end of the distribution. 4. **Watch the console.** Unused-preload warnings and duplicated URLs in the waterfall are free evidence that specific tags are pure cost. ## Keeping it from coming back Hints are side effects with no compile-time consumer, so nothing breaks when they go stale — which means they accumulate. Generate them from the build manifest where you can, keep a short written rule for what qualifies, and treat every new preload in review as a claim that needs the same two-part justification: needed now, and otherwise discovered late.