By Greg Nowak. Last updated 2026-09-16.
WordPress 7.1 gives hosting platforms and site operators more control over speculative loading. This browser feature can fetch—or go further and prepare—a likely next page before someone clicks. Get the setup right and navigation can feel much faster. Get it wrong and the site may generate requests nobody planned for, muddy the analytics and make the source of the behaviour surprisingly difficult to find.
The change does not make every WordPress site speculate more aggressively. The WordPress function reference documents new constants and environment variables for selecting the loading mode and eagerness. Hosts and deployment teams can now set that policy outside the database and WordPress interface.
That is useful operationally, but it changes how teams need to troubleshoot. If a site starts emitting an unexpected speculation rule, the WordPress settings screen tells only part of the story. The effective configuration could come from infrastructure, application code or another component adding rules of its own.
What WordPress 7.1 actually shipped
WordPress 7.1 was released on August 19, 2026. Its developer-facing changes are collected in the WordPress 7.1 Field Guide, a sensible starting point for compatibility checks on any managed WordPress stack.
There is an important detail in the development history. Contributors considered changing the default eagerness automatically according to caching conditions. The Core development ticket records that proposal and the eventual implementation. The cache-driven default change did not make the release; the new configuration controls did.
So if a site begins prefetching or prerendering more eagerly after an upgrade, do not assume WordPress 7.1 applied a universal new default. Inspect the rules sent to the browser, then identify the component responsible for each one.
Someone needs to own the rules
The Speculation Rules API lets a page describe possible navigation targets and the conditions under which a browser may act on them. Prefetching retrieves resources for a potential visit. Prerendering prepares the page more fully so it can appear quickly if the visitor chooses it.
The browser still decides whether to carry out the speculative action. A rule is a request, not a promise. Even so, eligible pages may receive traffic before a normal navigation happens, which is where careless configurations start to cause trouble.
Chrome’s prerendering guidance spells out the operational effects. Speculative work can influence origin load, caching, page state and analytics. A prerendered document also exists before and after activation. Code that treats every loaded page as visible may record activity too soon or trigger work before a visitor arrives.
The picture gets harder to read when several layers take part. A plugin may emit one set of rules, a theme another, while the hosting or delivery platform applies a broader policy. Each configuration can look reasonable on its own and still duplicate candidates, create overlapping behaviour or weaken exclusions.
| Route type | Main risk | What to check |
|---|---|---|
| Public article or landing page | Extra origin traffic | Cache status, number of candidates and actual navigation benefit |
| Personalised page | User-specific state | Cookie handling, cache separation and activation behaviour |
| Search results | Large numbers of unique URLs | Query exclusions and backend request volume |
| Cart or account area | Sensitive or state-changing flows | Explicit exclusions and no speculative requests |
| Login or logout route | Authentication transitions | Session behaviour and redirects |
| Download or tracked link | Side effects happening too early | No delivery, counting or tracking before activation |
A CDN helps, but it does not settle the cost question
A strong cache can absorb some speculative requests. “Served from cache” still does not mean free—or necessarily correct. The browser, network and delivery layer all do work. A cache miss can reach WordPress and its database, while personalised pages and query-based routes may bypass shared caching entirely.
Cache coverage should inform the policy without quietly becoming the policy. The proposed WordPress change would have linked eagerness to caching conditions, but that automatic behaviour did not ship. Teams can make the choice explicitly, based on the routes visitors actually use, how those routes are cached and how much additional load is acceptable.
The useful question is more specific than “Do we have a CDN?” Ask whether the eligible destinations are reliably cacheable, whether the rule selects the right links and whether the navigation improvement earns the extra work. Review CDN and origin logs together; either view on its own can hide part of the request path.
Test what reaches the browser
Start with the final HTML and the rules the browser receives. List every possible producer: WordPress core configuration, environment-level settings, plugins, themes and delivery components that can modify a response. Then record which layer owns the default and which one owns the exclusions.
Next, use the browser’s network tools on representative routes. Test obvious next clicks, but also test links that must never be speculative. Public pages, personalised views, internal search, carts, authentication routes, downloads and tracked links need separate cases because their caching and state behaviour are different.
Match that browser activity against edge and origin logs. This shows which speculative requests are cache hits, which reach PHP and whether two rule sets are doing the same work. A page can feel quick while quietly producing an unreasonable increase in backend traffic.
Measurement needs its own check. Page code should distinguish between a document prepared in advance and one activated for a visitor. Analytics and other side effects belong at the correct point in that lifecycle. Extra page views are not evidence of a performance gain if they include pages that were prepared but never visited.
Set one baseline and make the exceptions clear
WordPress 7.1 makes speculative-loading policy easier to control at deployment level. It cannot choose the right policy for a particular site. That depends on real navigation patterns, caching, personalisation, backend capacity and measurement requirements.
A workable setup has one explicit baseline, documented exclusions and a clear owner for changes. Remove conflicting emitters instead of trying to tune around them. Once the configuration is clean, compare navigation responsiveness with edge traffic, origin work and analytics quality.
This is a compact performance project, but it crosses hosting, development and measurement. Greg can help trace each rule to its source, build the route-based test matrix, compare browser evidence with CDN and origin logs, and turn the findings into a configuration every team can understand. The goal is faster navigation that helps visitors, without creating avoidable work elsewhere in the stack.
Related on GrN.dk
- AI Research Assistants Need a Source Trail, Not Just Citations
- Google’s 2026 AI Search Guidance: SEO Still Matters, but Reporting Has Changed
- Background AI Tasks Need Queues—not Just Longer API Calls
Need help with this kind of work?
Review your WordPress performance setup Get in touch with Greg.
