WordPress 6.8 quietly merged Speculative Loading directly into core, built on the browser-native Speculation Rules API — and most site owners running a current WordPress version already have access to it without installing anything. The feature loads pages in the background before a visitor even clicks a link, so that by the time they do click, the page is already there.
How It Actually Works
Speculative Loading works in one of two modes, and the difference between them matters:
| Mode | What happens |
|---|---|
| Prefetch | Downloads a likely-next page’s HTML, CSS, and JS in the background and caches it — but doesn’t process or render it until the visitor actually navigates there |
| Prerender | Fully renders the page in a hidden background tab — styles, images, JavaScript, everything — so clicking through feels instant because the page was already built |
WordPress core defaults to prefetch with conservative eagerness out of the box — a deliberately cautious default that limits how aggressively it speculates. The dedicated Speculative Loading plugin from the WordPress Performance Team goes further, defaulting to prerender with moderate eagerness, and adds a proper settings UI under Settings > Reading to control the mode and how aggressively it speculates.
Why “Eagerness” Is the Setting That Actually Matters
Eagerness controls how confident the browser needs to be that a visitor will click a link before it starts speculatively loading it — a conservative setting only speculates on links the visitor is clearly about to click (like on hover, with a delay), while a more eager setting starts speculating much earlier, trading some wasted bandwidth for faster perceived navigation. This is the real tuning knob: too conservative and you barely notice the feature is on; too eager on a content-heavy site and you risk prerendering pages nobody clicks, wasting server resources on speculative requests that never pay off.
What to Actually Check Before Relying On It
- Confirm your WordPress version is 6.8 or later to have the core feature at all, or install the dedicated plugin for more control on any supported version.
- Be careful with prerender and any code that fires on page load — analytics pings, cart/session logic, or anything counting a “visit” can fire during prerendering before the visitor ever actually lands, double-counting or misfiring. The Speculation Rules API does account for this in modern implementations, but it’s worth verifying with your specific analytics setup.
- Start conservative on eagerness, especially on a WooCommerce store where speculative navigation touching cart or session state needs care.
- Measure real-world impact via Core Web Vitals field data rather than assuming it’s helping — the gain is felt in perceived navigation speed between pages, not in your initial-load LCP score.
This is a different lever than the loading-side work we’ve covered before — see fetchpriority: The One-Line Fix That Cuts LCP and Interaction to Next Paint: The Core Web Vital WordPress Sites Keep Failing for the other two-thirds of Core Web Vitals. Want your site’s speculative loading configuration reviewed? Get in touch.
Frequently Asked Questions
Do I need a plugin, or does WordPress core already do this?
WordPress 6.8+ includes basic prefetch support in core with no plugin required. The dedicated Speculative Loading plugin adds prerender support and a settings interface for finer control.
Will this break my WooCommerce cart or checkout?
It can, if analytics or cart-state code fires unconditionally on page load without checking whether the page is actually being viewed vs. prerendered in the background. Test checkout flows specifically after enabling prerender.
Is prerender always better than prefetch?
Not necessarily — prerender uses more resources per speculative load since it fully renders the page, so it’s a genuine trade-off between server/bandwidth cost and perceived speed, tuned by the eagerness setting.
Featured image: original illustration.