By Greg Nowak. Last updated 2026-06-24.
WordPress 6.8 brought speculative loading into core, which is a sensible win for perceived speed. The default is intentionally cautious: logged-out frontend users get conservative prefetching, and only when they have already started to click a link. That is a useful baseline. It is not a green light to prerender every page that matters commercially.
The difference is easy to underestimate. Prefetching asks the browser to download the next document early. Prerendering goes further: the browser loads the page, renders it, and can run its code before the visitor actually lands there. When it works, the next page can feel instant. When it is enabled too broadly, it can touch carts, account state, analytics, personalization, and server capacity before anyone notices.
Core is cautious; the plugin is more operational
WordPress core’s default behavior is designed to work safely at scale. It excludes logged-in users, skips sites without pretty permalinks, and avoids URLs with query parameters. Developers also get controls: URL path exclusions, filters for mode and eagerness, and block-level classes such as no-prefetch and no-prerender.
The Speculative Loading plugin has a different profile. It defaults to prerendering with moderate eagerness, adds a Settings > Reading interface, and can be configured for frontend logged-in users if the server can carry the extra work. That makes it useful, but it also makes QA non-negotiable. The plugin gives teams a much shorter path to stronger behavior than core enables by default.
The first audit is about unsafe URLs
The first review should not be a speed test. It should be an unsafe-URL audit. WordPress and MDN both point to the same risk: URLs that change state through a GET request. Add-to-cart links, logout links, language switchers, sign-in flows, usage counters, favorites, and server-side conversion triggers can all become risky if an early load performs work that should only happen after a real navigation.
WordPress treats this as something themes and plugins need to handle. Query-string action URLs are mostly covered by the default exclusion, but rewritten URLs still need explicit path patterns. In core, wp_speculation_rules_href_exclude_paths can exclude paths such as cart areas. In the plugin, the FAQ points to plsr_speculation_rules_href_exclude_paths. For individual blocks or links, no-prerender is useful when prefetch is acceptable but prerender is not. Use no-prefetch when the link should be left out completely.
| Area | What to check | Control | Decision point |
|---|---|---|---|
| Cart and checkout | Cart pages can be prerendered before an item is added, or an action URL can run too early. | Use POST for state changes, exclude cart and checkout paths, and verify add-to-cart behavior after activation. | Stay with conservative prefetch unless cart state remains correct under prerender. |
| Login, logout, account, membership | User-specific pages can show stale state after login, logout, or settings changes. | Exclude sensitive paths or refresh state on activation with client-side checks. | Do not prerender until state changes are handled deliberately. |
| Analytics and conversion scripts | Page views or events may fire before the page is visible if the setup is not prerender-aware. | Delay custom analytics until activation with document.prerendering or prerenderingchange; verify provider behavior. |
Ship only when reporting matches real navigations. |
| Cache and server capacity | Browsers may spend bandwidth, memory, CPU, and cache resources on pages the user never visits. | Measure prerender requests, activations, hit rates, cache behavior, and logged-in load. | Increase eagerness only when the measured gain justifies the extra work. |
Analytics needs activation-aware testing
Prerendering is not just faster fetching. Client-side code can run while the page is still hidden. Chrome’s documentation says some analytics providers, including Google Analytics, delay until activation by default. That is helpful, but it does not cover every tag manager rule, custom event, A/B test, personalization script, or WordPress-specific tracking setup.
The practical test is to identify prerendered pages and activated prerenders. Chrome and MDN point to document.prerendering, the prerenderingchange event, and a non-zero PerformanceNavigationTiming.activationStart. Those signals let a team delay analytics initialization, label prerendered navigations in reporting, and compare business metrics against normal navigations.
Personalization deserves the same attention. MDN’s examples include stale state around sign-in status, preferences, and carts. If a visitor adds a product with JavaScript after the cart page has already been prerendered, the activated cart can be wrong unless the page refreshes or synchronizes state on activation. On a commercial WordPress site, that is not an edge case to hand-wave away. It affects checkout confidence.
Cache capacity is part of the release decision
Speculative loading is a browser hint, not a promise. Browsers can ignore it because of user settings, memory constraints, data-saver modes, battery conditions, or internal limits. Chrome also caps active speculations, and canceled prerenders may still have consumed resources. So the business case has to come from observed hit rates and Core Web Vitals impact, not from assuming every suggested page will be ready instantly.
The server side matters just as much. The plugin notes that logged-in frontend speculation is only sensible if the server can handle the extra load, with persistent object caching given as one example. That should trigger capacity testing, not guesswork. A cached brochure page and a personalized account page are different workloads. A product page may be a good prerender candidate for logged-out users and a poor one for logged-in customers if it bypasses cache or triggers expensive personalization.
A safer rollout pattern
Start with the WordPress 6.8 default and map risky paths before increasing eagerness. Cover cart, checkout, login, logout, account, language, preference, conversion, and personalized areas. Add path exclusions and block or link classes where needed. Then test analytics activation, cart freshness, login state, browser fallback behavior, and server or cache impact. Only after that does it make sense to compare LCP, Core Web Vitals, conversion reporting, and hit rates under stronger settings.
This is a good fit for a focused technical QA engagement. Greg can map unsafe URLs, add prefetch and prerender exclusions, validate analytics activation, review whether cache capacity supports more speculation, and measure whether the performance gain justifies the complexity. The point is not to switch off a useful WordPress feature. It is to make sure a speed optimization does not quietly change checkout behavior, reporting quality, or infrastructure load.
Related on GrN.dk
- WordPress 7.1's Media Pipeline Needs a Real Plugin and CDN Test Pass
- The 2026 WordPress Plugin Exploit Drumbeat Makes Plugin Inventory and Incident Response Paid Work
- WordPress 7.0's React 19 Upgrade Makes Custom Block QA a Paid Compatibility Job
Need help with this kind of work?
Plan a speculative loading QA review Get in touch with Greg.