The WordPress 7.1 roadmap plans a speculative loading change that can move eligible cached sites from conservative behavior toward moderate prefetch or prerender behavior. Staging should reveal extra requests, excluded URLs, analytics effects, and origin load before production adoption.
Use this for cached WordPress sites with WooCommerce, forms, membership areas, personalization, analytics, ad tags, rate-limited APIs, or JavaScript that changes state on page load.
Quick answer
WordPress 7.1 Speculative Loading Cache Detection Test should be handled with a narrow evidence-first workflow: confirm cache detection, inspect rule exclusions, measure extra requests, then verify the result before making broader changes.
What to check first
- Record whether WordPress detects page cache and persistent object cache on the staging environment.
- Inspect the generated speculation rules and list eligible, excluded, authenticated, query-string, cart, account, and admin URLs.
- Measure browser network requests, origin requests, cache hits, CPU, PHP workers, and bandwidth during hover and navigation tests.
- Confirm analytics, pixels, forms, carts, stock, personalization, and consent code do not treat prerender as a real visit or action.
- Compare disabled, conservative, and planned automatic behavior with the same navigation script.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Confirm cache detection | Record whether WordPress detects page cache and persistent object cache on the staging environment. | The staging environment reflects production page and object cache capabilities. |
| Inspect rule exclusions | Inspect the generated speculation rules and list eligible, excluded, authenticated, query-string, cart, account, and admin URLs. | Stateful, private, query-based, and authenticated URLs remain excluded. |
| Measure extra requests | Measure browser network requests, origin requests, cache hits, CPU, PHP workers, and bandwidth during hover and navigation tests. | Prerender does not create false pageviews, leads, purchases, or consent events. |
| Audit side effects | Confirm analytics, pixels, forms, carts, stock, personalization, and consent code do not treat prerender as a real visit or action. | Performance gains exceed measured bandwidth, worker, and analytics costs. |
Why this usually happens
- Prerendered pages can execute client-side code before the visitor commits to navigation.
- A cache-detection difference between staging and production can produce different defaults.
- Personalized or state-changing URLs need explicit exclusions.
- A CDN hit can hide additional browser requests from origin-only monitoring.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS https://staging.example.com/ | rg 'speculationrules|prefetch|prerender'
wp site-health status
wp cache get handl_cache_probe default
# Compare browser and origin logs for one scripted navigation path.
# Never include cart, account, logout, nonce, or state-changing URLs.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Confirm cache detection
- Inspect rule exclusions
- Measure extra requests
- Audit side effects
- Compare modes
What to tell the client or owner
Share cache detection results, speculation rules, excluded paths, network trace, origin load, analytics findings, and the chosen mode with rollback criteria.
Production verification checklist
- The staging environment reflects production page and object cache capabilities.
- Stateful, private, query-based, and authenticated URLs remain excluded.
- Prerender does not create false pageviews, leads, purchases, or consent events.
- Performance gains exceed measured bandwidth, worker, and analytics costs.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, test WordPress performance changes before production.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Verify environment-owned speculative loading configuration
When a host, deployment, or wp-config value can control the feature, run the WordPress 7.1 speculative loading constants and environment configuration test before diagnosing cache differences.
Helpful references
Prove speculative navigation does not count as a conversion
After cache detection and eagerness are confirmed, run the speculative loading false-conversion audit to test request-purpose headers, prerender state, page activation, consent, event IDs, and real business actions.