WordPress Speculative Loading: Test the Cart, Analytics, and Cache Before Prerendering

By Greg Nowak. Updated 31 October 2026.

WordPress speculative loading can make the next page feel almost instant. Before enabling prerendering across a shop or business website, though, check what that prepared page will contain—and what it will do before anyone visits it.

A faster navigation is useful when the cart stays correct, analytics count real visits, and hosting can handle the extra work. Here is a practical release plan that gives developers, operations leads, and marketing teams something concrete to approve.

First, check what your site actually enables

Prefetching downloads the next page’s HTML without running its JavaScript. Prerendering goes further: it prepares the page in a hidden browser context, including running JavaScript. That larger head start also creates more opportunities for unwanted activity.

WordPress introduced speculative loading in 6.8 with prefetch and conservative eagerness: fetching starts as someone begins clicking a link. Its default eligibility excludes logged-in visitors and sites without pretty permalinks. See the WordPress Core implementation notes.

The official Speculative Loading plugin defaults to prerender with moderate eagerness and provides controls under Settings > Reading. It also offers an explicit opt-in for logged-in visitors. Treat that as a separate release decision.

Inspect the generated rules on your site. A performance plugin, custom code, or CDN may add its own rules, so the WordPress setting alone does not describe everything the browser receives.

Choose a starting point by journey

Exclude action URLs before measuring speed

List links that change something when requested: add-to-cart, logout, language selection, favourites, and server-side conversion triggers. Even prefetching can activate a server-side action if a GET request performs it. Move state-changing actions to POST where practical; exclude unsafe links while that work is pending.

Core’s default rules exclude query-string URLs on sites with pretty permalinks, but rewritten action paths still need attention. Use the documented Core exclusion filter for additional paths. For example, this deliberately cautious configuration excludes three sensitive areas from both modes:

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

Replace these with your actual slugs and check translated paths and URLs without trailing slashes. Add explicit patterns where needed. The plugin also documents plsr_speculation_rules_href_exclude_paths; use the hook appropriate to the implementation you maintain.

For individual links or blocks, no-prefetch excludes both modes. no-prerender blocks prerendering while allowing an otherwise eligible prefetch. These exclusions govern the rules that honour them; verify any separately generated rules too.

Test the cart after the next page has been prepared

A straightforward checkout walkthrough can miss the problem. The useful test changes state between preparation and navigation:

1. In Chrome DevTools, open Application > Speculative loads and confirm the intended target was prepared.
2. Stay on the current page and change the cart through AJAX: add an item, change quantity, or apply a discount.
3. Navigate to the prepared target and check products, totals, delivery choices, currency, and cart counters.
4. Repeat with preference changes and login or logout in another tab where relevant.
5. Leave a prepared target unvisited and check that it creates no business event.

The MDN safety guidance covers stale state in both prefetching and prerendering. If a test fails, refresh authoritative state when the page becomes active, invalidate affected preparations, or keep the journey excluded. Repeat the test to prove the fix.

Check analytics before and after activation

Google Analytics delays measurement until prerender activation by default, according to Chrome’s analytics guidance. Custom events, affiliate pixels, tag manager triggers, and CRM integrations still need their own checks.

For custom analytics, this activation gate preserves normal navigation behaviour while waiting on prerendered pages:

const whenActivated = new Promise((resolve) => {
    if (document.prerendering) {
        document.addEventListener('prerenderingchange', resolve, { once: true });
    } else {
        resolve();
    }
});

whenActivated.then(() => initialiseAnalytics());

initialiseAnalytics() represents your own integration; retain its consent checks and prevent duplicate initialization. Verify no page-view or conversion request fires before activation, then confirm the expected events fire once afterward. Consent choices must still be respected.

After activation, a non-zero navigation timing activationStart identifies a prerendered visit. Use that signal to compare real-user performance between prepared and ordinary navigations.

Approve the serving cost as well as the speed

An unvisited preparation can still consume bandwidth, PHP workers, database queries, and third-party API calls. Compare origin requests, cache-hit ratios, response times, application concurrency, and database load against a representative baseline. Separate cached public pages from personalized responses.

Measure how often preparations become actual visits alongside Largest Contentful Paint and journey completion. A fast demonstration does not establish a worthwhile rollout. Browsers may also decline speculation, so ordinary navigation must remain reliable.

Start with one predictable, cached journey. Agree who checks analytics, who watches hosting, and who can restore the previous configuration. Expand when correctness, measurement, and capacity checks pass.

If ownership is spread across an agency, marketing team, and hosting provider, Greg can coordinate a focused review: inspect the rules, map exclusions, test key journeys, and document a release recommendation. Talk to Greg about your WordPress performance rollout.

Related on GrN.dk

• JavaScript-Heavy Service Pages Still Lose Leads: What to Audit in 2026
• WordPress 7.1: A Performance Setting Your Host May Already Control
• Speculative Loading Without Surprises: A CMS Operations Checklist

Need help with this kind of work?

Discuss your WordPress performance rollout Get in touch with Greg.

Sources

• Speculative Loading in WordPress 6.8
• Speculative Loading — WordPress Performance Team Plugin
• WordPress Code Reference: wp_get_speculation_rules()
• Prerender Pages in Chrome for Instant Page Navigations
• MDN: Speculation Rules API