Prerender vs Prefetch: Cost Trade-Offs

This guide is part of Speculative Loading & Prefetching, within Network & Server Response Optimization. Prefetch and prerender sit at different points on a cost-benefit curve. Prefetching a document downloads its HTML ahead of time: one request, little bandwidth, no script execution. When the user navigates, TTFB disappears, but the page still has to load its subresources and render. Prerendering loads and renders the whole page in the background: all resources, all scripts, full layout. When the user navigates, the page appears almost instantly — but if they never navigate there, all that work was wasted, on the server and on the user's device.

The right choice depends on three factors: how likely the navigation is, how expensive the page is to load, and whether the page has side effects that make speculative execution unsafe. This guide gives a framework for deciding per link pattern and a method for tuning with real hit-rate data.

Rapid Diagnosis

• Check navigation probabilities from analytics for each link pattern.
• Check page weight: bytes and main-thread time of target pages.
• Check server cost: whether target pages are cached at the CDN.
• Check side effects: anything that should only happen when a user really visits.

Root Cause Analysis: Where Speculation Goes Wrong

1. Prerendering low-probability links. Most prerenders wasted.

2. Prerendering heavy pages. Large CPU and memory costs on devices for uncertain benefit.

3. Prefetching uncached, expensive pages. Server load without CDN protection.

4. Ignoring side effects. Analytics, ad impressions, or state changes on unvisited pages.

Step-by-Step Resolution

1. Estimate expected value per pattern

For each link pattern, estimate the probability of navigation given the trigger (hover, visibility), the time saved (TTFB for prefetch; full LCP for prerender), and the cost if unused (bytes, server work, device CPU).

// Rough expected-value comparison per link pattern.
function speculationScore({ pClick, ttfbMs, lcpMs, pageKB, serverCostMs }) {
  const prefetch = pClick * ttfbMs - (1 - pClick) * (serverCostMs * 0.1);
  const prerender = pClick * lcpMs - (1 - pClick) * (pageKB * 0.5 + serverCostMs * 0.1);
  return { prefetch: Math.round(prefetch), prerender: Math.round(prerender) };
}
speculationScore({ pClick: 0.6, ttfbMs: 400, lcpMs: 1800, pageKB: 900, serverCostMs: 150 });
// trade-off: the weights are judgement calls (how much a wasted KB "costs");
// use them to rank patterns, not as precise economics.

2. Map patterns to actions

High probability and moderate weight → prerender (moderate eagerness). Medium probability → prefetch (moderate or conservative). Low probability or heavy pages → conservative prefetch or none. Side-effecting pages → never prerender.

3. Protect the server

Cache prefetched HTML at the CDN, and identify speculative requests by Sec-Purpose so they can be served from cache or shed under load.

4. Measure hit rates and adjust

Log speculation starts (server-side via Sec-Purpose) and activations (client-side via activationStart). Adjust eagerness and patterns where hit rates are low.

Verification

Track per pattern: speculations started, activations, hit rate, and LCP for activated navigations versus non-speculated ones. Track server requests with Sec-Purpose and their cache hit ratio. Check device-side impact in lab tests: prerendering heavy pages on low-end devices should not degrade the current page's INP.

Worked Example: An E-commerce Category Page

An e-commerce site prerendered every product link on category pages at moderate eagerness. Hit rate was 34%: users hovered over many products while browsing. Product pages were heavy (1.4MB, 600ms of main-thread work), and on mid-range Android devices, INP on category pages worsened by 40ms during browsing because of background prerenders. The team switched product links to conservative prerender (on pointer down) plus moderate prefetch, and kept moderate prerender only for "next page" pagination links (78% hit rate). Product navigation LCP was still much improved (prefetch removed TTFB; conservative prerender gave 100–200ms of lead time), category page INP returned to baseline, and wasted product prerenders fell by 80%.

Prefetching Subresources

Document prefetch saves TTFB; the page's subresources still load after navigation. If the next page shares most assets with the current one (same CSS and JS bundles), they are already cached and the remaining cost is mainly images. For pages with different bundles, <link rel="prefetch"> for key route chunks (or framework route prefetching) can warm the cache for subresources too. Prerender handles all of this automatically, at higher cost.

Tuning With Real Data

Expected-value estimates are a starting point; real hit rates settle the question. Log each speculation start server-side (the Sec-Purpose header identifies prefetch and prerender requests) with the link pattern, and log activations client-side with the same pattern. A weekly report per pattern — starts, activations, hit rate, LCP saved — shows where to raise or lower eagerness. Patterns with prerender hit rates under about 30% are candidates for downgrading to prefetch; prefetch patterns with very high hit rates are candidates for upgrading to prerender. Revisit the report after major design changes, since link placement shifts click patterns.

Common Mistakes

• Prerendering everything at moderate eagerness on link-dense pages. Many wasted prerenders.
• Ignoring device cost. Background prerenders compete with the current page on low-end devices.
• Prefetching uncached dynamic pages. Server load without benefit when hit rates are low.
• No per-pattern measurement. One overall hit rate hides the bad patterns.

Edge Cases

Pagination. "Next page" links have high click probability and light pages — ideal prerender candidates.

Search results. The first result has high probability; prerender it immediately, prefetch the rest on hover.

Logged-in dashboards. Prerendering can show stale state; prefer prefetch.

Large media pages. Prerendering pages with autoplay video wastes bandwidth; video should wait for activation.

FAQ

Related

• Speculation rules for instant navigations — writing the rules.
• Viewport prefetching with Quicklink — idle-time prefetching.
• Caching API responses at the CDN — protecting the server from speculative load.