Speculative Loading: A Practical CMS Operations Checklist

By Greg Nowak. Last updated 2026-06-24.

Speculative loading is no longer a browser experiment that only performance engineers need to watch. It now appears in places that ordinary website teams actually use: WordPress core, Cloudflare settings, and Drupal modules. That changes the job. The question is not simply whether speculative loading is fast. The question is whether the right parts of your site are being accelerated, safely, measurably, and with someone accountable for the rollout.

In plain terms, speculative loading lets a browser fetch, or in some cases prerender, a likely next page before the visitor clicks. Used carefully, that can make a service page, product page, article, or contact form feel almost instant. Used carelessly, it can request URLs that should never be touched in the background, distort analytics, waste cache capacity, or run scripts before a person has really navigated.

Why This Became an Operations Issue

The business case is straightforward. Many conversions depend on the second or third click, not the first page view. If a visitor moves from a homepage to a service page, from an article to a case study, or from a product listing to a product page, the perceived speed of that next page matters. It makes the site feel competent at the moment the visitor is deciding whether to continue.

The operational issue is that speculative loading may not be introduced by the same team that owns analytics, consent, cache rules, or risky application routes. WordPress can generate rules from core behavior. Cloudflare can add speculation at the edge. Drupal teams may add it through contributed tooling. A developer can also add inline rules or response headers. If nobody maps the source of the rules, several well-intentioned optimizations can overlap.

Where to Look First

Start by finding where speculation rules are coming from. Look for inline <script type="speculationrules"> markup, a Speculation-Rules response header, CMS defaults, plugins, modules, and CDN features. More than one source can be active, so do not stop after finding the first one.

On WordPress, speculative loading was introduced in core in version 6.8 with a conservative default: frontend prefetching rather than aggressive prerendering. It is disabled for logged-in users and for sites without pretty permalinks. That is a sensible baseline for many public content sites, but it still needs review against your routes and tracking setup.

At the edge, Cloudflare Speed Brain can add a Speculation-Rules header and ask Chromium-based browsers to prefetch likely next navigations with conservative eagerness. Cloudflare applies safeguards around cache eligibility, Workers, and origin fetches, but that does not remove the need to document who owns the setting and how it is tested.

Route Type	Good First Action	Reason
Public, anonymous, cacheable content	Allow same-origin prefetch	Low risk and often commercially useful
Homepage to service or product pages	Test targeted prefetch	Improves common decision journeys
Login, logout, account, cart, checkout, payment	Exclude by default	Often personalized, sensitive, or stateful
Search, filters, previews, admin paths	Review before enabling	Can create wasteful or misleading requests
High-confidence next page with tested scripts	Consider selective prerender	Higher reward, but higher analytics and consent risk

A practical first-pass matrix for deciding where speculative loading belongs.

The Risks to Test

The first risk is unsafe GET behavior. A background request should not log someone out, add an item to a basket, trigger a workflow, mark something as read, or change a record. If a URL changes state merely because it was requested, speculative loading will expose that design problem quickly. Exclude those paths first, then fix the underlying route behavior where possible.

The second risk is measurement drift. Prefetching is usually lighter because it fetches resources for possible later use. Prerendering is more powerful because the browser can prepare a page more fully before activation. That also means client-side code may run earlier than expected. Analytics, pixels, heatmaps, A/B testing, CRM scripts, and consent-dependent tags need explicit testing, especially if reporting drives marketing spend or sales decisions.

The third risk is unclear ownership. CMS teams, CDN administrators, developers, and marketing teams can all affect the same behavior. A safe rollout needs one route map, one list of exclusions, and one person or team responsible for checking the feature when plugins, campaigns, templates, or cache rules change.

Useful Implementation Checks

A quick header check can show whether an external rules file is being advertised:

curl -I https://example.com/

If the response includes a Speculation-Rules header, inspect the referenced file and confirm that it is served with the application/speculationrules+json MIME type. If the rules are inline, check your Content Security Policy. Inline speculation rules need 'inline-speculation-rules', a nonce, or a hash in script-src, otherwise the rollout can fail without an obvious visual symptom.

For WordPress path exclusions, keep the rule close to the operational reality of the site. For example:

add_filter(
    'wp_speculation_rules_href_exclude_paths',
    function ( $href_exclude_paths ) {
        $href_exclude_paths[] = '/cart/*';
        $href_exclude_paths[] = '/checkout/*';
        $href_exclude_paths[] = '/account/*';
        return $href_exclude_paths;
    }
);

Also check for the editor-level no-prefetch and no-prerender classes where a specific link or block should be opted out. These are useful for content teams, but they should not replace a proper path-level exclusion strategy for sensitive areas.

A Sensible Rollout Plan

For most business sites, the practical first phase is same-origin prefetch on public, anonymous, cacheable pages. Measure server requests, cache hit rate, important journey speed, analytics changes, and consent behavior. Keep the first scope small enough that you can inspect it manually in browser tooling and logs. Look for requests carrying Sec-Purpose: prefetch, and remember that unsupported browsers should simply ignore the rules.

Only then consider selective prerendering for a small number of high-confidence journeys. Good candidates are predictable next steps with clean caching, no personalization, and scripts that behave correctly when a page is prerendered and later activated. If that sounds narrow, that is the point. Speculative loading works best as a precise operational improvement, not a blanket switch.

A good deliverable should leave the business with more than a faster click. It should document where rules are generated, which paths are allowed, which paths are excluded, how analytics was validated, who owns the configuration, and when it should be reviewed again. If you need that audit across WordPress, Drupal, Cloudflare, caching, and analytics, talk to Greg about a focused performance and operations review.