Loading Now

WordPress Speculative Loading: What It Does and How to Configure It

Have you ever clicked on a link and noticed how quickly the next page loads? That brief moment where the page just “materialises”? This isn’t magic but a feature known as speculative loading, which has been enabled by default since WordPress 6.8 on countless WordPress sites.

In essence, your website can provide the browser with a hint about which page a user is expected to navigate to next. The browser then starts retrieving that page even before the click happens. If the user proceeds, the page is already loaded and ready to view. If they don’t, it may result in some unnecessary server load and bandwidth consumption.

This article explains what speculative loading entails, why prerendered pages appear instant, and the specific settings that WordPress 6.8 initiated by default. Additionally, we will cover practical steps: how to assess your website, configure the official plugin, and some crucial warnings about potential issues, particularly in your analytics.

Let’s dive straight in!







What precisely is speculative loading?

Speculative loading is a performance strategy where the browser retrieves a page ahead of time, anticipating user navigation based on certain indicators. This is facilitated by the Speculation Rules API, which allows a website to inform the browser, via a compact JSON format, which URLs to load and when to start this process.

The API comes in two variations:

  • Prefetch: This method downloads the HTML of a page in the background, enabling the browser to render it immediately when a user clicks, skipping the waiting time.
  • Prerender: This approach takes it further by fully rendering the page in a hidden, tab-like mode, complete with styles, images, and JavaScript. When the user clicks, the prerendered page is instantly shown.

If you’ve previously encountered older WordPress plugins that used tags upon hover, this is an advanced iteration of that concept: the logic resides within the page itself, and the browser determines when to implement it.

What makes a prerendered page feel immediate

According to Chrome’s documentation, a prerender essentially opens the page in an invisible background tab. All the resource-intensive tasks (like downloading files, parsing HTML, and executing scripts) occur while the user interacts with the current page or hovers over a link. Thus, when they click, the hidden page instantly becomes visible.

This directly impacts Core Web Vitals: the Largest Contentful Paint (LCP) time significantly decreases because the rendering has already taken place. Layout shifts happen before the user sees the page, and interactions are seamless as scripts have already executed before any user action.

It’s important to clarify that speculative loading does not enhance server speed or lighten page weight; it merely shifts the workload to an earlier stage, during the time that the browser would typically be idle. If the user decides not to click, the prefetch or prerender contributes to wasted bandwidth and unnecessary server requests.

According to the WordPress core team’s development notes for the 6.8 release, sites with this feature enabled saw an approximate 1.9% increase in LCP passing rates (based on data from HTTP Archive and Chrome User Experience Report covering over 50,000 sites), with over 8% of Chrome navigations already leveraging speculation rules. While these figures may seem modest, this feature delivers a notable improvement at no additional cost.

Browser support: Who benefits and who misses out

Here’s an aspect that marketing materials often overlook: the Speculation Rules API is a feature exclusive to Chromium. It operates in Chrome, Edge, and Opera (version 121 and later, as per the official plugin documentation). However, users of Safari and Firefox do not have this functionality available and thus experience the traditional, non-speculative loading method.

Furthermore, even within Chrome, the speculative loading is not guaranteed. The browser intentionally avoids prefetching and prerendering in scenarios where it would be unhelpful, such as when:

  • The user has enabled Save-Data, is using a battery saver in low battery mode, or is on a device with limited memory.
  • The “Preload pages” setting is disabled (some privacy-focused extensions, like uBlock Origin, may turn this off).
  • The page is opened in a background tab.

What WordPress 6.8 offers right from the start

With the release of WordPress 6.8 (“Cecil” in April 2025), the Speculative Loading feature from the WordPress Performance Team was integrated directly into the core of WordPress. If your site is running version 6.8 or later, speculative loading is likely already activated without any manual settings or checkboxes.

The default configurations are set to be cautious:

  • Mode: prefetch. WordPress retrieves the HTML of the forthcoming page beforehand but does not prerender it.
  • Eagerness: conservative. Prefetching initiates once the user begins pressing a link, occurring merely fractions of a second before the navigation occurs. This brief advance notice aids in avoiding unnecessary requests.
  • Frontend only, applicable to logged-out visitors only. Admin pages and logged-in sessions are automatically excluded.
  • Pretty permalinks required. If your website uses plain ?p=123 permalinks, this feature remains disabled, as URLs with query parameters cannot be reliably identified from action URLs that perform operations when accessed.

The core also automatically excludes potentially risky URLs: anything in the /wp-admin/ directory, the login page, links containing a _wpnonce security token, and follow links. For granular control, the Advanced panel in the editor accepts two CSS classes: -prefetch for opting out of prefetch for specific blocks, and -prerender to opt out of prerendering alone.

Note: The exclusion for logged-in users has greater significance than it appears: in membership sites, forums, and e-commerce platforms where a majority of frontend traffic consists of signed-in users, core’s speculative loading doesn’t come into play by default. The plugin (as discussed in the next section) can include logged-in users, provided that persistent object caching is established first.

How to set up speculative loading in WordPress

Step 1: Verify if it’s already operational (it likely is)

Open any front-facing page of your website in Chrome while logged out (an incognito window is a good option), view the page source, and search for speculationrules. If you see a JSON section that includes prefetch and conservative, WordPress core is functioning as anticipated.

For a live update, check the Speculative Loads section within Chrome DevTools’ Application panel to see which URLs are currently being speculated upon and the reasons for any successful or cancelled speculations.

PRO TIP: Keep this panel open and hover over some internal links: with the core’s conservative default, the prefetch will trigger as you start pressing the mouse button, whereas the plugin’s prerender mode activates upon hover.

Step 2: Install the Speculative Loading plugin for comprehensive control

The defaults provided by the core are secure but relatively modest. To access a settings screen and the more powerful prerender mode, install the official Speculative Loading plugin from the WordPress Performance Team (previously known as “Speculation Rules”; the core incorporation was derived from it).

In your dashboard, navigate to Plugins → Add New, search for “Speculative Loading,” then install and activate the plugin developed by the WordPress Performance Team.

Step 3: Select your mode, eagerness, and audience

Proceed to Settings → Reading and scroll to the Speculative Loading segment. There, you will find three sets of options: Speculation Mode (prefetch or prerender), Eagerness (the timing of the browser’s action), and User Authentication Status (determining who receives speculative loading benefits). The default settings for the plugin are set to prerender with moderate eagerness for logged-out visitors, marking a significant improvement from the core’s prefetch-only setup:

The eagerness setting determines the balance between speed and potential wastage:

EagernessActivation TimingBest For
ConservativeWhen pointer or touch is pressed down (the action to click has pretty much commenced)Busy Servers, heavier pages, minimal wastage
ModerateAfter hovering over a link for around 200 milliseconds on desktopMost sites; an ideal balance between lead time and accuracy
EagerAfter roughly 10 milliseconds of hovering (desktop)Lightweight, static pages where additional requests are inexpensive

Chrome limits concurrent speculative actions to two for interaction-based eagerness settings, meaning that a link-heavy page will not trigger multiple prerenders. If your pages are bulky or your hosting is measured, it is advisable to start with conservative settings and monitor your server logs before increasing the intensity.

Step 4: Exclude URLs from prerendering that shouldn’t be

Most WordPress pages are suitable for prerendering, but you should consider links that change state with a visit: customised logout links, “mark as favourite” URLs, vote counters. WordPress already excludes URLs with query parameters, follow links, and nonce-protected links, which typically covers the usual risks. For everything else, you have three options:

  • The -prerender CSS class can be applied to a link or block (this will skip prerendering, while still allowing prefetching).
  • The wp_speculation_rules_href_exclude_paths filter within core to exclude entire path patterns such as /cart/* from speculative loading.
  • The wp_speculation_rules_configuration filter, which sets the overall mode and eagerness in the code directly without installing the plugin (the settings of prerender and moderate eagerness correspond to the plugin’s defaults).

When in doubt, it’s better to exclude from prerendering only; prefetching a slightly dynamic page is typically harmless, but executing its JavaScript in a hidden tab could lead to issues.

What could potentially break (and what won’t)

Analytics pose a significant concern. A prerendered page executes JavaScript before anyone views it, leading to instances where if a user does not click, that visit does not get registered. A simplistic tracking setup might report a page view erroneously or register it twice: once during prerender, and again upon activation. Most analytics solutions like Google Analytics can identify prerendering and hold back page view beacons until the page is activated. Therefore, for the majority of sites, this won’t pose an issue. If you utilise custom tracking scripts, ensure they validate document.prerendering and await the prerenderingchange event before executing.

Personalisation should undergo testing. A prerendered page captures its state at the moment speculation begins, so changes like cart updates or logouts elsewhere may not be reflected accurately. Although most such actions necessitate fresh navigation, if your site heavily relies on personalisation, test the essential journeys.

Your server workload increases. Each prefetch and prerender counts as a legitimate request to your server. This is manageable for cached, anonymous pages (which is why the core limits the feature to logged-out users). However, if you’re using dynamic, uncached pages with an eager configuration, you may increase requests unnecessarily for visits that may not culminate. Monitor bandwidth and PHP worker usage for a week following any adjustments.

What won’t cause any issues include: visitors using Safari and Firefox, users with ad blockers or data-saver modes, and authenticated members. The fallback scenario here simply results in “nothing occurs,” as opposed to “something breaks.”

Final thoughts

Speculative loading is one of the few performance features that is both beneficial and almost free to implement:

  • WordPress 6.8 and later versions are equipped to prefetch internal links for logged-out visitors, conservatively, without needing configuration.
  • The official Speculative Loading plugin provides an upgrade to full prerendering capabilities along with settings access under Settings → Reading.
  • Chromium browsers (Chrome, Edge, Opera) perform the processing, while users with other browsers experience the standard loading method without additional complications.
  • Analytics platforms like Google Analytics accommodate prerendering out of the box; however, custom tracking implementations require a prerender check.

Think of it like a finishing coat on a paint job; if your pages are slow initially, focus on the core principles in this guide on how to enhance the speed of WordPress with five simple strategies, and then allow speculative loading to provide an even swifter experience on an already efficient site.

Have you noticed any improvements since the advent of WordPress 6.8, or have you adjusted the settings using the plugin? We’d love to hear from you in the comments below!

Well done! You’ve completed the article!

Share this content:


Discover more from Qureshi

Subscribe to get the latest posts sent to your email.

Discover more from Qureshi

Subscribe now to keep reading and get access to the full archive.

Continue reading