WordPress 7.1 can use more active speculative loading on sites with page and object caches. The expected exclusions need a direct Save-Data test. A site can look fast on office Wi-Fi while a constrained mobile user receives extra HTML bytes, duplicate work, canceled requests, origin misses, analytics noise, or stale personalized content.
Use this for WordPress performance teams, hosts, publishers, ecommerce stores, membership sites, and agencies supporting mobile or metered users.
Quick answer
Test the same public, private, cart, checkout, logout, download, external, and tracking-decorated links with Save-Data on and off. Record browser version, network profile, speculation rules, link eligibility, Sec-Purpose, status, transfer size, cache result, origin request, cancellation, navigation timing, and business state. Save-Data users should receive no unapproved speculative request. If the browser or rule implementation cannot provide that guarantee, exclude the route or return to conservative behavior.
What to check first
- Record WordPress build, browser, Save-Data state, connection profile, speculation rules, cache detection, CDN, and authenticated state.
- Create public, private, destructive, cart, checkout, logout, search, download, external, and campaign-link fixtures.
- Capture request purpose, transfer bytes, cache status, Age, origin count, cancellation, and the timing of the eventual real navigation.
- Compare cold edge, warm edge, slow connection, packet loss, and background-tab behavior with Save-Data on and off.
- Watch analytics, consent, cart contents, CSRF tokens, rate limits, and server CPU for side effects.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze browser, network, cache, and speculation configuration for the fixture. | Record WordPress build, browser, Save-Data state, connection profile, speculation rules, cache detection, CDN, and authenticated state. | Save-Data fixtures show the intended exclusion in the actual network trace. |
| Exclude Save-Data, private, state-changing, signed, and high-cost routes. | Create public, private, destructive, cart, checkout, logout, search, download, external, and campaign-link fixtures. | Private and state-changing routes receive no speculative request. |
| Correct cache keys before counting an edge hit as safe. | Capture request purpose, transfer bytes, cache status, Age, origin count, cancellation, and the timing of the eventual real navigation. | Public requests have correct purpose, cache, byte, and origin evidence. |
| Set byte, origin, cancellation, analytics-noise, and navigation-benefit budgets. | Compare cold edge, warm edge, slow connection, packet loss, and background-tab behavior with Save-Data on and off. | Real navigation, consent, cart state, analytics, and conversions remain correct. |
Why this usually happens
- Cache readiness says nothing about a visitor's network cost or preference.
- Dense navigation can make moderate rules fetch many pages the user never opens.
- Browsers and intermediaries may expose different purpose signals.
- A canceled request still consumed bytes and may have reached the origin.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture,save_data,network,eligible,purpose,edge,origin,bytes,navigation_ms,result
SD-01,off,4g,true,prefetch,hit,0,48120,122,pass
SD-02,on,4g,false,none,none,0,0,638,pass
SD-03,on,slow-3g,false,none,none,0,0,1220,pass
SD-04,off,slow-3g,true,prefetch,miss,1,53110,178,watch
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 guide | Save-Data off and warm edge | Eligible request stays within byte budget |
| Public guide | Save-Data on | No unapproved speculative transfer |
| Account page | Authenticated user | Always excluded |
| Cart action | Nonce or state-changing URL | Never requested speculatively |
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 browser, network, cache, and speculation configuration for the fixture.
- Exclude Save-Data, private, state-changing, signed, and high-cost routes.
- Correct cache keys before counting an edge hit as safe.
- Set byte, origin, cancellation, analytics-noise, and navigation-benefit budgets.
- Ship a small cohort with a documented conservative-mode rollback.
Decision rule
Approve active speculation only when Save-Data and sensitive fixtures receive no unapproved request, public transfers remain in budget, and the measured navigation benefit exceeds the extra byte and origin cost.
Production verification checklist
- Save-Data fixtures show the intended exclusion in the actual network trace.
- Private and state-changing routes receive no speculative request.
- Public requests have correct purpose, cache, byte, and origin evidence.
- Real navigation, consent, cart state, analytics, and conversions remain correct.
Field notes
- Measure transferred bytes, not only request count.
- Retest on a real mobile browser because desktop throttling does not reproduce every data-saving behavior.
- Keep checkout, account, logout, preview, signed, and state-changing URLs outside speculation.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture. Perform destructive changes, upgrades, queue repairs, cache-policy changes, and schema changes on staging first. Promote only the smallest change that has a measured rollback point.
What evidence should be kept?
Keep component versions, stable fixture IDs, UTC timestamps, request or export evidence, expected and actual outcomes, the decision owner, rollback point, and final clean verification. Remove or redact personal data before sharing.
When is the work finished?
Finish when the canonical user path passes, downstream records reconcile, failure cases are understood, monitoring is active, and an established page links to the new guide with useful context.
Mistakes to avoid
- Changing production before preserving the current result, exact versions, timestamps, and a reproducible fixture.
- Treating one successful screen or request as proof that every queue, provider, report, browser, and customer path agrees.
- Removing logs, identifiers, or rollback evidence before the failure boundary and accountable owner are known.
- Testing only an administrator session instead of the roles, devices, consent states, networks, 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. State which measurements prove success and which observation window still remains.
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.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references