Where preload accelerates what the current page needs right now, prefetch takes a fundamentally different, forward-looking approach — anticipating where the user is likely headed next and preparing for it at low, non-disruptive priority.
1Preparing For The Next Navigation, Not This Page
<link rel="prefetch" href="/next-page"> tells the browser that the user is likely to navigate to that URL soon, fetching and caching that page's resources ahead of time so that, if the navigation actually happens, it can feel instant — the resources are already available locally rather than requiring a fresh network round-trip at the moment of navigation.
This is a fundamentally different target from preload, which accelerates resources the *current* page needs right now. A classic, strong use case: a multi-step checkout flow, where step 1 can confidently prefetch step 2's resources, since the vast majority of users who begin checkout do proceed to the next step.
2Deliberately Low Priority, Idle-Time Only
Unlike preload's explicit high-priority request, prefetch is intentionally designed as a low-priority hint, fetched by the browser only when genuine spare network capacity exists — meaning it never competes with or delays resources the current page actually needs to render and function correctly right now.
This priority difference reflects the fundamentally different confidence level involved: the current page's own resources are needed with certainty, while a prefetched resource represents a probabilistic bet on future behavior that may or may not materialize.
3A Probabilistic Bet — Apply Selectively
Because prefetch consumes real bandwidth (even if only idle capacity) for something that might never actually be used, indiscriminately applying it to every link on a page — 'just in case' — wastes that bandwidth across the many navigation paths a user won't actually take, diluting whatever genuine benefit exists for the paths they will.
The most effective use targets genuinely high-confidence predictions: a linear, predictable flow's next step, a page's single dominant call-to-action link, or data-driven signals (like the most commonly clicked link from analytics) — not a blanket, speculative application across an entire page's links.
4Step-by-Step Breakdown
Betting On What The User Does Next. preload accelerates resources the current page needs right now, at high priority. prefetch does something entirely different: opportunistically, at low priority, fetching resources for a page the user hasn't navigated to yet but probably will next.
prefetch Targets Likely Future Navigation, Not The Current Page. <link rel="prefetch" href="/next-page"> tells the browser 'the user will likely navigate here soon' — commonly used for the next step in a checkout flow, or a page heavily linked from the current one, fetched in idle time for a potentially instant subsequent navigation.
prefetch's Target. What is <link rel="prefetch" href="/checkout/shipping"> actually preparing for?
- →A resource the current page needs immediately
- →A likely future navigation to a different page the user hasn't visited yet
- →Sending background analytics data
Fetched At Low Priority, During Idle Time. Unlike preload's explicit high-priority request, prefetch is deliberately low-priority, fetched only when the browser has genuine spare idle capacity — it never competes with or delays resources the current page actually needs right now.
prefetch's Priority Level. Does prefetch compete for bandwidth with resources the current page actually needs right now?
- →Yes, it requests the same high priority as current-page resources
- →No, it's deliberately low-priority and only uses genuine spare idle capacity
- →It's unpredictable and varies significantly by browser
A Probabilistic Bet, Not A Guarantee. Since prefetch is a bet on likely future navigation, it can be wasted bandwidth if the user doesn't actually navigate there — best applied to genuinely likely next steps (like a linear checkout flow) rather than speculatively to every link on a page.
The Probabilistic Nature Of prefetch. What's the risk of applying rel="prefetch" to every single link on a page speculatively?
- →None; there's no real downside to prefetching everything
- →Wasted bandwidth fetching resources for pages users likely won't actually visit
- →It reliably crashes the browser tab
prefetch Mastered. You now understand that prefetch anticipates likely future navigation rather than serving the current page, fetches at low priority using only idle capacity, and should be applied selectively to genuinely likely next steps rather than speculatively everywhere.
Prefetch A Likely Next Page. rel="prefetch" hints the browser to fetch a resource the user will probably need soon.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1prefetch Has No Direct Accessibility Impact But Contributes To Overall Perceived Performance For All Users
A faster-feeling subsequent navigation benefits every user, including those on assistive technology who may otherwise experience longer perceived delays between page transitions.
SEO Implications
- 1
prefetch Can Improve Perceived Navigation Speed Without Affecting The Current Page's Own Core Web Vitals
Because it's strictly low-priority and idle-time-only, it provides a genuine UX benefit for likely subsequent navigations without any risk of harming the current page's own LCP, INP, or CLS scores.
Best Practices
Reserve prefetch For Genuinely High-Confidence Predictions Of Likely Next Navigation
Linear flows (checkout, onboarding) and data-backed common paths offer real value; broad, speculative application across every link wastes bandwidth on low-probability navigations.
Never Confuse prefetch's Low-Priority, Next-Page Focus With preload's High-Priority, Current-Page Focus
Using the wrong one for a given need either fails to accelerate a genuinely critical current-page resource, or wastes high-priority bandwidth on a merely probable future need.
Frequent Bugs
A team uses preload for a next-likely-page resource, and it competes with and delays the current page's own critical rendering.
Switch to prefetch instead, which is specifically designed as a low-priority, non-competing hint for exactly this next-navigation use case.
A page prefetches every single link on it, and overall bandwidth usage increases without a corresponding meaningful navigation speed improvement.
Reduce prefetch usage to only genuinely high-confidence likely next steps, rather than applying it speculatively and broadly.
Real-World Examples
A Linear Checkout Flow Using prefetch
Each checkout step prefetching the next, since the vast majority of users proceed linearly through the flow.
<!-- On /checkout/cart -->
<link rel="prefetch" href="/checkout/shipping">
<!-- On /checkout/shipping -->
<link rel="prefetch" href="/checkout/payment">