Speculation Rules in WordPress: Prerender Pages for Near-Instant Clicks

You click a link on a WordPress site and the next page appears before you have finished blinking.

That is what the Speculation Rules API does. It lets a site tell the browser which links a visitor is likely to click next, so the browser can fetch — or even fully render — those pages ahead of time. Used well, it turns ordinary navigation into something that feels instant. Used carelessly, it burns server resources, inflates analytics, and prerenders pages nobody ever wanted.

This guide explains how speculation rules work, what WordPress already does for you, how to turn them on safely, and — just as important — what to exclude.

What speculation rules actually do

When you visit a page, your browser normally waits for a click before it requests the next page. Speculation rules flip that order. You give the browser a small set of JSON instructions, and the browser decides, based on those instructions, which linked pages to prepare in advance.

There are two levels of preparation, and the difference between them matters a lot:

Prefetch downloads a page’s HTML in the background but does not run it. When the visitor clicks, the browser still has to parse the HTML, load the CSS and JavaScript, and render the page. The click feels faster — often noticeably so — but it is not instant, because the heavy work still happens after the click.

Prerender goes all the way. The browser loads the page, runs its scripts, and renders it invisibly in the background. When the visitor clicks, the browser simply swaps the prerendered page into view. The result feels genuinely instant, because almost all of the work is already done.

Eagerness: how bold should the browser be?

Speculation rules also let you control when the browser starts preparing a page:

• Immediate — prepare the page as soon as the rules are read. The most aggressive option and the easiest to misuse.
• Eager — prepare pages for links the visitor hovers over, and for links visible on screen. A reasonable middle ground for prerendering.
• Moderate — wait for a hover of a couple of hundred milliseconds before preparing. A brief hover is a decent signal of intent, which makes this the sensible default for most sites.
• Conservative — wait for a stronger interaction signal. The safest option, and the one that wastes the least.

Think of eagerness as a dial between speed and waste. Every step toward “immediate” buys a little more speed and spends a little more server capacity on pages nobody visits. Start at moderate; get bolder later, once you have measured the cost.

What WordPress already does for you

Here is the good news: if you run a recent version of WordPress, you may not need to do anything at all. WordPress 6.8 and later include speculative loading out of the box, with a conservative default aimed at logged-out visitors — the audience that benefits most, since their pages are cacheable. Before you install a plugin or paste any code, check what is already there. It takes about thirty seconds.

Step 1: Check whether speculation rules are already running

Open any public page on your site in Chrome or Edge, right-click, and choose View Page Source. Search the source for speculationrules. If you find a block of JSON that looks like this, speculation rules are already active:

{
"prerender": [
{
"source": "document",
"where": {
"and": [
{ "href_matches": "/" },
{ "not": { "href_matches": "/wp-" } },
{ "not": { "selector_matches": ".no-prerender" } }
]
},
"eagerness": "moderate"
}
]
}

Do not be surprised if the exact pattern differs — the presence of the block is what matters. If it is there, your site is already prerendering same-site links at a moderate eagerness, with WordPress admin paths excluded. That is a solid default, and for many sites it is all you will ever need.

Step 2: Choose prefetch or prerender

Before you touch any settings, decide which level of preparation your site actually needs.

Choose prefetch if your hosting is shared or resource-limited, your pages are heavy, or your traffic is high. Prefetch still cuts a visible chunk off navigation time, because the HTML is already on the visitor’s device when they click — and when a prefetched page is never visited, the wasted cost is small.

Choose prerender if your pages are light and well cached, your hosting has headroom, and perceived speed matters most — for example, on a small brochure site, a documentation site, or a blog where visitors hop between articles. Prerender is also the right call when your server response is already fast, because then the browser-side work (parsing, scripts, rendering) is the remaining bottleneck, and prerendering removes exactly that.

Choose neither — yet — if your site has not fixed its slow first load. Speculation rules do nothing for the first page a visitor lands on, because there is no earlier page to speculate from. If your homepage takes four seconds, prerendering the second page will not save you. Fix the first load first: our guide to fixing LCP issues in WordPress (https://wpspeedaudits.site/how-to-fix-lcp-issue-wordpress/) walks through that in order of impact.

Step 3: Enable and tune speculation rules

There are two practical routes: a plugin, or a small code snippet. The plugin route is the right one for almost everyone.

Option A: The Speculative Loading plugin

The official Speculative Loading plugin from the WordPress Performance Team is free on wordpress.org and is the same codebase WordPress core adopted. Install and activate it, and it outputs a speculation rules block on your front end. Its settings let you adjust the mode (prefetch or prerender) and the eagerness without writing code.

After activating, view your page source again and confirm the speculationrules block is present. Then click around the site normally. Nothing should look different — that is the point.

Option B: Add the rules manually

If you prefer not to add another plugin, you can output the same JSON from your theme’s functions file or a code-snippets plugin. The snippet below adds a moderate-eagerness prerender rule for same-site links, while excluding WordPress admin paths:

add_action( 'wp_head', function() {
    if ( is_admin() || is_user_logged_in() ) {
        return;
    }
    ?>
    <script type="speculationrules">
    {
      "prerender": [{
        "source": "document",
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": { "href_matches": "/wp-*" } },
            { "not": { "href_matches": "/*\?*" } },
            { "not": { "selector_matches": ".no-prerender" } }
          ]
        },
        "eagerness": "moderate"
      }]
    }
    </script>
    <?php
} );

A few things to note about this snippet. It only runs for logged-out visitors, because prerendering for logged-in users risks leaking private content and because logged-in pages are rarely cacheable anyway. It skips URLs with query strings, which covers search results and filtered views. And it honours a no-prerender CSS class, which gives you a manual escape hatch for any individual link: add that class to a link and the browser will leave it alone.

Whichever route you take, do not run both at once. Two speculation rules blocks on the same page can conflict. Pick one method and stick with it.

What to exclude: the part most guides skip

Prerendering the wrong pages causes real problems. Treat this list as mandatory, not optional:

• Cart, checkout, and account pages. On a WooCommerce site, prerendering a checkout page can trigger cart fragments and session behaviour for visitors who never intended to buy. Exclude /cart/, /checkout/, and /my-account/ outright.
• Admin and login paths. Anything under /wp-admin/ and /wp-login.php should never be speculated. WordPress core already excludes these, but if you write your own rules, exclude them again.
• Logout links. This is the classic speculation-rules footgun. A prerendered logout link can log a visitor out before they click anything. Exclude any link that contains action=logout, and any link with the no-prerender class your theme applies to logout links.
• Forms and actions. Links that change state — delete, unsubscribe, confirm, approve — must never be prerendered. A hover is not consent to run an action.
• URLs with query strings. Search results, filtered archives, and tracking-parameter URLs are usually unique to one visitor. Prerendering them wastes resources and can pollute analytics with phantom pageviews.
• File downloads and external links. Speculation rules only apply to same-origin URLs by default, which already protects you from prerendering other people’s sites. Keep it that way.

How to test that prerendering is working

Speculation rules fail silently. A typo in the JSON, a conflicting plugin, or a browser that does not support the API will all leave your site looking exactly the same, just slower to navigate. So verify, don’t assume.

1. View the page source and confirm the speculationrules block is present and valid JSON. A single misplaced comma disables the whole block.
2. Use Chrome DevTools. Open DevTools, go to the Application panel, and look for the Speculative Loads section. It shows which URLs were prefetched or prerendered, and — usefully — which ones were rejected and why.
3. Time a navigation. Open a page, hover over a link for a second, then click it. On a prerendered link the new page should appear with almost no loading indicator. Compare with a link you excluded (for example, a no-prerender link) to feel the difference.
4. Check your server logs after a week. A small rise in requests to never-visited pages is normal — that is speculation doing its job. A large rise means your eagerness is too aggressive or your exclusions are too narrow.

That fourth check matters because most speed tests measure a single page load, not a navigation between two pages, so they will not show you the benefit. Our guide to testing WordPress speed the right way (https://wpspeedaudits.site/how-to-test-wordpress-site-speed/) covers lab versus field data and why a single score never tells the whole story.

The downsides nobody mentions

Speculation rules are genuinely useful, and they are also genuinely oversold. Before you enable prerender site-wide, weigh these costs honestly:

Server load goes up. Every prerendered page is a full page request your server has to serve, including database queries for any part that is not cached. On a site with thin hosting margins, aggressive prerendering can tip the server over during a traffic spike — and if your host charges by CPU or bandwidth, you are paying for pages nobody reads.

Analytics get noisier. Most analytics tools count a prerendered pageview only when the page is actually shown, which limits the damage. But server-side analytics, ad impressions, and some custom tracking will see inflated numbers. If your traffic suddenly jumps the week you enable prerendering, check whether it is real visitors or speculation before celebrating.

Mobile data is not free. Prerendering a page on a visitor’s phone consumes their data plan. Browsers are considerate here — Chrome, for example, is more conservative with speculation on slow connections — but the cost is still real. This is another reason moderate eagerness beats immediate: a hover is at least a hint of intent.

It can mask real problems. A site that feels instant because of prerendering can still have a terrible first load and bloated JavaScript. Speculation is a polish layer, not a foundation. If JavaScript execution time is the real bottleneck, our guide to reducing JavaScript execution time in WordPress (https://wpspeedaudits.site/reduce-javascript-execution-time-wordpress/) will do more for you than any speculation rule.

A sensible rollout

If you have read this far, here is the rollout I would recommend:

1. Check whether WordPress already outputs speculation rules. If it does, stop — you are done unless you have a specific reason to change the defaults.
2. If not, install the Speculative Loading plugin and leave it on its defaults for two weeks.
3. Exclude cart, checkout, account, logout, and action links explicitly, and confirm the exclusions in DevTools.
4. After two weeks, compare server load, bandwidth, and analytics against the previous period. If the cost is small and navigation feels faster, consider moving from moderate to eager prerendering on your lightest pages.
5. Re-check after any theme change, caching-plugin change, or hosting migration — any of those can silently remove or duplicate your rules.

Speculation rules are one of the rare performance features that ask almost nothing of the visitor and give back a genuinely better experience. The browser does the work and the visitor feels the difference. Just respect the exclusions, measure the cost, and remember what speculation cannot do: it cannot make a slow site fast. It can only make a fast site feel instant — which, when the foundations are right, is a very good thing to be.