Speculation Rules API: Instant Background Page Prerendering
- Last updated
- Prerequisites:
- Resource hints (preload/prefetch)
- Understanding of navigation and the back-forward cache
- browser
- speculation-rules
- prerender
- prefetch
- navigation
- performance
Read at your depth
The practical view
The Speculation Rules API lets you hint which future navigations should be prefetched or prerendered. Add a JSON block: <script type="speculationrules">{ "prerender": [{ "source": "list", "urls": ["/about", "/pricing"] }] }</script>. Prerendering fully renders the page in the background (including JS execution), so navigating to it is instant — the browser swaps the prepared page in. Prefetching only fetches the document and some resources. Rules can also use document rules ({ "source": "document", "where": { "href_matches": "/docs/*" } }). This is a modern alternative/replacement for the deprecated <link rel="prerender">.
The same idea in other frameworks
Next.js integrates speculation rules for prefetch/prerender of route targets.Angular SSR can emit speculation rules for likely-next routes.Nuxt's link prefetching aligns with speculation rules for instant navigation.SvelteKit's link hover prefetching is being superseded/augmented by speculation rules.Legacy vs modern
Link rel=prefetch/prerender (deprecated) vs speculation rules
The old rel=prefetch/prerender hints were per-element and prerender was removed; speculation rules batch JSON rules for prefetch and full prerender.
<link rel="prefetch" href="/about"> <!-- ❌ OLD: per-element, prefetch only -->
<link rel="prerender" href="/about"> <!-- ❌ OLD: deprecated/removed in most browsers --><script type="speculationrules">
{ "prerender": [{ "source": "list", "urls": ["/about", "/pricing"] }] }
</script> <!-- ✅ NEW -->Interview gotchas
Context
This tests the two-level speculation model — interviewers want the fetch-only vs full-render distinction and the practical UX difference on navigation.
The mechanical answer
Speculation prefetch fetches the document (and, in some cases, subresources) into the cache but does NOT execute it or render it — the navigation still runs the normal load pipeline when triggered, just faster because the bytes are cached. Speculation prerender fully renders the page in a hidden context: it runs HTML parsing, CSS, JavaScript, layout, and subresource loading in the background. When the user navigates to that URL, the browser activates the already-rendered document, so the page appears instantly — no parsing or JS execution on the critical path. The cost: prerender consumes real memory/CPU (a whole live page), so it should target likely-next navigations only, while prefetch is cheaper and safer for speculative candidates.
Trap
The naive answer is 'prerender is just a stronger prefetch'. It is a different mechanism (a live hidden page vs cached bytes). Another trap: assuming a prerendered page behaves identically to a normally-loaded one — restricted APIs are deferred until activation (document.prerendering is true during prerender), so pages must handle the prerendering state or they may misbehave. Candidates who explain the hidden-document lifecycle and activation swap show real understanding.
Context
This probes the safety model — interviewers want to know what a prerendered page cannot do (intrusive side effects) and how authors should code for the hidden state.
The mechanical answer
While prerendering, the page runs in a hidden document (document.prerendering === true) and must avoid intrusive behaviors: it cannot show notifications, play audio without a user gesture, prompt for permissions, or interact with the user, because the user hasn't navigated yet. Restricted APIs (e.g. notification.requestPermission, some storage/payment prompts, Web Locks in certain modes) are deferred or fail until activation. Pages that need to adjust behavior can listen for the prerenderingchange event to run activation-time work (e.g. start analytics, resume deferred rendering). The browser also enforces budgets (memory/CPU) and may evict prerendered pages under pressure. Authors must ensure analytics and side effects don't double-fire when a prerendered page activates.
Trap
The naive answer is 'prerendered pages are just invisible pages, no special rules'. Restricted APIs and the hidden state are real constraints. Another trap: analytics counting prerendered pages as real visits — prerender runs scripts, so analytics fire before activation unless guarded by document.prerendering. Candidates who mention the prerendering state flag and the activation event show real production knowledge.