Predictive Loading with Speculation Rules

Speculation Rules can significantly speed up how quickly users see your page content. And Page Lightning enables them by default.

They are a new browser feature that lets us tell the browser to preload certain pages when we suspect the user will click a link to them. This can significantly reduce the time it takes for the user to see those pages. There are three types of pre-loading:

  • Prefetch – This is where just the HTML is loaded in advance.
  • Prerender – This is where the whole page is loaded in advance. Think of it as a hidden tab where the speculated page loads. When the user clicks the link, that tab is swapped in.
  • Prerender until script – This variant of Prerender stops before scripts execute. This makes it a lot safer to use than the full prerender, but not as instant.

Prerenders can cause a near-instant page load, but it means the user is downloading a lot more resources. However, prerender does take advantage of caching, meaning many resources will already be in the browser, like the main bundle and CSS files, but probably not images specific to the page. For less certain speculations, it may be nicer to just prefetch.

Speculation Rules provide several ways to apply their rules for links on a page:

  • Conservative – Load the destination when the user clicks on the link. This is 100% certain, but it only slightly speeds up the next page’s load time.
  • Moderate – Load the destination when the user hovers over the link for 200ms. This is less certain, but it can give the browser some time to load the next page in advance.
  • Eager – Load the destination when the user hovers over the link for 10ms. So a lot more aggressive than moderate.
  • Immediate – Load the destination as soon as the rule is defined.

On mobile devices, the rules differ to accommodate touchscreens, where users do not hover over links. They focus more on the links’ visibility on the screen.

The Apps also let you decide whether a rule applies when the user is not using a mouse. e.g. a mobile or tablet.

Rules get applied to links. E.g., a Moderate Prefetch on a link would cause the browser to prefetch the link’s HTML after the user hovers over it for 200ms.

Any standard user activities that we know could change speculated pages will cause any already speculated pages to be removed from the current page and from any other tabs in the browser. The rules are still in place, so speculation can start afresh. This includes standard activities such as logging in/out, changing consent options, changing currency, altering cart contents, or completing checkout. If you have your own functionality that could change the contents of speculated pages, e.g. a third-party consent banner, then when things change, you can reset all current speculations with this command:

PageLightning.resetSpeculationRules();

Our Tag Rocket app has a Page Lightning script that calls this function when the user changes their consent options via a third-party consent system.

Standard Rules

There are several built-in rules, each with options to adjust its aggressiveness.

Built in speculation rules

Product Card

Product cards are where products are listed on pages such as categories, brands, and the home page. We focus on these because they are often the most prominent parts of a page designed to attract clicks.

These rules assume the theme is based on Cornerstone. That is, the cards are selected by the CSS selector “.productCarousel .card, .product .card”. If the rules do not work, you may need to implement custom rules using your own selector.

Product Card Viewed defaults to prefetch the product URL if the card has been visible for 2 seconds.

Product Card Interactions default to prerender-until-script/moderate. So the product URL will start prerendering (up to script execution) after the user hovers over it for 200ms.

These defaults mean the product’s HTML is fetched when the card has been visible for 2 seconds. If the user then hovers over the card for 200ms, it starts rendering the product page up to the point of running scripts.

Blog Link

This covers links from the general blog page to the individual blog posts. These links are detected by the “.blog .blog-title, .blog .blog-thumbnail” CSS selector.

These rules default to prerender-until-script/moderate. So the blog URL will start prerendering after the user hovers over it for 200ms.

Other Internal Link

Other internal links default to prefetch/moderate. So the rest of the link URLs will start prefetching after the user hovers over them for 200ms.

Custom Rules

The app also lets you create custom rules with the following options:

  • Restrict to a specific page type. E.g. product page.
  • Restrict to pages whose URLs contain certain text (from a list).
  • CSS selectors to find links on the page to include.
  • A list of URL patterns to find links to include.
  • What type of rule to fire (prefetch, prerender).
  • How is the rule fired (conservative, moderate, eager, immediate, viewed).
  • If viewed, how long do they need to view it for.
  • An option to restrict the rule based on whether a mouse is being used.

e.g. you could immediately prerender a very popular URL on a specific page.

Some examples:

Prerender-until-script a regularly clicked link on the home page, such as one in the carousel.

Prefetch the next page link when it is visible (with the “.pagination-item—next” CSS selector).

Prerender-until-script the first three products on a grid using these CSS selectors:

.productGrid .product:nth-child(1)
.productGrid .product:nth-child(2) 
.productGrid .product:nth-child(3)

Creating our Internal Link Click Report on data for your store can give you great insights into which links are most likely to be clicked and, therefore, good candidates for speculations.

CSS Class-based Rules

CSS classes let you define how rules are applied to links by editing the theme. A class applies to all links within its scope:

  • prefetch-immediate  – prefetch all links as soon as the class is applied.
  • prefetch-eager – prefetch on hover over a link for 10 milliseconds. Mobiles use viewport heuristics.
  • prefetch-moderate – prefetch on hover over a link for 200 milliseconds. Mobiles use viewport heuristics.
  • prefetch-conservative – prefetch on link clicks.
  • prerender-immediate  – prerender all links as soon as the class is applied.
  • prerender-eager – prerender on hover over a link for 10 milliseconds. Mobiles use viewport heuristics.
  • prerender-moderate – prerender on hover over a link for 200 milliseconds. Mobiles use viewport heuristics.
  • prerender-conservative – prerender on clicking a link.
  • prerender_until_script-immediate  – prerender_until_script all links as soon as the class is applied.
  • prerender_until_script-eager – prerender_until_script on hover over a link for 10 milliseconds. Mobiles use viewport heuristics.
  • prerender_until_script-moderate – prerender_until_script on hover over a link for 200 milliseconds. Mobiles use viewport heuristics.
  • prerender_until_script-conservative – prerender_until_script on clicking a link.

Classes can be dynamically added. E.g. You could add a prefetch-immediate class to a link once it has been visible for 2 seconds.

You can also disable rules for areas of the page, like:

  • prefetch-off – do not prefetch any links.
  • prerender-off – do not prerender any links.
  • prerender_until_script-off – do not prerender until script any links.
  • immediate-off
  • prerender-moderate-off
  • Etc.

The system also supports rules based on how long a link is viewed. It’s possible to add your own viewed rules using the following classes:

  • prerender-viewed
  • prefetch-viewed
  • prerender_until_script-viewed

And control how long the user has to see the specified element using these attributes on the same element. It defaults to 2 seconds:

  • prerender-viewed-time=”2000″
  • prefetch-viewed-time=”1500″
  • prerender_until_script-viewed-time=”1750″

Some devices do not use a mouse (e.g., a touchscreen), like a mobile. Our system lets you restrict or vary rules based on whether a mouse has been used. e.g. the built-in product viewed rule lets you decide whether it applies only when a mouse has not been used (mobile).

All the main classes can have -mouseinactive or -mouseactive added to them to restrict when they apply.

To test, you can add ?wsa-mouse=active or ?wsa-mouse=inactive to a URL to override the mouse detection. It needs to be added to every page you test.

How To Test Your Rules

The Chrome Developer Tools show which Speculation Rules are present on a page and their status. This can be monitored as you interact with the page to see how rules fire.

Chrome developer tools->Application->Speculative loads->Speculations

How To Monitor Their Impact

Because of the nature of speculation rules, single tests do not reflect what is happening with real users. Their behaviour determines how rules fire and if they are used. So we need to look at real-world data.

The Tag Rocket Report

If you have Tag Rocket, we recommend setting up the Tag Rocket Report. This gives you detailed reports on how your site is performing with real users, in the Web Vitals section. The TTFB, FRHS, and TTLB reports all measure the speed of the initial HTML. While FCP and LCP focus on when the user can use the page.

The reports have filters related to the speculation rules. The “navigational-prefetch” delivery type means the page is prefetched. The pre-rendered filter lets you look at only the data for pre-rendered pages.

The Core Web Vitals from CrUX

Google collects real user data from some Chrome users (CrUX). This data is made available from several tools in several forms.

This data is more limited. It’s only from some Chrome users; it is aggregated, and it provides no details on the causes of issues.

Page Speed Insights – the top of its report, provides page-specific or site-wide data.

Google Search Console – Site-wide data with examples of pages in each classification.

BigCommerce checkout page using speculation rules

BigCommerce now does some speculations from the cart to the checkout page.

Cloudflare Speed Brain and speculation rules

Cloudflare can now do some very conservative speculations via its Speed Brain feature. You need your own Cloudflare account connected to the site via O2O. Unfortunately, enabling it interferes with the speculation rules added by Page Lightning and disables most of our rules. We recommend that you ensure Speed Brain is not enabled if you have your own Cloudflare account.

Google search speculation rules

Did you know that Google search already prefetches the first two search results (immediate) and then the rest as you hover over them (moderate)!

Prerender and Tracking Tags

If you think about it, prerendering is like fully loading a page in a hidden tab.

This could mess up your tracking data if the tracking code runs in this hidden tab.

Many trackers are already aware of this (e.g., GA4) and wait until the page becomes visible. Tag Rocket also does this for all the tags it manages. But you may find some trackers that go wild when the user has not seen the page, and may never see it.

The “Prerender until script” speculation rules are a safe option. It will go as far as it can, loading resources etc. But stops before it has to run any scripts. So, no tracking code starts.

If your scripts do not handle prerendering or are outside of Tag Rocket, you could use our Lazy Loading module to run them only on ‘page-visible’.

Mozilla has provided a way to delay scripts on prerendered pages.