Speculative Loading Is Now Configurable by Environment

Prerendering is the rare optimisation that a visitor perceives directly: a click that produces a page with no perceptible wait, because the work was done before the click. It is also the rare optimisation that can cost you money by doing work nobody asked for, or corrupt a report by counting a page view that never happened. WordPress 7.1, released 19 August 2026, made the control over that trade-off an environment-level setting.

Prefetch and prerender are not the same promise

The Speculation Rules API offers two levels, and Chrome’s documentation on prerendering pages draws the line. Prefetched documents are processed the way a navigation would be but not rendered, and are held in memory so they are available to the browser more quickly when needed. Prerendering goes further and renders the page in a hidden background state, so activation is close to instantaneous.

The cost profile differs accordingly. A prefetch spends bandwidth and a server response. A prerender spends bandwidth, a server response, and the memory and CPU of a fully rendered page that may never be shown. On a site where a visitor’s next click is genuinely predictable, prerendering is the strongest perceived-performance change available. On a site where it is not, it is a multiplier on server load.

Why environment-level configuration was the missing piece

The 7.1 release announcement states that speculative loading defaults can now be set through environment variables or constants, so hosts and site owners can configure how WordPress prefetches pages without writing a plugin. The practical problem that solves is the staging environment.

A team running staging and production from one codebase previously had one setting for both. Prerendering on a staging box means a crawler, a QA session or a single developer hovering over a menu generates real requests against an environment sized for none of it, and any analytics or logging attached to that environment records page views that correspond to nobody’s attention. Moving the default into an environment variable means production can be aggressive and staging can be off, with no branch and no conditional in the theme.

Choosing an eagerness setting

Chrome documents four eagerness levels, and the differences are concrete rather than descriptive:

• immediate — speculates as soon as the rules are observed. Maximum coverage, maximum waste.
• eager — on desktop, triggers after roughly 10 milliseconds of pointer hover; on mobile, uses simple viewport heuristics, around 50 milliseconds after an anchor enters the viewport.
• moderate — on desktop, triggers after about 200 milliseconds of hover or on pointer down; on mobile, uses more complex viewport heuristics, around 500 milliseconds after scrolling stops.
• conservative — speculates on pointer or touch down, which is the last possible moment that still buys anything.

Mobile is the reason to be careful. Hover does not exist there, so the eager and moderate settings fall back to viewport heuristics, which on a long archive page can mean speculating on a great many links that scroll past without being read. A content site with a high pages-per-session figure can justify moderate. A store with a large catalogue and low navigation depth usually cannot.

What to exclude, always

Anything with a side effect must be excluded, without exception. Add-to-cart URLs, checkout steps, logout links, one-time action links, and any endpoint that mutates state on a GET request. A prerendered logout link logs the user out; a prerendered cart action adds the product. Chrome’s documentation notes that a number of APIs causing intrusive behaviours are not activated in the prerendered state and are delayed until activation, but that protection covers browser-level intrusions like prompts, not your application’s own side effects.

Checkout deserves separate thought for a second reason. A prerendered checkout page executes its payment-gateway scripts in the background, which is both wasted work and a source of interaction cost later. Stores whose problem is already where checkout flows fail INP should not add speculative execution of the same scripts on top of it.

Verify it rather than trust the setting

A setting that is enabled and not working looks identical to a setting that is working, because the whole point is that nothing appears to happen. Check it directly. View source and confirm a speculation rules script is present with the configuration you expect. In Chrome’s developer tools, the speculative loads panel lists what was speculated, whether it succeeded and why it failed when it did not — a header that disallows prerendering, a rule that matched nothing, a cross-origin destination. Watch the server’s request log while browsing a template as an ordinary visitor and confirm the volume of speculative requests is what you intended.

Then re-measure. Speculative loading improves perceived navigation speed; it does not improve the first page load, and it does not repair a slow server response — it just spends that response earlier. The same caveat that applies to caching plugins and Core Web Vitals applies here, and the underlying costs it hides are the ones catalogued in where WordPress sites lose speed.