WordPress’s new speculative loading defaults signal a shift towards faster navigation but demand careful configuration

With the introduction of speculative loading features in WordPress 6.8, site owners can achieve faster navigation through prefetching and prerendering, but must balance speed gains with bandwidth and security considerations. The feature’s customisation and browser support highlight a nuanced approach to enhancing user experience while avoiding overreach.

WordPress’s speculative loading features have moved from niche optimisation to a built-in part of the platform’s performance story. With WordPress 6.8, the core software now outputs speculation rules for most logged-out front-end visits on sites using pretty permalinks, giving compatible Chromium-based browsers a chance to prefetch likely next pages before the click completes. The result can be a noticeably faster follow-up navigation, but the trade-off is that teams must be much more deliberate about what they let the browser guess. According to WordPress developer documentation and independent explainers of the feature, the configuration can be tuned for prefetch or prerender, with different levels of eagerness that change how quickly the browser begins work.

The practical distinction between prefetch and prerender matters. Prefetch retrieves a document early so the browser can shorten the wait on a later visit, while prerender goes further by preparing the page in the background so activation can feel almost immediate. The downside is that prerendering consumes more bandwidth, memory and CPU, and may do so for pages the user never opens. MDN and WordPress-focused guidance both stress that speculative loading is a hint, not a promise: unsupported browsers ignore it, and even supported browsers apply their own heuristics.

That makes the feature useful, but not universally safe. Articles on speculative loading in WordPress note that the performance upside is greatest when users follow predictable internal paths, such as from a post to related content or from a category page to a product page. In those cases, the next navigation can benefit from warmer HTML, scripts and layout data, which may improve measured Largest Contentful Paint and Interaction to Next Paint on the destination page. But the same sources warn that the benefits apply to the page the visitor chooses next, not necessarily to the first landing page from search or advertising.

The new default in core also does not remove the need for restraint. WordPress developer references document filters such as wp_speculation_rules_configuration, which let engineers alter the mode and eagerness, and exclude paths that should never be guessed. That matters for WooCommerce and similar builds, where cart, checkout, account and other state-changing routes can be exposed through links that look ordinary but should not be prefetched or prerendered. Performance documentation for the plugin ecosystem makes the same point: a site can easily create extra network traffic, trigger unnecessary server load, or even introduce behavioural bugs if speculation is applied too broadly.

The browser support picture is equally important for agencies and site owners deciding whether to go further than the core defaults. Perfmatters and MDN both note that the current ecosystem is concentrated in Chromium-based browsers such as Chrome, Edge and Opera, while Firefox and Safari do not support the same speculative loading approach. In practice, that means the feature can improve experience for a large share of users without breaking the rest, but it should never be sold as a universal instant-loading layer. It remains progressive enhancement, not a replacement for sound server response times, lean JavaScript and well-managed third-party code.

For that reason, the most defensible approach is selective use rather than blanket adoption. Core’s conservative defaults are generally the right starting point for editorial sites and blogs. More aggressive prerender settings may be justified when the site has strong internal navigation patterns, a reliable object cache, clean exclusions for transactional paths and enough traffic to benefit from warmer destination pages. Even then, teams should measure entry pages and internal navigations separately, because a feature that improves a second click can leave the first visit unchanged. As the WordPress and browser documentation makes clear, speculative loading is best treated as a navigation optimisation with explicit boundaries, not as a substitute for fixing slow landing pages.