In an HTML page's head, what is the difference between <link rel="preload"> and <link rel="prefetch">, and which navigation does each one serve?

## What a resource hint is A browser can only fetch what it has found. It finds most subresources by parsing HTML, and it finds the rest much later — after CSS has been parsed, after a script has run, after a component has decided it needs something. A **resource hint** is a `<link>` element (or an equivalent `Link:` HTTP response header) that tells the browser about that work ahead of time. `preload` and `prefetch` are the two hints that actually fetch bytes, and they sit at opposite ends of the urgency scale. ## rel="preload": this navigation, mandatory, high priority ```html <link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin> <link rel="preload" href="/hero.avif" as="image"> ``` A preload is an instruction, not a suggestion: the browser starts the request more or less immediately, and the `as` attribute tells it what kind of resource this is, which in turn sets the request's destination, its `Accept` header and its priority. The purpose is to move *discovery* earlier — never to make a download faster once it is already in flight. The crucial property is that preload **downloads and parks**. It does not execute or apply anything. A preloaded script is sitting in cache doing nothing until a `<script src>` with the same URL asks for it; a preloaded stylesheet is inert until a `<link rel="stylesheet">` applies it. If nothing consumes the resource shortly after load, Chrome logs a console warning that the resource "was preloaded using link preload but not used within a few seconds from the window's load event" — which in practice means you either wasted the bytes or fetched them twice. Good preload candidates share one trait: the browser would otherwise find them **late**. A font whose URL only appears inside a stylesheet, an LCP image referenced by a CSS `background-image`, a JSON payload the app fetches after boot. A resource already sitting as a plain `<img src>` or `<script src>` near the top of the HTML is a bad candidate, because the browser's preload scanner has already found it. ## rel="prefetch": the next navigation, speculative, lowest priority ```html <link rel="prefetch" href="/checkout.js" as="script"> ``` A prefetch says: *I think the user will go somewhere next, and this is what that page will need.* The browser treats it as the lowest-priority work on the page, typically running it once more urgent transfers are done, and stores the response in the HTTP cache subject to that response's own cache headers, so the next navigation can reuse it instead of going to the network. Because it is speculative, the browser is free to deprioritise, delay or skip it entirely — under memory pressure or on a constrained connection, for instance. Two caveats separate a prefetch that works from one that only looks good. First, the response has to be cacheable and still valid when the user clicks; a `no-store` response cannot be reused. Second, in browsers that partition the HTTP cache by top-level site, a cross-site prefetch may not be reusable in the destination's partition at all — so verify the next navigation actually records a cache hit rather than assuming it. ## The priority difference is the whole story Everything else follows from urgency. Preload competes with the resources the current page is rendering with, so it helps when the preloaded thing is genuinely on the critical path and hurts when it is not. Prefetch deliberately stays out of that competition, which is exactly why it is useless for the current page: by the time it downloads, the page has already rendered. ## The two classic mistakes - **Prefetching something the current page needs.** It arrives after everything else and shows up as no improvement at all, which is often misread as "hints don't work". - **Preloading next-page assets.** Now a route the user may never visit is stealing bandwidth from the hero image, and LCP gets worse. ## Rules that keep you out of trouble 1. Preload only late-discovered resources the **current** viewport needs, and make sure something on the page consumes each one. 2. Prefetch only high-confidence next steps, and measure the hit rate rather than trusting the prediction. 3. Remember that hints move discovery, not throughput. Bandwidth is finite; every hint you add takes some of it from something else. 4. Both can be delivered as `Link:` response headers when you cannot edit the HTML — the semantics are identical.