WordPress 6.8 and newer can enable speculative loading without an extra plugin. Core emits a browser Speculation Rules API block for eligible front-end links, normally using conservative prefetching. The browser can fetch a likely next document before a visitor clicks it, reducing the wait after navigation.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
To turn it on, update WordPress, use pretty permalinks, test while logged out, and confirm that the page source contains <script type='speculationrules'>. If you need a settings screen, install the WordPress Performance Team’s Speculative Loading plugin and configure it under Settings → Reading → Speculative Loading. Use prefetch first; choose prerender only after checking bandwidth, JavaScript side effects, and personalized or state-changing URLs.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →What speculative loading does
Speculative loading uses the browser’s Speculation Rules API to start work on a possible next navigation. WordPress identifies links that may be visited and publishes rules telling a supporting browser whether to prefetch or prerender their destinations. The official WordPress Developer Resources description is: “The Speculation Rules API is a web API that allows to automatically prefetch or prerender certain URLs on the page, which can lead to near-instant page load times.”
With prefetch, the browser downloads the target document ahead of time. When the visitor clicks, the document may already be available, although the browser still has to perform the normal navigation and rendering work. With prerender, the browser prepares the destination more completely and can run JavaScript before the click. That can make a supported navigation feel almost immediate, but it also performs more work that may be discarded if the visitor chooses another link.
#1 Best Overall
This is a progressive enhancement, not a requirement for navigation. Browsers that do not implement the API ignore the rules and load pages normally. A WordPress site therefore remains functional when speculative loading is unavailable.
Requirements and WordPress defaults
Use WordPress 6.8 or newer
Native support was added in WordPress 6.8. On an older release, use the official Speculative Loading plugin if you want the feature and its settings interface without writing PHP. Keeping WordPress, themes, and plugins updated is still necessary because speculative loading does not replace ordinary performance, caching, or security maintenance.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesPretty permalinks are required for the core path
Core’s default rules are not emitted when a site does not use pretty permalinks. Open Settings → Permalinks, select a human-readable structure such as Post name, save, and then retest the front end. If your site must retain a non-pretty structure, the core default may remain absent and you should evaluate the plugin or a carefully scoped developer configuration instead.
Logged-out front-end requests are the starting point
WordPress core defaults to no speculative rules for logged-in requests. Check the site in a private window or another browser session where you are not authenticated. This avoids mistaking an administrator or editor view for the public behavior and prevents speculative requests from carrying the wrong personalized context.
Supported browsers are not universal
The plugin documents functionality in Chromium-based browsers such as Chrome, Edge, and Opera version 121 or newer. Safari and Firefox ignore the rules without breaking links, so visitors on those browsers simply receive no speculative-loading benefit. Treat browser support as an enhancement opportunity rather than a compatibility dependency.
Enable the WordPress 6.8+ core behavior
- Update WordPress. In the dashboard, go to Dashboard → Updates and install WordPress 6.8 or a newer supported release. Complete a backup and update test if your site has custom code or a staging workflow.
- Confirm the permalink structure. Go to Settings → Permalinks, use a pretty-permalink structure, and click Save Changes. Saving is important after changing the option because WordPress must refresh rewrite settings.
- Test as a public visitor. Sign out, open a private window, or use a separate browser profile. Visit a page that contains ordinary internal links. Do not use an admin screen for this check.
- Inspect the generated markup. View the page source and search for
speculationrules. You are looking for a block whose script type isspeculationrulesand whose JSON contains candidate rules. In browser developer tools, the same element appears in the document’s HTML. - Start with the core defaults. Leave the conservative prefetch configuration in place while you establish a baseline. Core’s conservative behavior begins close to a likely click and generally wastes less bandwidth and CPU than aggressive settings.
- Exercise representative links. Open the browser’s Network panel, preserve the log, and click several internal links. Look for activity associated with the destination before or during the click. Use the Performance panel when you need to see whether prerendered JavaScript or other client-side work runs before navigation.
If no rules appear, verify all three gating conditions: the site is running WordPress 6.8 or newer, the request is logged out, and pretty permalinks are enabled. A page-cache layer can also serve older HTML, so purge the relevant cache and repeat the source check.
Use the Speculative Loading plugin for a settings interface
The WordPress Performance Team’s Speculative Loading plugin is useful when a site is below WordPress 6.8 or when editors need to change the mode and eagerness without editing PHP. Its documented installation path is:
- Open Plugins → Add New in the WordPress dashboard.
- Search for Speculative Loading.
- Install the plugin published by the WordPress Performance Team and click Activate.
- Open Settings → Reading → Speculative Loading.
- Select the desired mode and eagerness, save the settings, and repeat the logged-out source and network checks.
The plugin defaults to prerender with moderate eagerness. That combination can improve perceived navigation speed, but it may perform substantially more work than WordPress core’s conservative prefetch behavior. On a busy site, begin with the least aggressive option that meets your goal and increase it only after monitoring requests and side effects.
Prefetch or prerender: which mode should you choose?
| Choice | What the browser does | Potential benefit | Main cost or risk | Good starting use |
|---|---|---|---|---|
| Prefetch | Downloads the target document ahead of navigation. | Shortens document-fetch time while limiting speculative work. | Consumes bandwidth and cache capacity for links that may never be clicked. | Most public content sites and any first rollout. |
| Prerender | Prepares the destination more fully and may run its JavaScript before navigation. | Can produce the largest perceived speed improvement on a supported click. | Higher CPU, memory, and bandwidth use; analytics, personalization, timers, or other scripts can run even when the visitor never clicks. | Stable, mostly public pages after side-effect testing. |
Choose based on more than the fastest possible click. Consider expected navigation speed, wasted bandwidth and CPU, JavaScript side effects, and whether the destination is dynamic or authenticated. A catalog or documentation site with cacheable public pages is a safer candidate than a dashboard, account area, checkout flow, or application whose scripts mutate state during startup.
Control eagerness
| Eagerness | Intent signal | Resource use | When it fits |
|---|---|---|---|
| Conservative | Starts close to an actual click. | Lowest waste among the available levels. | Default-style rollout, mobile audiences, expensive pages, or uncertain traffic patterns. |
| Moderate | Starts when the browser sees stronger intent, such as a hover. | More speculative requests than conservative mode. | Sites with reliable caching and links visitors commonly follow. |
| Eager | Starts on weaker intent signals. | Highest waste risk and the greatest chance of preparing pages that are never opened. | Only after measuring capacity, cache behavior, and script side effects on your own site. |
Eagerness is independent of mode. For example, conservative prerender is still prerender and can run destination JavaScript, while eager prefetch can still create a large volume of unused document requests. Change one variable at a time so you can attribute any change in server load or analytics.
Configure the feature with PHP
Theme and plugin developers should use WordPress’s documented filter rather than the private core implementation. The public filter was introduced in WordPress 6.8:
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
return array(
'mode' => 'prefetch', // 'prefetch' or 'prerender'
'eagerness' => 'conservative', // 'eager', 'moderate', or 'conservative'
);
} );Place site-specific code in a maintainable site plugin or a child-theme mechanism appropriate to your deployment, not in a way that will be erased by a parent-theme update. The returned values must be one of the documented modes and eagerness levels. Returning null disables speculative loading for that request, which is useful when a particular request context should not emit rules.
Additional rules can be added through the wp_load_speculation_rules action. Use that action for narrowly targeted additions, such as a controlled set of known public destinations. Avoid replacing core’s behavior wholesale unless you understand how every candidate is generated and have a test plan for exclusions, caching, and authenticated contexts.
WordPress’s internal WP_Speculation_Rules class validates rule modes, but it is marked private for core use. Plugin and theme authors should not build integrations that call that class directly; use the public filter and action instead.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Exclude sensitive and state-changing URLs
Speculation is inappropriate for destinations where a request could expose personalized data, consume a one-time token, or trigger a state change. Keep these URL categories out of prefetch and especially prerender:
- Checkout and payment pages.
- Cart and order-confirmation flows.
- Account, profile, and other highly personalized pages.
- Login and logout endpoints.
- Administration screens.
- Destructive actions such as delete, cancel, publish, or unsubscribe links.
- Forms and endpoints that mutate data when loaded or initialized.
The official plugin provides path exclusions through a documented filter. Use that mechanism to exclude whole URL patterns when a category is consistently unsafe. For an isolated link, add the no-prerender CSS class to opt that link out of prerendering. Review the generated rules after adding exclusions; an exclusion that exists in code but is not reflected in the emitted candidate list has not solved the problem.
Do not assume that a GET request is harmless simply because it is technically a read. A page can start analytics, personalization, reservation, or client-side mutation during prerender. Inspect forms, inline scripts, tag-manager triggers, and application boot code before enabling prerender on those routes.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Logged-in users and server capacity
Core does not emit speculative rules for logged-in requests by default. The plugin documents opt-in controls for all logged-in users or for administrators. Enabling those controls changes the capacity calculation: authenticated pages may bypass public caches, carry larger responses, and execute user-specific JavaScript.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteBefore opting in, measure origin requests, object-cache hit rate, response time, and memory or CPU headroom. Persistent object caching can reduce repeated database work, but it does not make every personalized response safe to prerender. Keep administration screens excluded even if another logged-in group is allowed to receive rules.
A practical rollout is to leave authenticated traffic disabled, verify anonymous traffic first, then test one controlled role or staging account. Compare ordinary navigation with speculative requests and watch for duplicate analytics events, unexpected API calls, and permission-sensitive content in browser caches.
How to verify that it is working
- Check the version or plugin. Confirm WordPress is 6.8 or newer, or confirm that the Speculative Loading plugin is active.
- Separate session types. Test a logged-out private window and a logged-in session independently. Record which behavior you expect for each.
- Confirm permalinks. Verify that pretty permalinks remain enabled after any migration or environment change.
- Inspect the rule block. In page source or developer tools, locate
<script type='speculationrules'>and inspect the candidate URLs, mode, and eagerness. - Watch the network timeline. Open the Network panel before hovering or clicking representative internal links. Check whether the destination request begins before the click and whether it is served from cache at navigation.
- Inspect performance traces. For prerender tests, use the Performance panel to identify JavaScript, API calls, analytics, or timers that execute before navigation.
- Test exclusions. Confirm excluded paths and links carrying
no-prerenderdo not appear as eligible candidates and do not start speculative requests. - Monitor after deployment. Compare origin request volume, cache-hit rate, bandwidth, response latency, analytics counts, and application logs before and after changing mode or eagerness.
Troubleshooting common failures
No speculationrules element appears
Check the WordPress version, pretty-permalink setting, and authentication state first. If all three are correct, purge page caches and inspect the uncached HTML. A security, optimization, or HTML-rewriting plugin may also be removing unknown script blocks; temporarily test with that transformation disabled in staging.
Rules appear but no request is visible
The browser may not support the API, the intent signal may not have been reached, or an extension or privacy setting may be blocking the behavior. Repeat the test in a current Chromium-based browser documented by the plugin, then use a clear hover or click on a normal internal link while recording the Network panel.
Recommended Free Tools
Server load rises after enabling the plugin
Reduce eagerness before changing anything else. If the site is using prerender, switch to prefetch; if it is moderate or eager, move to conservative. Recheck cache hit rate and exclude expensive, personalized, or low-probability paths. Do not judge the change from one page view: compare a representative period of traffic and origin metrics.
Analytics or application actions run twice
That behavior can result from prerendered JavaScript running before the visitor navigates. Audit page-load analytics, timers, API calls, and mutation code on affected destinations. Use prefetch, lower eagerness, or exclude those URLs rather than trying to suppress each side effect after it has already fired.
A link that should be excluded is still prepared
Verify that the exclusion matches the final URL and path, including trailing-slash and query-string behavior. For one link, confirm the no-prerender class is present in the rendered anchor and that stale cached HTML is not being served. Reinspect the emitted candidate list after clearing caches.
What performance improvement should you expect?
There is no responsible universal percentage for WordPress speculative loading. The result depends on browser support, cache state, page weight, network conditions, server capacity, the visitor’s actual next click, and whether the speculative request is reused. A prerender that is never visited is work without a navigation benefit, while a conservative prefetch that matches the next click can remove much of the document-fetch delay.
Measure your own site with the same templates, traffic mix, cache configuration, and device classes you care about. Use real navigation timings and origin metrics rather than assuming that a higher eagerness setting is automatically faster. The useful outcome is a lower delay for common, safe navigations without an unacceptable increase in wasted requests or client-side side effects.
Quick Recap
A low-risk rollout plan
- Update a staging copy to WordPress 6.8 or newer and enable pretty permalinks.
- Inspect core’s conservative prefetch output while logged out.
- List routes that are personalized, authenticated, transactional, destructive, or expensive, and exclude them.
- Test public article, category, and documentation links in a supported Chromium-based browser.
- Compare navigation timing, origin requests, cache hits, bandwidth, and analytics behavior with speculative loading disabled.
- Deploy to a small traffic slice or a low-risk period if your infrastructure supports staged releases.
- Only then evaluate the plugin’s moderate or eager settings, or prerender, and change one setting at a time.
- Keep authenticated and administration traffic disabled unless separate capacity and side-effect testing justify an opt-in.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
