The Speculation Rules API allows a browser to preload—or even prerender—pages that a visitor is likely to open next. For a well-targeted site, this can make browsing nearly instantaneous and improve Core Web Vitals. For an SME project, the benefits are real, but the rules need to be clearly defined to avoid wasted bandwidth, skewed analytics, and unexpected costs.
What specific changes does the Speculation Rules API bring?
The Speculation Rules API is a web API—that is, a browser feature—designed to anticipate future navigation. Instead of waiting for a user to click a link, the site can specify in advance which pages should be preloaded.
Today, two actions matter most to a decision-maker. The prefetch Download the HTML document of a probable page. The prerender Goes a step further: The browser loads and renders the page in the background—including JavaScript—before the user actually views it.
The business case is simple. Well-timed preloading reduces wait times. Well-timed pre-rendering can make it seem like the page loads instantly. Chrome indicates that pre-rendering can produce an LCP close to zero, reduce certain visual lags during loading, and improve the INP as long as the loading process is complete before user interaction.
LCP (Largest Contentful Paint) measures the time it takes to display the main visible content. INP (Interaction to Next Paint) evaluates responsiveness following a user action. These metrics are part of the Core Web Vitals, which are often monitored in SEO audits and UX ; if your site is already slow, start by figuring out How Google Updates Respond to Quality Signals.
Prefetch, prerender, prerender_until_script: three levels of anticipation
Visit prefetch is the most conservative setting. The browser fetches the future document but does not render it as a full page. This is useful for a category page, a follow-up article, or a product page that is frequently viewed after a given page.
Visit prerender is more powerful, and therefore riskier. The page is loaded and rendered before the click, along with its scripts, resources, and state. According to MDN, a pre-render consumes approximately the same resources as a render in a , which quickly becomes cumbersome on mobile devices or on pages with a lot of content.
A third action, prerender_until_script, has been marked by Chrome as experimental and part of the origin trial since January 2026, starting with Chrome 144. The release notes for Microsoft Edge 146 also mention it. Honestly, this option is only justified for technical teams capable of keeping up with browser updates and accepting a certain degree of instability.
The Speculation Rules API is still marked as “Limited availability” and “Experimental” by MDN in 2026. It works primarily within the Chromium ecosystem, including Chrome, Edge, and Opera. Safari and Firefox should not be assumed to be supported in a project’s specifications.
| Approach | What the browser does | Expected gain | Main risk | Reasonable Use Cases |
|---|---|---|---|---|
prefetch |
Download the "Future" document | Faster navigation | Bandwidth is wasted if targeting is poor | The following articles, pages that are very likely to be relevant |
prerender |
Loads and renders the entire page | Page loads almost immediately after activation | Scripts, analytics, or resources running too early | A short and predictable journey |
prerender_until_script |
Partial pre-rendering up to the script | Promising but experimental | Compatibility and Maintenance | Supervised Testing on an Advanced Project |
How do you preload pages using the Speculation Rules API?
Rules can be declared directly on the page using a tag . They can also be sent via an HTTP header Speculation Rules, which points to an external JSON file; Chrome specifies alors that the resource must be served with the type application/speculationrules+json.
For a project manager, the point isn't to choose an elegant syntax. The real issue is targeting. Preloading every page in a menu just because it's technically possible is a bad idea: you increase network usage without guaranteeing any noticeable benefit.
Chrome recommends limiting pre-rendering to one or two pages at most. The browser also applies its own limits based on the urgency level, known as eagerness, which indicates whether the rule is triggered early or only after an fort signal, such as a hover or the start of a click.
In the projects we’re working on, we often see a very cost-effective approach: start with a conservative rule covering two or three common transitions, measure the results, and then scale up. An online store can target the most likely product page from a list. A media outlet can target the next article. A B2B site can load the contact page only after the user has visited an offer page.
- Identify the most common user paths in Matomo, Google Analytics 4, or server logs.
- Exclude sensitive pages: shopping cart, account, checkout, and pre-filled forms.
- Test for abord
prefetch, then make a reservationprerenderwith pages that are really predictable. - Check the effects in Chrome DevTools, under the "Application" section, then "Speculative loads."
- Measure LCP, INP, conversions, and server usage before scaling up.
WordPress 6.8: A Simpler Way to Enter Data, but It's No Magic Trick
WordPress 6.8 introduced speculative loading into the CMS core in 2025. Make WordPress Core states that the core includes a default rule that is conservative by design, and that developers can add their own rules via wp_load_speculation_rules.
The WordPress “Speculative Loading” plugin also supports the Speculation Rules API and targets Chromium-based browsers version 121 or higher, such as Chrome, Edge, and Opera. Its documentation states that speculative loading is enabled by default only for unauthenticated users, since unauthenticated pages are generally easier to cache and more efficient to preload.
This distinction is crucial. A WordPress showcase site with server-side caching, Cloudflare CDN, and stable public pages is a good candidate. An extranet, a complex WooCommerce site, or a members-only area with customized content requires more caution.
The WordPress features and filters available in 2026, such as wp_speculation_rules_configuration, wp_get_speculation_rules(), WP_Speculation_Rules or exclusion filters, allow you to refine the processing. From the agency’s perspective, the natural tendency is to treat these settings as a performance feature, not just a checkbox in the admin panel.
If your project already relies on a large number of extensions, you should also examine the entire chain: page cache, CDN, cookie consent, ad scripts, marketing tags, and security. The risks are similar to those encountered in architectures connected to multiple third-party services, a topic closely related to Invisible vulnerabilities on the API side when events do not occur at the expected time.
Measured gains: promising, but context-dependent
Public case studies provide useful performance metrics. Google Search has been using prefetching via Speculation Rules on Android since October 2022 and has rolled it out to desktop through September 2024. The A/B test results reported by Chrome indicate, depending on the release, a desktop improvement of 7.6 ms on FCP and 9.5 ms on LCP, followed by another LCP improvement of 58.6 ms with Chrome for desktop.
These numbers may seem modest. But on the scale of Google Search, they matter. For an SME, they show above all that prefetching alone isn’t a magic wand if the page is already fast or if the next click is hard to predict.
The results become more meaningful with pre-rendering. A Ray-Ban case study published on web.dev in 2024 reports a 13.1% decrease in the bounce rate and a doubling of the conversion rate after using prerendering with the Speculation Rules API. A Monrif study from early 2025, combining Speculation Rules prerender and bfcache, shows a 17.9% reduction in LCP and an 8.9% improvement in engagement.
The bfcache, or backward cache, is a browser cache that keeps a page ready until a user navigates back or forward. It works in tandem with pre-rendering, since much of the perceived slowness stems from back-and-forth navigation between pages. This is also where modern interfaces—such as transitions between views—can enhance technical performance; this topic ties into the approaches described regarding the View Transitions API if your site uses it.
A common pitfall: confusing perceived speed with the actual speed of the infrastructure. Pre-rendering can hide a slow page after it’s loaded, but it doesn’t always reduce server load. It can even increase it if pages are pre-rendered but never actually viewed.
Budget, Timelines, and Trade-offs for an SME Project
On a recent WordPress installation, an initial clean test can take anywhere from half a day to two days if the theme is standard, the cache is properly configured, and the navigation paths are simple. For an e-commerce site or a site with advanced tracking, however, you should plan on three to six days, since you’ll need to exclude high-risk pages and verify events.
In France, depending on the service provider, the cost of implementing best practices on an existing website typically ranges from €500 to €2,500 (excluding tax) for a basic audit, implementation, and acceptance testing. A more comprehensive performance optimization project—including Web Vitals, CDN, caching, images, JavaScript, and before-and-after measurements—can cost between €3,000 and €10,000 (excluding tax), depending on the technical debt.
With this budget, it’s best not to treat the Speculation Rules API as a standalone measure if the site is already loading 3 MB of unnecessary JavaScript. The best return on investment often comes from reducing abord—which slows down all pages—and then preloading the two navigation elements that really matter.
Compatibility also requires a trade-off. Since the API isn't available everywhere, it must enhance the experience for compatible browsers without degrading the experience for others. This is a gradual improvement: Chrome and Edge benefit from it, while other browsers continue to function as usual.
When it comes to SEO, stay pragmatic. Recent reliable sources mainly emphasize the waste of resources and bandwidth that results from poor targeting, not a proven direct impact on Googlebot’s crawl budget. If your goal is visibility, also focus on content, structured data, and editorial consistency; the Schema.org data that is useful for understanding the pages can contribute to a performance project.
The technical pitfalls that non-technical people discover too late
The first risk involves analytics. During pre-rendering, a page already exists in the background, but the user hasn't seen it yet. The Google Codelab notes that Google Analytics and Google Publisher Tag automatically delay certain actions until the page is activated, but other providers or custom scripts may not do so.
Possible consequences: inflated page views, ad pixels triggered too early, skewed A/B tests. For a marketing team, this is a problem. You’re making decisions based on tainted data.
Another limitation: cross-site rendering of pages. Chrome indicates that same-site rendering is the default behavior. Cross-site same-site rendering requires the target to explicitly accept it using the header Supports-Loading-Mode: credentialed-prerender. Cross-site pre-rendering is currently not possible.
Simply put: you cannot freely embed just any page from a third-party domain. If your booking tunnel, payment system, or configurator is hosted elsewhere, you’ll need to check the architecture. The same applies to certain misaligned subdomains.
Pages that rely on user state deserve special attention. Shopping cart, customer account, personal dashboard, dynamic quotes, cookie consent—anything that depends on a session must be excluded or handled with care. Instant navigation isn’t worth a shopping cart error or data displayed at the wrong time.
Defining the scope of this type of project early on helps avoid most unpleasant surprises: page selection, exclusion rules, before-and-after measurement, and then phased rollout. This is often where an outside perspective can save time, especially when performance, SEO, hosting, and tracking intersect.
FAQ on the Speculation Rules API
Does the Speculation Rules API work on all browsers?
No. In 2026, MDN classified encore as having limited and experimental availability. This primarily affects Chromium-based browsers such as Chrome, Edge, and Opera.
Should I enable pre-rendering on all WordPress pages?
No. It's best to start with the public pages that are most likely to be affected and exclude the shopping cart, account, payment, forms, and personalized content. WordPress 6.8 actually uses a conservative approach by default.
Does the Speculation Rules API directly improve SEO?
It can improve performance metrics such as LCP or perceived experience, which helps a website that is already consistent. It does not replace useful content, a clear site architecture, or comprehensive technical work.
What is a realistic cost estimate for implementing it?
For a simple existing website, expect to pay between €500 and €2,500 (excluding tax), depending on the scope of testing. A more extensive performance optimization project can cost between €3,000 and €10,000 (excluding tax).
How can you verify that the rules are working?
Chrome DevTools includes an "Application" section, followed by "Speculative Loads," where you can inspect rules, attempts, and errors. This should be supplemented with actual metrics on LCP, conversions, and analytics.