WordPress 7.1 adds ways to configure speculative loading through environment variables or PHP constants. That helps managed platforms and deployment pipelines, but it also creates another source of truth that can disagree with plugin settings, filters, cache variants, and the HTML a visitor actually receives.
Use this for hosts, DevOps teams, agencies, and site owners that configure speculative loading differently across local, staging, preview, and production environments.
Quick answer
Choose one documented owner for mode, eagerness, and URL exclusions. Set environment values before WordPress loads, purge every HTML cache layer, fetch representative pages anonymously, and inspect the emitted speculation rules. Test eligible links, excluded links, checkout, login, search, and personalized routes before enabling broader behavior.
What to check first
- Inventory plugin settings, wp-config constants, environment variables, filters, and host-level injection that can affect speculation rules.
- Record the intended mode and eagerness for local, staging, preview, and production.
- Fetch uncached HTML and identify the exact speculationrules script delivered to anonymous visitors.
- Test excluded routes such as wp-admin, login, cart, checkout, account, search, preview, and personalized query strings.
- Compare origin, page cache, CDN, and browser output after every configuration change.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Choose the configuration owner | Inventory plugin settings, wp-config constants, environment variables, filters, and host-level injection that can affect speculation rules. | The effective mode and eagerness match the approved environment record. |
| Document environment values | Record the intended mode and eagerness for local, staging, preview, and production. | Origin and CDN HTML contain the same intended speculation rules. |
| Purge HTML cache layers | Fetch uncached HTML and identify the exact speculationrules script delivered to anonymous visitors. | Transactional, private, preview, and personalized routes remain excluded. |
| Inspect emitted rules | Test excluded routes such as wp-admin, login, cart, checkout, account, search, preview, and personalized query strings. | Real-user performance and conversion monitoring show no harmful change. |
Why this usually happens
- Configuration values can be loaded before plugin code and silently override a dashboard expectation.
- Full-page and CDN caches can keep old speculation rules after the source value changes.
- A broad URL pattern may include transactional or personalized routes that should remain excluded.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
# Example inventory, not a copy-paste configuration
wp config list | grep -i speculat
printenv | grep -i speculat
curl -sS https://example.com/ | grep -A8 -B2 'speculationrules'
curl -sS -I https://example.com/checkout/
# Record origin and CDN cache headers with the effective rule.
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 |
|---|
| Environment | Production constant differs from staging | Each environment emits the documented rule after cache purge |
| Eligible link | Same-origin public article | The link matches the intended rule and does not trigger errors |
| Sensitive route | Cart, checkout, account, login, preview | The route remains excluded from speculative navigation |
| Conflict | Plugin setting and environment override disagree | The effective owner and precedence are documented and observable |
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.
- Choose the configuration owner
- Document environment values
- Purge HTML cache layers
- Inspect emitted rules
- Test exclusions and conversions
Decision rule
Do not broaden speculative loading when the effective configuration cannot be explained, sensitive routes match, cached variants disagree, or performance gains come with duplicate requests or conversion regressions.
Production verification checklist
- The effective mode and eagerness match the approved environment record.
- Origin and CDN HTML contain the same intended speculation rules.
- Transactional, private, preview, and personalized routes remain excluded.
- Real-user performance and conversion monitoring show no harmful change.
Field notes
- Save the raw HTML response alongside the environment value and cache status.
- Test logged-out traffic first because public HTML caches usually serve that audience.
- Measure navigation and conversion behavior before increasing eagerness.
Questions teams ask during testing
Why use environment configuration?
It lets deployment and hosting teams define behavior consistently without editing settings manually on every site.
Why can two visitors receive different rules?
Page-cache variants, CDN state, authentication, and environment-specific configuration can produce different HTML.
Does a rule in HTML prove better performance?
No. It proves delivery. Performance and business outcomes still need field measurement.
Mistakes to avoid
- Do not assume the dashboard displays the effective production value.
- Do not test before purging page and CDN caches.
- Do not include checkout, account, login, preview, or personalized URLs in broad rules.
- Do not increase eagerness without measuring request and conversion behavior.
What to tell the client or owner
Share the environment, configured value, source owner, page URL, raw speculationrules block, cache headers, visitor state, matched link, and observed request behavior.
When HandL WP should help
HandL WP can identify every speculative-loading configuration owner, validate public HTML across cache layers, test route exclusions, and monitor performance and conversion outcomes.
If this is active on a production site, verify WordPress speculative loading.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references