WordPress Speculative Loading: What It Does and How to Configure It

Ever clicked a link and the next page just… appeared? No spinner, no white flash, nothing. That little moment of magic is increasingly not magic at all. It’s speculative loading, and since WordPress 6.8 it’s been running quietly on millions of WordPress sites by default.

The short version: your site can now tell the browser which page a visitor is likely to open next, and the browser starts loading it before the click happens. If the visitor follows through, the page is already waiting. If not, not much harm done. That speculative request may waste some bandwidth and server work.

This guide walks through what speculative loading is, why prerendered pages feel instant, and what WordPress 6.8 turned on by default. Then it gets practical: checking your site, configuring the official plugin, and the honest part most announcements skip: what can break, starting with your analytics.

Let’s jump right in!

What is speculative loading, exactly?

Speculative loading is a performance technique where the browser loads a page before the user asks for it, based on signals that a navigation is coming. The technology behind it is the Speculation Rules API, a browser feature that lets a site declare, in a small block of JSON, which URLs the browser should prepare and how early it should start.

The API offers two flavors of “prepare”:

Prefetch downloads the page’s HTML in the background, so when the user clicks, the browser skips the network wait and starts rendering immediately.
Prerender goes much further: the browser fully renders the page in a hidden, tab-like context, styles, images, and JavaScript included. When the user clicks, the prerendered page is “activated” and swapped into view essentially instantly.

If you’ve seen older WordPress plugins that inject <link rel="prefetch"> tags on hover, this is the grown-up, browser-native successor to that idea: the rules live in the page itself, and the browser decides when to act on them.

Why a prerendered page feels instant ⚡

Chrome’s own documentation describes a prerender as opening the page in an invisible background tab. All the expensive work (downloading assets, parsing HTML, running scripts) happens while the user is still reading the current page or hovering over a link. The click itself then does almost nothing: the hidden page moves to the foreground, fully formed.

The effect on Core Web Vitals is direct: Largest Contentful Paint (the time until the main content appears) drops close to zero because the painting already happened, layout shifts occur before anyone sees the page, and interactions feel snappy because scripts finished before the user touches anything.

One honest clarification: speculative loading doesn’t make your server faster or your pages lighter. The same work still happens, just earlier, during time the browser would otherwise spend idle. And if the user never clicks, the prefetch or prerender was wasted bandwidth and a real server request that served nobody.

According to the WordPress core team’s dev note for the 6.8 release, sites running the feature improved their LCP passing rate by roughly 1.9% at the median (HTTP Archive and Chrome User Experience Report data, 50,000+ sites), and over 8% of all Chrome navigations already relied on speculation rules. No miracle numbers, but a measurable, web-wide nudge for a feature that’s free to turn on.

Browser support: who benefits and who doesn’t

Here’s the part marketing pages gloss over: the Speculation Rules API is a Chromium feature. It works in Chrome, Edge, and Opera (version 121 and above, per the official plugin’s documentation). Safari and Firefox don’t support it yet, so their users get the classic, non-speculative experience.

Even inside Chrome, speculation isn’t guaranteed. The browser deliberately skips prefetching and prerendering when it would be a bad idea, including when:

The user has Save-Data enabled, battery saver running on a low battery, or a device low on memory.
The “Preload pages” setting is turned off (some privacy extensions, like uBlock Origin, turn it off for you).
The page is open in a background tab.

What WordPress 6.8 gives you out of the box

WordPress 6.8 (“Cecil,” released in April 2025) merged the WordPress Performance Team’s Speculative Loading feature directly into core. If your site runs 6.8 or newer, speculative loading is very likely already active. No setting, no checkbox: it just showed up one update.

The core defaults are deliberately cautious:

Mode: prefetch. WordPress downloads the next page’s HTML ahead of time, but doesn’t prerender it.
Eagerness: conservative. The prefetch fires when the user starts pressing down on a link, typically a fraction of a second before the navigation. That’s a short head start, but it almost never wastes a request.
Frontend only, logged-out visitors only. Admin screens and logged-in sessions are always excluded.
Pretty permalinks required. If your site uses plain ?p=123 permalinks, the feature stays off, because URLs with query parameters can’t be reliably distinguished from “action URLs” that change things when visited.

Core also excludes risky URLs automatically: anything under /wp-admin/, the login page, links containing a _wpnonce security token, and nofollow links. For per-block control, the editor’s Advanced panel accepts two CSS classes: no-prefetch opts a block’s links out of everything, no-prerender out of prerendering only.

ℹ️ NOTE: The logged-in exclusion matters more than it sounds: on membership sites, forums, and stores where most frontend traffic is signed in, core’s speculative loading does nothing by default. The plugin (next section) can opt logged-in users in, though it warns you should have persistent object caching first.

How to configure speculative loading in WordPress

Step 1: Check whether it’s already running (it probably is)

Open any frontend page of your site in Chrome while logged out (an incognito window works), view the page source, and search for speculationrules. If you find a JSON block mentioning prefetch and conservative, WordPress core is already doing its thing.

For a live view, the Speculative loads section in Chrome DevTools’ Application panel shows which URLs are being speculated on and why a speculation succeeded or was canceled.

💡 PRO TIP: Keep that panel open and hover over a few internal links: with core’s conservative default the prefetch appears as you press the mouse button, while the plugin’s prerender mode fires on hover.

Step 2: Install the Speculative Loading plugin for full control

Core’s defaults are safe but modest. For a settings screen and the much stronger prerender mode, install the official Speculative Loading plugin from the WordPress Performance Team (formerly “Speculation Rules”; the core merge was based on it).

In your dashboard, go to Plugins → Add New, search for “Speculative Loading,” and install and activate the plugin by the WordPress Performance Team.

Step 3: Choose your mode, eagerness, and audience

Head to Settings → Reading and scroll to the Speculative Loading section. It offers three radio groups: Speculation Mode (prefetch or prerender), Eagerness (how early the browser acts), and User Authentication Status (who gets speculative loading at all). The plugin defaults to prerender with moderate eagerness for logged-out visitors, a clear step up from core’s prefetch-only approach:

Eagerness is the knob that trades speed against waste:

Eagerness	When it fires	Good for
Conservative	On pointer or touch down (the click has basically started)	Busy servers, heavy pages, minimal waste ✅
Moderate	After hovering a link for about 200 milliseconds on desktop	Most sites; the sweet spot between lead time and accuracy
Eager	After roughly 10 milliseconds of hover (desktop)	Lightweight, static pages where extra requests are cheap

Chrome caps concurrent speculations at two for the interaction-based eagerness levels, so a link-heavy page won’t spawn dozens of prerenders. If your pages are heavy or your hosting metered, start conservative and watch your server logs before going more aggressive.

Step 4: Exclude URLs that should never prerender

Most WordPress pages are safe to prerender, but think about links whose visit changes something: custom logout links, “mark as favorite” URLs, vote counters. WordPress already excludes query-parameter URLs, nofollow links, and nonce-protected links, which covers the usual suspects. For anything else, you have three tools:

The no-prerender CSS class on a link or block (prerendering skips it, prefetching still allowed).
The wp_speculation_rules_href_exclude_paths filter in core, which excludes whole path patterns like /cart/* from speculation.
The wp_speculation_rules_configuration filter, which sets the global mode and eagerness in code instead of installing the plugin (prerender with moderate eagerness mirrors the plugin’s default).

When in doubt, prefer excluding from prerender only. Prefetching a slightly-dynamic page is usually harmless; running its JavaScript in a hidden tab might not be.

What can break (and what won’t)

Analytics are the big one. A prerendered page executes its JavaScript before anyone sees it, and if the user never clicks, that visit never happened. A naive tracking setup can count a pageview anyway, or count it twice: once on prerender, once on activation. Google Analytics and most popular providers detect prerendering and hold their pageview beacons until the page is actually activated, so for most sites this is a non-issue. If you run custom tracking code, make sure it checks document.prerendering and waits for the prerenderingchange event before firing.

Personalization deserves a test. A prerendered page reflects the state of things when the speculation started: a cart change or logout elsewhere won’t be reflected in it. Most such flows trigger a fresh navigation anyway, but if your site personalizes heavily, test the important journeys.

Your server does more work. Every prefetch and prerender is a real request hitting your stack. For cached, anonymous pages that’s cheap (why core limits the feature to logged-out traffic). On dynamic, uncached pages with an eager setting, you’re multiplying requests for visits that may never complete. Watch bandwidth and PHP worker usage for a week after switching modes.

And what won’t break: Safari and Firefox visitors, users with ad blockers or data-saver modes, and logged-in members. The failure mode here is “nothing happens,” not “something explodes.” 🙌

Final thoughts 🏁

Speculative loading is one of the rare performance features that’s both meaningful and nearly free to adopt:

WordPress 6.8+ already prefetches internal links for logged-out visitors, conservatively, with zero configuration.
The official Speculative Loading plugin upgrades that to full prerendering with a settings screen at Settings → Reading.
Chromium browsers (Chrome, Edge, Opera) do the work; everyone else gets the normal experience with no side effects.
Analytics tools like Google Analytics handle prerendering correctly out of the box; custom tracking needs a prerender check.

Think of it as the top coat, not the paint job. If your pages are slow to begin with, start with the fundamentals in this guide on how to speed up WordPress with five quick wins, then let speculative loading make an already-fast site feel instant.

Have you noticed a difference since WordPress 6.8, or did you tune the settings with the plugin? Let us know in the comments section below!