The Browser Can Arrive Before the User: Rolling Out Speculation Rules Safely
Prefetch and prerender can make navigation dramatically faster — but they can also trigger analytics, cart state, login logic, and server work too early. Here is how to audit the rollout.
A user moves the pointer toward “Details,” clicks — and the next page appears almost instantly. That is the promise of Speculation Rules: the browser can prefetch or even fully prerender likely future documents.
The performance benefit can be substantial. The hidden catch is that a prerendered page can already execute JavaScript, fetch data, change client-side storage, and trigger requests before the user has actually seen it.
That turns a speed optimisation into an application-logic question. If pageviews, cart actions, authentication state, or expensive backend queries are tied to “the page loaded,” the browser can start doing work before a real navigation happens.
Why this deserves a closer look in 2026
Chrome has continued to evolve its eagerness heuristics. eager no longer behaves like immediate: on desktop, Chrome 143 changed it to speculate after a very short hover, while mobile has used viewport-based heuristics since January 2026. moderate and conservative wait for stronger signals of user intent.
At the same time, MDN still marks the Speculation Rules API as not Baseline with limited cross-browser availability. Treat it as progressive enhancement: when a browser does not speculate, ordinary navigation still needs to work correctly.
The useful question is not “Which pages can we prerender?” It is “Which navigations are cheap, safe, and likely enough to move forward in time?”
Prefetch and prerender are not the same thing
With prefetch, a future document is fetched early and kept ready for a later navigation. It is generally the lower-risk starting point, but it still consumes network resources and can create backend requests. Chrome explicitly recommends starting with prefetch for more complex sites.
Prerender goes much further. The browser loads the document and its resources and begins executing the page in a hidden state. JavaScript can run and additional requests can start. A prerendered page is therefore not merely an aggressive cache. It is closer to a not-yet-visible instance of the next page.
Red flag 1: A GET request changes state
If links such as /logout, /add-to-cart?id=42, /accept-invite, or /delete?item=7 change state as soon as they are requested, speculative loading can trigger the action without an intentional click.
Chrome explicitly calls out these cases when explaining URLs that should be excluded from speculation. The deeper fix is architectural: state-changing operations should not be disguised as harmless GET navigation.
Before rollout, inventory:
- Which GET routes modify data or sessions?
- Do query parameters trigger server-side actions?
- Do downloads, exports, or document-generation jobs start on page load?
- Do logout, invite, or admin links mix navigation with mutation?
A performance review can reveal an HTTP design problem at the same time.
Red flag 2: Analytics counts pages nobody saw
Many analytics implementations send a pageview when a page initialises. During prerendering, “initialised” is not the same as “viewed.”
MDN warns that JavaScript during prerender can cause analytics events, ad impressions, or other application side effects. The platform provides document.prerendering, prerenderingchange, and PerformanceNavigationTiming.activationStart to distinguish these states.
A safe rollout therefore asks:
- Are pageviews sent only after real activation?
- Are conversion or impression events firing too early?
- Do third-party SDKs understand prerendering?
- Can incompatible scripts be delayed until activation?
Otherwise the site improves navigation speed while degrading the data used to make product decisions.
Red flag 3: The instant state is already stale
Imagine that an account page is prerendered while the user is signed out. The user signs in in a second tab and then opens the already prepared page. Or a basket is prerendered before another item is added on the current page.
Without revalidation, the instant page may show the wrong state. MDN describes this risk for user-specific and fast-changing server-rendered state.
Possible controls include:
- selectively revalidate critical data on
prerenderingchange, - propagate login, logout, and basket changes across tabs,
- invalidate speculative entries after relevant state changes,
- where appropriate use
Clear-Site-DatawithprefetchCacheandprerenderCache, - avoid prerendering sensitive pages or wait for stronger user intent.
Red flag 4: The “fast” page doubles infrastructure work
A prerender can load resources in full even when the user never navigates there. For a static CDN page, that may be cheap. For dashboards, search results, reports, or personalised views, it can create database work, API calls, and rendering cost.
Chrome warns about over-speculation because it consumes bandwidth, memory, and CPU for users and can also consume site resources. Candidate pages therefore need a cost classification as well as a probability score.
Static content and cached detail pages are often inexpensive. Personalised dashboards, complex searches, and generated reports are more expensive. Endpoints with side effects should not be speculated at all.
Eagerness is a product decision
conservative waits for pointer or touch down. moderate responds to clearer interest such as a longer hover. eager speculates earlier, with Chrome's recent heuristic changes. immediate starts as soon as the browser observes the rule.
The earlier the speculation, the better the chance of a near-instant navigation — and the greater the probability of wasted work. A staged business-site rollout is therefore often safer:
- Prefetch likely, inexpensive destinations.
- Prerender only a small set of safe destinations.
- Start with
conservativeormoderate. - Become more aggressive only after measuring real activation and waste.
An allowlist is easier to control
For shops, SaaS products, and portals, a small positive selection is generally easier to maintain than “every internal link except…”.
Good candidates include editorial articles, service pages, static product information, and common next views without personalised state. Poor candidates include logout, checkout stages, cart mutations, role changes, exports, admin actions, and expensive search results.
That avoids adding another exclusion rule every time the product gains a feature.
CSP can silently break the rollout
Sites with a strict Content Security Policy need to review Speculation Rules explicitly. Inline rules using script type="speculationrules" are subject to CSP requirements. MDN documents options including 'inline-speculation-rules', nonces, and hashes. Rules can also be referenced through the Speculation-Rules response header as external JSON resources.
A classic failure is that a rule works locally without a strict CSP but is blocked in production. Inspect the headers actually delivered and the browser console, not only the source template.
How to test a safe rollout
A useful test is not one Lighthouse run. It connects performance with business behaviour.
Phase 1: Inventory candidate destinations by navigation probability, cacheability, backend cost, side effects, third parties, analytics, session state, and consent dependencies.
Phase 2: Start with a small number of prefetch targets and monitor hit rate, additional requests, transfer size, origin/API load, and errors.
Phase 3: Move only low-risk destinations to prerender and deliberately test sign-in/sign-out across tabs, basket changes, consent changes, dynamic prices, widgets, forms, and real-time data.
Phase 4: Instrument activation. Use document.prerendering, prerenderingchange, and activationStart to distinguish normal loads, documents currently prerendering, and navigations activated from prerender.
Only then can the team decide whether the speed gained is worth the speculative work performed.
What Website-Pflichtencheck would inspect
A Speculation Rules and prerender audit can examine current rules and eagerness, GET routes with hidden mutations, logout/cart/checkout paths, analytics and conversion events, personalised state, login and consent changes across tabs, third-party scripts, server/API/CDN cost, CSP compatibility, invalidation after state changes, speculation hit rate, and fallback behaviour in other browsers.
The goal is not to load as many pages in advance as possible. It is to prepare the right next page as early as useful without performing an action the user has not actually taken yet.
Speculative loading can then be a powerful performance technique. Without a state and measurement model, it can also become a very fast way to execute the wrong thing at the wrong time.