The WordPress 7.1 roadmap described moving speculation toward moderate eagerness when object and page caching are detected. Cache detection is not the same as protection. Personalized routes, cookie variants, stale keys, purge storms, query strings, device variants, bypass headers, or a CDN configuration error can send speculative requests to PHP and the database without a completed navigation.
Use this for WordPress performance, hosting, CDN, database, analytics, security, and conversion teams evaluating speculative loading.
Quick answer
First record whether the installed build enables the expected speculation policy. Create fixtures for ordinary navigation, prefetch, prerender, canceled speculation, activated speculation, Save-Data, logged-in users, sensitive routes, query strings, cache warm and cold states, and purge windows. Join purpose, route class, edge result, origin status, PHP time, queries, bytes, CPU, rate-limit use, activation, and navigation improvement. Set an origin-miss and byte budget before expanding.
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 |
|---|
| Warm public page | Prefetch then activated navigation | Edge hit and measurable navigation gain |
| Canceled speculation | User never opens target | Cost remains inside waste budget |
| Personalized route | Cart, account, or nonce state | Excluded from speculation |
| Purge window | Cold cache under traffic | Origin budget triggers hold |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Confirm the active speculation configuration and route exclusions. | Record WordPress build, speculation rules, page-cache and object-cache detection, CDN policy, cookies, bypasses, exclusions, and origin limits. | Every speculative request has a route class, purpose, cache result, origin result, and activation state. |
| Repair CDN and application cache keys that create avoidable public-route misses. | Classify public cacheable, personalized, cart, checkout, account, search, admin, API, query-string, and signed routes. | Public warm routes stay at the edge while sensitive routes remain excluded. |
| Exclude personalized, state-changing, costly, and rate-limited paths. | Capture Sec-Purpose or Purpose, edge cache result, origin request, response status, database query count, PHP time, bytes, CPU, and rate-limit units. | Origin requests, database work, bytes, CPU, and rate-limit burn remain inside threshold. |
| Lower eagerness or disable the affected cohort when waste exceeds budget. | Compare cold, warm, purged, stale, error, canceled, activated, Save-Data, logged-in, bot, and slow-network fixtures. | Real completed navigations improve without false sessions, leads, purchases, or security incidents. |
What to check first
- Record WordPress build, speculation rules, page-cache and object-cache detection, CDN policy, cookies, bypasses, exclusions, and origin limits.
- Classify public cacheable, personalized, cart, checkout, account, search, admin, API, query-string, and signed routes.
- Capture Sec-Purpose or Purpose, edge cache result, origin request, response status, database query count, PHP time, bytes, CPU, and rate-limit units.
- Compare cold, warm, purged, stale, error, canceled, activated, Save-Data, logged-in, bot, and slow-network fixtures.
- Calculate origin misses and transferred bytes per completed navigation, then define hold and rollback thresholds.
Field notes
- Separate user-perceived navigation improvement from server-resource cost.
- Keep canceled speculation visible in performance reports but out of business conversions.
- Use route classes and purpose signals instead of judging one aggregate cache-hit percentage.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
route,purpose,edge,origin,queries,php_ms,bytes,activated,nav_gain,result
/blog/a,prefetch,HIT,0,0,0,8421,yes,180ms,pass
/search?q=x,prefetch,MISS,1,42,210,94120,no,0,hold
/cart,none,BYPASS,1,31,180,52010,yes,n/a,excluded
/blog/b,prerender,MISS,1,18,95,81220,no,0,review
Why this usually happens
- A page cache can exist while specific cookies or routes bypass it.
- Speculative requests happen before a completed user navigation is guaranteed.
- Object cache hits still consume PHP, network, serialization, and database-adjacent work.
- CDN cache keys can fragment by device, query, language, cookie, or header.
Decision rule
Keep the more eager policy only when representative public routes improve completed navigation, canceled work stays inside budget, and sensitive or expensive paths never reach the origin through speculation.
Production verification checklist
- Every speculative request has a route class, purpose, cache result, origin result, and activation state.
- Public warm routes stay at the edge while sensitive routes remain excluded.
- Origin requests, database work, bytes, CPU, and rate-limit burn remain inside threshold.
- Real completed navigations improve without false sessions, leads, purchases, or security incidents.
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.
- Confirm the active speculation configuration and route exclusions.
- Repair CDN and application cache keys that create avoidable public-route misses.
- Exclude personalized, state-changing, costly, and rate-limited paths.
- Lower eagerness or disable the affected cohort when waste exceeds budget.
- Retest navigation benefit and origin cost after every cache, CDN, or plugin change.
Mistakes to avoid
- Changing production before preserving exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful browser screen as proof that queues, providers, caches, reports, roles, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, consent states, networks, and failure paths real users have.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a customer, expose personal data, or change inventory. Perform destructive repairs, upgrades, cache-policy changes, and schema work on staging first. Promote only the smallest measured change with a current rollback point.
What evidence should the report keep?
Keep exact component versions, UTC timestamps, stable synthetic IDs, expected and actual results, queue or provider identifiers, the decision owner, rollback point, and final verification. Redact customer data, credentials, tokens, message content, addresses, and private infrastructure details before sharing evidence.
When is the task complete?
Complete the task when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context. Record any observation window that remains instead of calling a quiet test a permanent fix.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, root cause or current cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window is still open.
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, audit WordPress speculative-loading cost.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Set a cold-cache purge budget
Use the WordPress 7.1 speculative-loading cache purge budget to separate real and speculative requests during invalidation, quantify origin burn, and stop routes that exceed capacity without user benefit.
Helpful references