The WordPress 7.1 roadmap says speculative loading can move from conservative to moderate when both object and page caching are detected. That can improve perceived navigation, but it also increases eligible prefetches. Incorrect cache detection, private links, cart routes, tracking redirects, personalized pages, or a weak CDN key can turn helpful speculation into origin load, stale content, or unwanted requests.
Use this for WordPress site owners, hosts, performance teams, publishers, membership sites, ecommerce stores, and agencies preparing the final WordPress 7.1 release.
Quick answer
Record the exact WordPress release candidate, cache plugins, persistent object cache, CDN policy, browser, and speculation rules. Create public, personalized, logout, cart, search, file-download, external, and tracking-link fixtures. Compare conservative and moderate mode for eligible links, request purpose headers, edge hits, origin requests, cache keys, user-visible latency, analytics noise, and business actions. Approve moderate mode only when private or state-changing routes stay excluded and the extra fetch budget is justified.
What to check first
- Record WordPress build, cache detection result, object-cache backend, page cache, CDN, browser, and active speculation rules.
- Inventory links that are public, personalized, destructive, authenticated, cart-related, external, downloadable, or decorated with tracking parameters.
- Capture request purpose, status, cache result, Age, origin count, bytes, cancellation, and subsequent navigation timing.
- Compare conservative and moderate cohorts under cold edge, warm edge, mobile network, save-data, and logged-in conditions.
- Watch origin CPU, database work, cache churn, analytics sessions, cart state, privacy signals, and conversion completion.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Public article | Warm CDN object | Prefetch is an edge hit and navigation is faster |
| Account link | Logged-in personalized page | Excluded from speculation |
| Cart action | State-changing or nonce URL | Never fetched speculatively |
| Cold edge | Moderate mode traffic burst | Origin stays within approved budget |
Decision rule
Enable moderate behavior only when every sensitive fixture remains excluded, shared pages have correct cache keys, origin and byte budgets pass, analytics can distinguish speculation, and measured navigation benefit is meaningful.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze cache detection and speculation rules for a reproducible staging fixture.
- Exclude private, state-changing, signed, cart, checkout, logout, and high-cost routes.
- Correct CDN cache keys and origin bypass rules before increasing eligibility.
- Set request, byte, origin, and analytics-noise budgets for moderate mode.
- Run a small production cohort and keep a documented conservative-mode rollback.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze cache detection and speculation rules for a reproducible staging fixture. | Record WordPress build, cache detection result, object-cache backend, page cache, CDN, browser, and active speculation rules. | Eligible public links show the intended purpose and cache behavior. |
| Exclude private, state-changing, signed, cart, checkout, logout, and high-cost routes. | Inventory links that are public, personalized, destructive, authenticated, cart-related, external, downloadable, or decorated with tracking parameters. | Private and state-changing URLs receive no speculative request. |
| Correct CDN cache keys and origin bypass rules before increasing eligibility. | Capture request purpose, status, cache result, Age, origin count, bytes, cancellation, and subsequent navigation timing. | Origin, bandwidth, cache churn, and analytics noise stay in budget. |
| Set request, byte, origin, and analytics-noise budgets for moderate mode. | Compare conservative and moderate cohorts under cold edge, warm edge, mobile network, save-data, and logged-in conditions. | Real navigations and conversions work with a one-step rollback available. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture,mode,route,purpose,edge,origin,bytes,navigation_ms,business_state,result
SP-01,moderate,/guide,prefetch,hit,0,48120,118,unchanged,pass
SP-02,moderate,/my-account,none,none,0,0,622,private,pass
SP-03,moderate,/cart/add,none,none,0,0,710,unchanged,pass
SP-04,moderate,/pricing,prefetch,miss,1,52700,142,unchanged,watch
Production verification checklist
- Eligible public links show the intended purpose and cache behavior.
- Private and state-changing URLs receive no speculative request.
- Origin, bandwidth, cache churn, and analytics noise stay in budget.
- Real navigations and conversions work with a one-step rollback available.
Why this usually happens
- Cache presence does not prove every eligible URL has a safe shared cache key.
- Moderate rules can fetch links users never choose, especially dense menus and archives.
- Analytics and security systems may interpret speculative requests as ordinary visits unless purpose signals are respected.
Field notes
- Test with real navigation density rather than a blank theme page.
- Keep authenticated, cart, checkout, logout, preview, and signed URLs outside speculation.
- Compare user benefit against origin and bandwidth cost, not only a synthetic Lighthouse score.
Mistakes to avoid
- Changing production before preserving a reproducible fixture, timestamps, and the current result.
- Treating one successful screen, request, or export as proof that every downstream system agrees.
- Removing logs, identifiers, or rollback evidence before the owner and failure boundary are known.
- Testing only an administrator session instead of the roles, devices, consent states, and failure paths users actually have.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and a narrow synthetic fixture. Perform destructive, version, cache-policy, queue, or schema changes on staging first, then promote the smallest proven change.
What evidence should be kept?
Keep versions, fixture IDs, UTC timestamps, request or export evidence, expected and actual results, the decision owner, rollback point, and the final clean verification. Redact personal data.
When is the work finished?
Finish when the canonical user path passes, downstream records reconcile, failure cases are understood, monitoring is in place, and an established page links to the new guide with useful context.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, 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, review WordPress 7.1 performance readiness.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Test the Save-Data exclusion
Extend the cache-readiness matrix with the WordPress 7.1 Save-Data speculation test so constrained users, transferred bytes, cancellations, origin requests, and sensitive-route exclusions are measured directly.
Measure origin-miss burn
After cache readiness passes, use the WordPress 7.1 speculation origin-burn dashboard to join purpose, edge result, PHP work, queries, bytes, activation, and navigation benefit.
Helpful references