Comparisons

Pairs that get conflated in real conversations, and in real pull requests. Neither column wins — what decides is the requirement. Each record leads with the confusion, because the confusion is the reason the record exists.

Preload vs Prefetch

What people get wrong about this pair

They read as two settings of the same knob and they are opposites in priority and in intent. Preload competes with everything else on the current critical path: it says "this matters now", so a preload for something that was not on the critical path actively delays something that was. It is the hint people most often get wrong, and the browser will warn you when a preloaded resource is not used shortly after load. Prefetch is the opposite — deliberately idle-priority, for a navigation that may never happen, and its cost is bandwidth and data on a metered connection for a guess that was wrong. The related mistake is reaching for hints at all before checking whether the resource could simply have been discoverable earlier: a reference in the initial HTML is found by the preload scanner without any hint, and restructuring so the scanner can see it beats annotating a late discovery.

Preload — fetch a resource this navigation definitely needs, now, at high priority
Use it when

A late-discovered critical resource: a font the first screen needs, a hero image referenced from CSS, a script the parser will not see until it has run something else.

Prefetch — fetch a resource a *future* navigation will probably need, at the lowest priority
Use it when

The likely next route: the bundle and data for the page a user on this screen usually goes to next, warmed while the browser is idle.

DimensionPreload — fetch a resource this navigation definitely needs, now, at high priorityPrefetch — fetch a resource a *future* navigation will probably need, at the lowest priority
ForThis navigationA likely next navigation
PriorityHigh — competes with the critical pathLowest — deliberately idle
When it helpsA critical resource discovered late by the parserA predictable next step with idle bandwidth to spare
Cost of being wrongDelays something that was actually criticalWasted bytes, and data on a metered connection
Cached asUsed almost immediately by this pageSits in the HTTP cache for later — subject to its lifetime
Better alternative firstMake it discoverable in the initial HTMLSplit routes so the next one is small, or prefetch on intent (hover, focus)