Practical WordPress performance, tested and explained.

Speed Test
WordPress Speed

WordPress Speculative Loading: How to Test, Configure, or Disable It

WordPress can prepare likely next pages before a visitor clicks. Learn what Core enables, how to verify it, and when to tune or disable it safely.

By SitePulse Labs 11 min read Published August 20, 2026
Abstract browser navigation path branching into a lighter prefetch route and a fully prepared prerender route.

Abstract browser navigation path branching into a lighter prefetch route and a fully prepared prerender route.

WordPress 6.8 added speculative loading to Core. On eligible front-end requests, WordPress prints a small set of browser instructions that can prepare an internal page shortly before a visitor follows its link. WordPress 7.1 did not replace the shipped default, but it did add an official way for hosting providers to change what that default resolves to.

This feature is not a page cache, a first-load optimization, or a shortcut to a higher Lighthouse score. It targets the next navigation after a page has already loaded. The browser may fetch only the destination document, or it may prepare the destination more completely, depending on the mode WordPress supplies.

For most sites, the conservative Core default is a reasonable starting point. The useful work is to confirm what your site actually outputs, test it as a logged-out visitor, and identify dynamic routes before making the rules more aggressive.

The short answer

  • On a standard WordPress 7.1 site, auto resolves to prefetch with conservative eagerness. A host can now override those default values, so inspect the output instead of assuming.
  • Core normally enables speculative loading only for logged-out visitors when pretty permalinks are active.
  • The optimization applies to likely subsequent navigations. It does not improve the initial landing page by itself and is not a guaranteed SEO or Core Web Vitals boost.
  • Core limits the rule to same-site links and automatically excludes administrative, asset, query-string, nofollow, and opted-out links. Site-specific carts, accounts, downloads, and state-changing routes may need extra exclusions.
  • The underlying Speculation Rules API has limited browser availability. It works in current Chromium-family browsers, while non-supporting browsers ignore the rules as a progressive enhancement.
  • prerender or more eager triggering can make a later navigation feel faster, but it can also spend more bandwidth, memory, CPU, and server capacity on a page the visitor never opens.

What speculative loading changes

Without speculation, the next page request starts after a click. Connection work, the HTML request, and rendering all sit on the critical path of that navigation. Speculative loading lets a supporting browser begin selected work earlier when its heuristics indicate that a link may be followed.

WordPress uses the web platform’s Speculation Rules API. It outputs a document-level rule describing which links are eligible, which mode to use, and how eager the browser should be. Core builds this JSON; most site owners should customize it through documented WordPress filters rather than editing the generated rules or Core files.

Two settings control the behavior:

  • Mode: prefetch requests the destination document. prerender prepares the page much more fully in a hidden renderer, including its subresources and JavaScript.
  • Eagerness: conservative waits for pointer or touch down. In current Chrome, moderate uses a 200-millisecond hover signal on desktop, or pointer down if that happens sooner; mobile uses viewport-based heuristics. eager triggers sooner than moderate. Chrome also supports immediate, but WordPress deliberately rejects it for Core’s document-level rule as a safety measure.

Browser heuristics are version-sensitive. Treat those timing details as a description of current Chrome behavior, not a permanent cross-browser contract.

Prefetch versus prerender

The modes are often grouped together as “preloading,” but they do materially different work.

Prefetch Prerender
Work before navigation Requests the destination document and may make it reusable for the click Loads and renders the destination in a hidden renderer, including CSS, JavaScript, and other subresources
Potential benefit Can reduce part of the network and server wait if the response finishes and is reused Can make activation feel close to instant when the prepared page is eligible and ready
Client cost Usually lower; one document response may go unused Higher memory, CPU, bandwidth, and script execution
Site cost An extra document request that should still be served safely A fuller page load that may never become a visible visit
Shipped Core default Yes: auto currently resolves to prefetch No; requires explicit configuration or a host-level default override

Prerendering deserves extra care on pages with personalization, authentication-sensitive state, analytics, advertising, or client-side actions. Chrome delays Google Analytics, Google Publisher Tag, and Google AdSense activity until activation, but that behavior should not be generalized to every third-party script. Other code may need to check document.prerendering and wait for prerenderingchange, or the affected route should be excluded.

Stale state is another concern. A page prepared in the background can reflect information that changes before activation. A cart, account area, availability screen, or personalized dashboard should be tested for correct activation behavior, not merely for speed.

What WordPress enables by default

WordPress 6.8 introduced speculative loading in Core. The default configuration is created only when no user is logged in and the site has a non-empty permalink structure. Otherwise, Core starts with null, which disables the feature for that request.

For eligible requests, the mode and eagerness initially use auto. In the current WordPress 7.1 code reference, those values resolve to prefetch and conservative. An explicit value supplied through wp_speculation_rules_configuration takes precedence.

WordPress 7.1 added WP_SPECULATIVE_LOADING_DEFAULT_MODE and WP_SPECULATIVE_LOADING_DEFAULT_EAGERNESS. A host can set either as an environment variable or constant to change what auto resolves to; a defined constant takes precedence over the corresponding environment variable. This means two WordPress 7.1 sites can legitimately produce different effective defaults even when neither site owner added a normal plugin filter.

A separate Core proposal discussed changing eagerness to moderate automatically when page caching and persistent object caching are detected. That proposal is assigned to a future release at the time of this review. It is not proof that WordPress 7.1 shipped cache-aware escalation, so do not diagnose your site on that assumption.

What Core excludes automatically

Core’s current rule applies only to links within the same site. Its base path exclusions cover:

  • /wp-*.php, which includes /wp-login.php;
  • /wp-admin/*;
  • paths in the site’s uploads and content directories;
  • paths in the plugins directory and the active template and stylesheet directories; and
  • on the normal pretty-permalink setup, any URL containing query parameters.

Core also excludes anchors with rel="nofollow". A link, or a parent containing links, can opt out with .no-prefetch or .no-prerender as appropriate. In prerender mode, .no-prefetch is also respected because prerendering includes the work of prefetching.

These base exclusions cannot be removed through the public path-exclusion filter. You can add your own path patterns, however.

The remaining risk is site-specific behavior. Some plugins expose clean-looking GET routes that change state, such as /add-to-favorites/123/, without a query string. Even if that design is undesirable, it exists. Carts, checkouts, accounts, search results, logout paths, download triggers, and personalized screens should be reviewed before increasing eagerness or enabling prerender. A path being readable does not automatically make it safe to request speculatively.

How to check whether it is active

Open a public page while logged out, choose View page source, and search for type="speculationrules". WordPress normally prints an inline JSON block. A platform or plugin can also deliver rules through a Speculation-Rules response header, so check the response headers if no inline block appears but you expect another implementation.

If you are logged in or the site uses Plain permalinks, the default WordPress configuration is disabled. Also check for a performance plugin, site-specific filter, or host override before concluding that Core is malfunctioning.

A controlled DevTools test

Chrome DevTools provides a dedicated view under Application → Background services → Speculative loads. Use it to confirm eligibility and results rather than inferring success from how fast a click feels.

  1. Use a current Chromium browser with its page-preloading setting enabled. Open a private window or otherwise confirm you are logged out of WordPress.
  2. Open the Speculative loads panel, then reload the page so the panel can populate the current rule set.
  3. Inspect the Rules view for valid or invalid JSON and the source of each rule. Check that the effective mode, eagerness, and exclusions match what you intended.
  4. Interact with several representative same-site links. For conservative, pointer or touch down is the relevant trigger. For a more eager configuration, include hover behavior on desktop and normal scrolling/tapping on mobile.
  5. Inspect the Speculations view. It records candidate URLs and whether an attempt is pending, ready, activated, failed, or ineligible, with failure details where available.
  6. Include both normal articles and sensitive templates in the review. Confirm that deliberately excluded cart, checkout, account, search, action, and download routes do not become eligible.
  7. When comparing configurations, change one setting at a time. Keep the browser, device profile, tested links, login state, and cache state consistent.
  8. Review server or edge logs and resource monitoring if available. The browser panel shows client-side behavior; logs show how many extra requests reached your infrastructure.

This is a manual functional test, not a load test. Normal repeated navigation is enough to verify rules. Obtain your host’s permission before sending artificial load.

A one-off Lighthouse run cannot prove that speculative navigation worked, because it measures an isolated page load. Use the PageSpeed Insights guide to keep lab and field evidence separate, and build a repeatable WordPress performance baseline before comparing wider performance changes. The SitePulse WordPress Speed Test can support that baseline, but DevTools and request evidence are what confirm speculation status.

Keep, tune, exclude, or disable?

For most publishing and brochure sites, leave prefetch plus conservative in place unless testing reveals a specific problem. It offers a restrained subsequent-navigation benefit with a relatively low chance of wasted work.

Consider moderate only when likely internal destinations are cacheable, the server has headroom, and representative desktop and mobile behavior has been checked. Understanding which WordPress caching layers absorb incoming requests is useful because more eagerness can create more background requests; it does not turn those requests into free work.

Consider prerender for tightly controlled navigation paths where activation behavior, scripts, personalization, and infrastructure cost have all been verified. Do not enable it across a dynamic site merely because it feels faster in one desktop test.

Add exclusions when only certain routes are unsafe. Disable the feature while investigating unexpected state changes, excessive request volume, or a conflict you cannot yet isolate. In a broader optimization backlog, prioritize measured WordPress speed findings before spending time on a small navigation refinement while a larger first-load bottleneck remains.

Safe, reversible code changes

Put a chosen override in a small site-specific plugin or MU-plugin. Do not edit WordPress Core. Theme functions.php edits disappear after a theme switch and a syntax error there can break the front end. Use only the configuration callback you actually need; a disable filter and a mode-setting filter should not compete in the same active plugin.

Disable speculative loading

<?php
/**
 * Plugin Name: SitePulse Labs - Speculative Loading Override
 * Description: Site-specific control for WordPress speculative loading.
 */

add_filter( 'wp_speculation_rules_configuration', '__return_null' );

Rollback: Deactivate the plugin or remove the filter. There is no database migration to undo.

Select an explicit mode and eagerness

<?php
add_filter(
    'wp_speculation_rules_configuration',
    static function ( $config ) {
        if ( is_array( $config ) ) {
            $config['mode']      = 'prerender';
            $config['eagerness'] = 'moderate';
        }

        return $config;
    }
);

The is_array() check preserves Core’s disabled contexts instead of enabling speculative loading for logged-in users or Plain permalinks.

Rollback: Remove this filter or deactivate its plugin. auto will again resolve to Core’s default or the host’s override.

Add custom path exclusions

<?php
add_filter(
    'wp_speculation_rules_href_exclude_paths',
    static function ( $paths ) {
        $paths[] = '/cart/*';
        $paths[] = '/checkout/*';
        $paths[] = '/my-account/*';

        return $paths;
    }
);

Replace these examples with the actual routes used by your site, then test both the exact landing path and its children. Paths begin with / and can use * as a wildcard.

Rollback: Remove the added patterns or deactivate the plugin. Core’s built-in exclusions remain intact.

Troubleshooting

  • No rules are visible: Confirm WordPress is 6.8 or later, the session is logged out, and Permalinks are not set to Plain. Purge page caches after changing code.
  • Rules exist but no attempt triggers: Enable the browser’s page-preloading preference, open the Speculative loads panel, reload, and test a same-site link that is not excluded.
  • A rule is invalid or blocked: Read the Rules panel error. A strict Content Security Policy may need the standards-defined inline-speculation-rules source expression for inline rules.
  • The observed default is unexpected: Check performance plugins, MU-plugins, site filters, and the two WordPress 7.1 host-level constants or environment variables.
  • A dynamic page behaves incorrectly: Return to prefetch/conservative, add an exclusion, or disable speculation while checking state, activation events, and third-party code.
  • Testing differs by device: Chrome’s desktop and mobile eagerness heuristics are not identical. Repeat the same route on representative devices rather than extrapolating from hover behavior alone.

FAQs

Does speculative loading speed up a visitor’s first page?

No. The browser needs a loaded page containing rules and links before it can prepare a likely destination. Improve the first-load path separately.

Will it improve my PageSpeed Insights score?

Not automatically. Lighthouse tests a page load in isolation, while this feature targets navigation from one page to another. Any effect on field metrics depends on real eligibility, completion, activation, and traffic patterns.

Is speculative loading an SEO ranking factor?

There is no documented direct ranking signal for enabling it. Treat it as a user-experience optimization, not a ranking guarantee.

Can it be used with a page cache or CDN?

Yes. They address different stages of the request. A cache can reduce the origin cost of speculative requests, but you should still measure the added request volume and check for duplicate rules from performance tools.

Add no-prefetch or no-prerender to the anchor or a parent element. Also remember that Core excludes rel="nofollow" links, although nofollow should not be added solely as a performance switch because it has separate link semantics.

Conclusion

WordPress speculative loading is useful precisely because its shipped default is restrained. Verify the effective rule on your own site, confirm it in DevTools, and review sensitive routes before increasing eagerness or switching to prerender. If logs or functional checks reveal wasted requests or incorrect state, the safest response is an explicit exclusion or a reversible rollback—not a faster-looking navigation at the expense of reliability.

Sources and further reading

About the author

SitePulse Labs

SitePulse Labs publishes practical WordPress performance, hosting, security, Core Web Vitals, and technical SEO guidance.

View all articles →

Continue reading