Prefetching Pages

Rule: prefetch one high-confidence next page after the current page is interactive. Use it when the click path is predictable; avoid it for logged-in, consent-gated, metered, or low-probability paths.

Start with 70%+ click confidence, fewer than 2 prefetched documents per view, and under 200 KB of extra mobile transfer. Keep it when users save 300-800 ms and unused prefetch bytes stay below 5% of session bandwidth.

What Prefetching Means

Prefetching means fetching a future resource before the user asks for it: an HTML document, route bundle, image, API response, or DNS lookup. Preload helps the current page; prefetch helps the likely next page. A prefetch should wait for idle network and CPU time.

<link rel="prefetch" href="/pricing" as="document">
<link rel="dns-prefetch" href="//cdn.example.com">

When to Use It and When to Avoid It

Use it for repeatable behavior: product page to pricing, cart to checkout, article to next article, or a route exposed by hover, tap, or viewport intent. Do not use it for weak intent, search results, account pages, state-changing checkout actions, private URLs, 2G, slow 3G, low battery, data saver mode, or pages with failing Core Web Vitals.

Prefetch Decision Matrix

Prefetch Budget

Treat prefetching like a budget, not a feature toggle:

• Documents: 1 primary document on page load intent; 2 only on high-confidence flows such as checkout.
• Bytes: under 200 KB extra transfer on mobile and under 500 KB on fast desktop connections.
• Timing: after interaction readiness, idle time, hover intent, or scroll depth; never before critical CSS and JavaScript.
• Stop rule: disable the hint when waste rate exceeds 50%, server requests rise more than 10%, or p75 transition time does not improve.

Implementation Process

1. Map the path. In GA4, server logs, or your analytics warehouse, find page pairs where at least 70% of users continue from page A to page B within the same session.
2. Pick the smallest useful resource. Start with the next HTML document or route bundle. Do not prefetch image galleries, video, or large API payloads on the first test.
3. Gate by conditions. Check navigator.connection, saveData, viewport intent, hover intent, and battery constraints where available. Default to off when the signal is missing.
4. Add the hint late. Inject the prefetch tag after the current page is interactive, ideally during idle time or after a user signal.
5. Verify the cache hit. Use Chrome DevTools, Lighthouse, PageSpeed Insights, or WebPageTest to confirm the resource appears as prefetched and is reused on click.
6. Measure the business result. Compare route transition time, conversion rate, revenue per session, bounce rate, and bandwidth per session before and after the change.

Browser and Platform Signals

Modern browsers may ignore or throttle hints, so prefetching must be progressive enhancement. Useful inputs:

• rel="dns-prefetch" for early DNS resolution.
• rel="preconnect" for meaningful third-party connection cost.
• rel="prefetch" for low-priority future resources.
• Framework route prefetching in Next.js, Nuxt, Astro, and similar systems.
• Service worker caching for explicit cache rules and offline behavior.

Evidence and Measurement

Use measured evidence, not intuition. Google's mobile research includes the 53% abandonment figure for pages taking longer than 3 seconds (Think with Google); that supports caring about speed, not prefetching every route.

Record a 7-14 day baseline when traffic allows. Compare median and p75 route transition time, prefetch hit rate, unused-byte waste rate, conversion rate, revenue per session, server requests, and CDN bandwidth.

Keep a test when hit rate is 50%+, extra bandwidth is below 5% per session, and transition time drops. If conversion does not move, keep the change only when experience improves and infrastructure cost stays low.

Risks and Failure Modes

• Bandwidth waste: The user never clicks, so bytes are spent without value.
• Server load: Aggressive hints can double document requests on high-traffic paths.
• Privacy leakage: Prefetching sensitive URLs can disclose intent before the user acts.
• Consent errors: Prefetching third-party scripts can fire requests before consent is granted.
• Stale content: Cached future pages can show old pricing, inventory, or availability.
• Current-page slowdown: Too many hints compete with the page the user is already viewing.

Mitigate these risks with caps, cache-control headers, consent checks, and rollback metrics. If the error budget is small, run an A/B test before full rollout.

Alternatives to Prefetching

Prefetching is not the first fix for a slow site. Use these options first when the current page is the problem:

Conclusion

Prefetching pages is useful when it is selective, measurable, and reversible. Start with one path where the next click is obvious, cap the extra bytes, confirm the cache hit, and keep it only if users experience faster transitions without meaningful bandwidth, privacy, or server-cost tradeoffs.