WordPress speculative loading: review prefetch and prerender before changing defaults

Separate prefetch, prerender and returning to history

MDN’s Speculation Rules API guide distinguishes preparing a future document from loading the resources of the page already being read. Prefetch retrieves a prospective document; prerender prepares the page more fully, including resources and JavaScript. Browser availability is limited, and both involve resource costs.

Returning to a previously visited page is another investigation, covered by our back-button state guide. Do not label every unexpectedly quick page or old screen a speculative-load problem.

For the fictional archive, preparing a likely next chapter is different from preparing every search result or an account action. Define the intended journey before choosing a mode or eagerness setting.

Check current defaults instead of an old tutorial

The current WordPress default-configuration reference states prefetch with conservative eagerness. Hosting defaults can be overridden; an explicit configuration supplied through a filter takes precedence. Do not assume that cache detection automatically switches a current installation to moderate behavior.

The configuration reference describes default eligibility for logged-out visitors on sites with pretty permalinks, subject to filtering. An administrator’s logged-in screen may therefore be the wrong observation for a public reader journey.

Record WordPress version, relevant host or optimization integration and the actual emitted page rules. The private default helper documents core behavior; it is not an integration API to call from copied theme code. Use maintained configuration surfaces owned by the responsible developer or provider.

Find the rules the browser really receives

Inspect the exact public starting page in a clean logged-out session and a browser that supports the feature. Confirm the address and final response. Ask which component owns the rule set; adding another optimization plugin without that inventory may create overlapping behavior.

Chrome’s debugging guide explains Application views for rules, candidates, statuses and reasons. Prefetch can be inspected through Network; prerender uses a separate renderer that needs its corresponding inspection context. Reading only the current page’s Network list can miss that distinction.

Record the candidate address, selected rule and outcome before navigating, then whether the eventual navigation used that preparation. A rule existing in the document is not proof that the browser fetched anything, and a ready candidate is not proof that a person visited it.

Retain core safeguards and add specific exclusions

The current rule-generation reference shows base path exclusions, nofollow link exclusions and no-prefetch/no-prerender opt-outs relevant to the selected mode. Those safeguards do not discover every custom action your site may expose. The generator is private core implementation, not a supported function to invoke directly.

WordPress provides a public href-path exclusion filter for additional paths. Have the maintainer apply installation-specific exclusions through the supported integration, preserving base protections. A copied shop-path list is not enough for an unrelated site’s membership or custom routing.

Check the resulting rules on the actual pages and verify that normal deliberate navigation still works. Do not repurpose nofollow across all editorial links as an unexplained universal workaround. Keep navigation semantics, optimization selection and application authorization as distinct responsibilities.

Review work that should wait for activation

Prerender requires a deeper application review than fetching a document. Chrome’s prerender guide documents document.prerendering, the prerenderingchange event and activationStart timing context. These let implementers distinguish preparation from activation and defer work that depends on a real visit.

Ask the owner of measurement, notifications and other integrations how each behaves before and after activation. A browser lifecycle facility does not prove that every third-party script uses it correctly. Do not count a prepared candidate as a reader engagement or conversion merely because a request appeared in a log.

Keep review data synthetic and use an isolated environment for consequential integrations. The acceptance condition is deliberate intended behavior; an attractive timing number cannot excuse duplicate messages, premature state changes or misleading reports.

Check freshness and the no-speculation route

Test an ordinary direct visit and the prepared navigation to the same destination. Compare current content, account boundaries and essential controls, then check a browser or state where speculation is unavailable. The guide’s purpose is progressive improvement rather than a second version of the site that only works after a special navigation.

If personalized content is involved, use the separate private-response cache review. If an installed application retains older assets, the service-worker update guide investigates that different layer. Do not change several caching systems to explain one candidate’s status.

Make a scoped decision and keep the evidence

For the fictional archive, accept a narrow chapter-to-chapter configuration only after useful destinations, exclusions, activation and fallback behavior are checked. Compare representative journeys under a consistent setup; do not promise a percentage gain or infer a real-reader improvement from one successful laboratory navigation.

Keep the actual rules, configuration owner, checked routes, observed outcomes and untested integrations. If a regression appears, revert the specific authorized configuration through its maintained control and repeat the affected journey. A canceled speculative request alone is not a defect; a sensitive action performed before the reader chooses it is a substantive problem to resolve.