Distinguish preconnect, dns-prefetch, preload, prefetch, and fetchpriority. When does each help, and how can they hurt?
Precise understanding of each hint's effect on discovery/connection/priority and the cost of misuse.
These control WHEN and at WHAT PRIORITY the browser does network work, filling gaps the default discovery order leaves. `dns-prefetch` resolves a domain's DNS ahead of time — cheap, good for origins you'll likely use but not immediately. `preconnect` goes further: DNS + TCP + TLS handshake, so when the real request fires the connection is already warm — use for a few critical cross-origin origins (your image CDN, fonts host, API), but each open connection has cost so limit it to 2–4 and only ones you'll use very soon (an unused preconnect wastes a connection). `preload` (<link rel=preload as=...>) tells the browser to fetch a resource NOW at high priority that it would otherwise discover late — the classic use is a font (referenced from CSS, found late) or the LCP image or a critical script; you MUST set `as` correctly (and crossorigin for fonts) or the browser can't match it and may double-fetch. `prefetch` is the opposite intent: fetch at LOW priority something for a FUTURE navigation (the next likely route's chunk), stored for later — great for perceived-instant navigations, done during idle. `fetchpriority` (high/low/auto) tunes the relative priority of a resource the browser already knows about — e.g., fetchpriority="high" on the LCP <img> to jump it ahead of other images, or low on things that can wait. How they hurt: preload/preconnect are bandwidth and connection you spend UP FRONT, competing with genuinely critical resources — preloading too much (or the wrong thing) DELAYS your LCP by contending for the pipe; an unused preload is flagged by the browser as wasted; over-preconnecting opens idle connections. So the discipline is: hint only the few resources on the critical path, verify with DevTools' priority column and the 'preload not used' warnings, and prefer the native signals (fetchpriority on the hero image, defer on scripts) before scattering <link> hints. Think of it as a scalpel for the critical path, not a blanket 'load everything sooner'.
Shaving the critical path with the right hint; auditing hints that hurt by over-fetching.
<!-- Warm a connection you'll use very soon (limit to a few) -->
<link rel="preconnect" href="https://cdn.example" crossorigin>
<link rel="dns-prefetch" href="https://cdn.example"> <!-- cheaper, weaker -->
<!-- Fetch NOW at high priority something discovered late (font, LCP img) -->
<link rel="preload" as="font" type="font/woff2"
href="/fonts/inter.woff2" crossorigin>
<!-- Low-priority fetch for the NEXT navigation, during idle -->
<link rel="prefetch" href="/routes/settings.[hash].js">
<!-- Reprioritize a known resource -->
<img src="hero.avif" fetchpriority="high" width="1200" height="675" alt="…">
<img src="below.avif" fetchpriority="low" loading="lazy" alt="…">