Predictive Preloads: Stop Reacting to Clicks and Start Predicting Them

Why Instant is the Goal

While many website owners focus on achieving 'good' scores on metrics like Core Web Vitals, savvy e-commerce leaders understood long ago that this is merely the baseline. They know what isn't widely understood: the journey from 'good' to truly 'instant' is where the most significant business value lies. The relationship between speed and conversion isn't linear; the largest gains are unlocked when page navigations become seamless.

Why Pages Are Not Instant Yet

The reason this goal remains elusive is fundamental. Every page load is a sequence of delays: network latency to fetch data, server time to process the request, and client-side resources to render the page. No matter how well each individual component is optimized, this sequence imposes a hard limit on performance. You inevitably hit a performance plateau that traditional methods cannot overcome.

Breaking the Barrier with Prediction

To break through that performance barrier and unlock the next tier of growth, we must stop reacting to clicks and start predicting them.

The Solution: Predictive Preloads

Predictive Preloads is our engineering response to this challenge. It works in three key phases:

1. Prediction: The next user navigation is predicted using machine learning models on real user monitoring data.
2. Pre-caching: The Service Worker fetches the HTML for the likely next pages and stores them directly on the user's device.
3. Pre-rendering: The browser fully renders the pages in the background using speculation rules (supported in Chromium-based browser).

The result is that when a user clicks a predicted link, the page is already fully rendered in memory. The browser simply has to swap it into view. The navigation feels instantaneous.

‍

How It Works: Four Success Factors

Delivering a truly instant navigation is not as simple as adding a <script type="speculationrules"> tag. A naive implementation can easily degrade the user experience or, worse, bring down your infrastructure or corrupt business-critical data. We have seen each of these bad outcomes in practise.

To build an effective, production-ready system, we had to solve four distinct engineering challenges.

Challenge 1: Hyper-Accurate Prediction

The entire system's efficiency hinges on prediction quality. A late or missed prediction is useless and a missed opportunity. A wrong guess wastes resources.  So, how do you know which page to preload, and when?

Our solution is a sophisticated, multi-layered machine learning architecture built on a foundation of Real-User Monitoring (RUM) data. We use cross customer data from billions of user journeys to learn general user and click behavior and customize the models by training on link metadata and URL transition from the targeted sites.

While we can host and execute large scale models on server our infrastructure, a lot of information is available on the user device itself. To balance this tradeoff, we combine multiple models for our preload decisions.

‍

• On-Device Models are trained on real-time signals like link characteristics (position, size, content, surrounding area) and user behavior (scroll velocity and frequency,  cursor or touch distance) and take the users device and individual page layout into account. These models are loaded and executed in the browser while browsing the site and are extremely powerful predictors.
• Server-Side Models augment then on-device prediction via an API to leverage more powerful server-side analysis. This allows for complex probabilistic journey analysis with semantic content similarity via embeddings. This more complex model understands which pages have to strongest connection in the current user journey but it can only be executed on server side.
• Heat Maps for the specific page the user is on are used to boost probabilities of links to be clicked relative to the measured temperature.

The final prediction is a synthesis of these layers and is evolving constantly as we incorporate more data into the prediction.

Why separate on-device and server-side models
‍The on-device model works extremely well with numerical data or categorical variables of low cardinality (e.g. a page type that which only has a few possible values). Categorical variables with thousands of possible values (like URLs or content descriptions of pages) need to go through complex embedding steps which blows up the model and can only be support on server side.

Lead Time - The Decisive Metric

There are much simpler approaches out there (like pre-rendering on hover or touch) which also capture a good portion of the clicked links but what these approaches have in common is that they predict very late. That means the browser has only little time to pre-render the target page resulting in a low effectiveness of the pre-rendering.

The time a browser has to pre-render a page before user navigation is called lead time. Alongside prediction accuracy, it is one of the primary metrics we optimize for.

The strong relationship between lead time and LCP is displayed in the next graph.

Challenge 2: Zero Added Infrastructure Load

A system that preloads pages for a significant percentage of visitors could easily multiply traffic by 10x, overwhelming most origin infrastructures or generating prohibitive costs.

To solve this, Predictive Preloads are handled entirely by the Speed Kit infrastructure. Preload requests are served from our edge caches and never hit customer servers, meaning zero additional load or cost.

This builds on our dynamic caching system we’ve described before. The preload process is as follows:

1. Speed Kit serves an anonymously cached version of the next page's HTML from our edge network which is used for pre-rendering.
2. When the user actually clicks the link, our Service Worker sends the HTML request to the origin server to retrieve the personalized page.
3. At the same time, the browser switches the pre-rendered page into view, resulting in an instant navigation to the user.
4. When the personalized HTML is loaded, the DOM is automatically merged into the preloaded anonymous page on the client side and JavaScript is executed.

Challenge 3: Intelligent Client-Side Resource Management

Predictively pre-caching and pre-rendering pages comes with overhead that needs to be carefully managed. We make sure to never interfere with the user's current experience.

We minimize overhead in two key ways:

• Network: We build our serving layer around delta encoding so every loaded page only transmits the parts that are different from all other pages. We do this with the help of compression dictionaries which turn out to be incredibly effective. With this, we reduce the the HTML content by 80-90% on top of state of the art compression like brotli. This allows us to pre-cache ten pages with the bandwidth needed for a single HTML document.
• CPU: To protect the main thread, JavaScript is only parsed and compiled during pre-rendering—it is not executed. This prevents expensive script evaluation from competing with the user's active tab.

Challenge 4: Eliminating Unwanted Side-Effects

Rendering a page in the background that the user might not visit is risky. Here is how Predictive Preloads avoids the potential side effects:

• Skewed analytics from beacons firing on unvisited pages is avoided because Predictive Preloads only executes JavaScript once the user actually navigates to the page, preventing adverse effects for analytics and other third-party scripts.
• Altered server state, such as incorrect user recommendations based on preloaded pages, is prevented by pre-caching sites from a separate caching infrastructure that, by design, cannot impact the original server's state.
• Unintended actions, like an accidental logout from preloading a /logout link or showing stale information on a /cart page, are averted by merging the personalized, up-to-date page content into the pre-rendered shell only at the moment the user navigates to it, ensuring data is always current.

Impact Of Predictive Preloads Tested at Scale

The value of this technology is demonstrated through rigorous A/B testing. Here is what we see consistently:

Performance Metrics:

• Pre-cached Navigations: Between 85-95% of all navigations are pre-cached on the device
• Pre-rendered Navigations: Between 60-70% of pre-cached navigations are pre-rendered in the background (in chromium-browsers)
• Instant Navigations: Up to 70% of user navigations are served instantly with an LCP below 300ms (less than the blink of an eye)

Business Metrics:

• Conversion Rate Lift: We measure direct (relative) conversion uplifts between 1.5% and 5%.
• User Engagement: We saw significant increases in pages per session and average session duration as site exploration becomes frictionless

BMW Example:

The Strategic Choice for E-commerce Leaders

We've walked you through the four critical engineering pillars required to make navigations truly instant. Building this technology in-house is a multi-year R&D odyssey, demanding a dedicated team of data scientists and performance engineers—a significant and perpetual investment. The cost is not just monetary; it's the invaluable time your engineering team could have spent on your core commerce platform and business-driving innovations.

This is why we built Predictive Preloads as a managed feature. We’ve already made the multi-million dollar, multi-year investment so you don't have to. You can bypass the immense R&D and maintenance costs and immediately give your customers the seamless experience that drives conversion and engagement. Focus on your business. We'll make it instant.