I changed one hidden Google Chrome setting and web browsing became instant

Websites are not what they used to be. There’s a lot more scripting now, and with full-on web apps running directly inside the browser, the web is a very different place from what it was 20 years ago. Duh.

But all of this comes at a cost: speed. Web pages are heavier, and our network speeds, browsers, and servers all have to work harder to make browsing feel as instant as it was always supposed to feel.

There’s a lot of work going into that, though I admit most of it seems to be in the “make loading faster” camp rather than the “maybe stop making websites weigh as much as an operating system” camp. Caching, CDNs, compression, lazy loading, smarter JavaScript delivery, and now… prerendering.

The Chrome flag that loads websites before you click

It can make web browsing feel instant

So. There’s a relatively new web technology called the Speculation Rules API. It gets the name because it speculates. The basic idea is this: when you’re reading a website, the website can tell your browser which page you’re likely to click next, and Chrome can start loading that page in the background before you actually click it.

The advantage is obvious: when you do click the page, some or all of the work has already been done. The page appears much faster, and in the best cases, it can feel almost instant.

You can experiment with this in Chrome through its flags. Go to chrome://flags, then search for prerender. Depending on your Chrome version, you may see one or more prerender-related flags. The exact flag names can change because Chrome flags are experimental, but the general idea is the same: enable the prerendering-related options available in your build, restart Chrome, and Chrome will be more willing to use this newer speculative loading behavior when websites support it.

The first flag (prerender) is the core. This one has to be on for the feature to work. The second one is an enhancement that expands the scope. By default, Chrome won’t load sites that have scripts in the headers. Because this might falsely trigger scripts on web pages that you never visit. However, with the second flag on, Chrome loads the web page right up until it has to execute a script. That’s where it pauses, and keeps the script for when you actually click and visit the web page. It’s pretty smart.

For instance, if you’re filling in a multi-page form, the website can reasonably guess that you’re going to click Next once you’re done with the current page. So it can ask Chrome to prepare the next page ahead of time. Then, when you actually click Next, you don’t have to sit there watching the browser do all the work from zero. It just goes in. It sounds great.

Let’s talk about the disadvantage and the caveat, and then I’ll show you how much of a difference it makes, and how you can test it for yourself.

You can’t have this everywhere

For obvious reasons

Time to address the elephant in the room. If you just turned this on in Chrome and noticed zero difference before and after, it probably comes down to two reasons: 1. Your network is already fast, and 2. the website doesn’t support speculation rules.

We’ll address both in the test, but let’s talk about the second one first.

Obviously, the Speculation Rules API needs to have some smarts. Web pages are packed with links. If this worked automatically on every website and every link inside it, it would be a disaster. There are probably hundreds of links on this very page that you’re reading. If your browser started prerendering all of them, your computer would have a small spiritual crisis. You’d also waste a lot of data, because you’re definitely not going to visit all of those pages.

The main way that this speculation works, is through your mouse movement. There are different types. For example, in some websites, it starts prerendering the page when you hover over the link. The speculation is that since you’re hovering the link, you’re likely going to click it, so they should have the page ready.

There are also different levels of eagerness. A website can ask Chrome to prepare a page immediately, only when you hover over a link, or only when you start clicking. The more aggressive the rule, the faster the navigation can feel, but the more resources it may waste if the user never actually clicks.

On some websites, the speculative loading starts when you hover over a link. The guess is simple: if your mouse is sitting on a link, there’s a decent chance you’re about to click it. So Chrome may start preparing the page while your finger is still deciding. On other websites, it only starts at the moment you press the mouse button down. Normally, navigation happens after the full click completes: press down, release, then the browser moves on. With conservative speculative loading, Chrome can get a tiny head start as soon as you press down, before you release the button. That might sound like nothing, but even a few milliseconds can help when the browser can start the network request early.

Why won’t this work on every website?

So why not enable this for every website and every link, but only trigger it when you hover over links? Well, that would work in some cases, but consider this: you’re signed in to a website, and your cursor passes over the Sign out button. You don’t click it. You just hover. What would happen if the browser treated that as a page you were about to visit? It would not be ideal.

Although, the prerendering mechanism is smart. It won’t prerender more than two pages at a time, so when it wants to prerender a third page, it’ll scrap one of the older ones to make room and not bloat the memory. That was what I saw in my testing.

USB-C can now carry up to 240W. It can, but will it? No. The charger needs assurance that the cable and the device can handle that much power. Even if the charger supports it, and even if the device supports it, and even if the cable looks physically robust enough, the charger still wants a statement from the cable. That statement comes from an E-Marker chip. It’s the cable saying, “Yes, I can handle this.” If the cable doesn’t make that statement, the charger falls back to a safer power level. The cable might be fine without the E-Marker chip, but are you willing to risk melting your cable? Better safe than sorry!

It’s the same thing here. Chrome needs the website to proactively say, “It’s OK to prefetch or prerender this URL.” Otherwise, Chrome usually defaults to no, regardless of your enthusiasm in the flags page. Websites need to define the rules for the URLs they want prepared. It’s a whitelist model.

And if you don’t end up clicking, Chrome ditches the speculative page. It’s pretty smart about memory, battery, and resource constraints. It has limits, and it won’t just keep prerendering an infinite number of pages until your RAM is all the way full. In my testing, Chrome wouldn’t keep more than two prerendered pages around at once. When it needed to prepare another one, it discarded an older prerendered page to make room. That’s the right behavior. But the one thing you can’t get back is network traffic. If Chrome fetched a page in the background and you never opened it, that data was still used.

Putting prerender to the test

A head-to-head

Now, let’s put it to the test so I can show you that it does make a difference. For a fair test with meaning, we need to have the trinity in place:

1. Chrome prerendering enabled.
2. A website that supports speculation rules.
3. A slow network, because otherwise the difference may be negligible.

I have a 300Mbps connection. You can make fun of me for not having 2Gbps, but it’s fast enough for web browsing. On a normal connection, most regular pages already load quickly enough that this feature may not feel dramatic. Thankfully, Chrome DevTools gives us everything we need to make the test more accurate.

A website that supports speculation

A lot of standalone websites don’t support speculation rules yet. MakeUseOf is one example — we haven’t implemented that yet. For this test, I used the DebugBear website, which has a neat implementation of it. I came across their website after reading about Speculation API on their blog.

With the prerendering flag enabled, I opened their website and pressed F12 to bring up DevTools. Then I went to the Application tab and opened the Speculative loads section. This is where Chrome shows the speculation rules a website has provided, along with whether any of them are running, ready, failed, or ignored.

DebugBear had simple rules in place, including one that prepares the sign-up page when the sign-up link is hovered. When I hovered my mouse over the sign-up button, the rule status changed from idle to running, and then to ready.

That’s what we want to see. The browser has received a rule, acted on it, and prepared the page before I clicked.

A slow network

How do we simulate a slow network? Even if I had a slow network, it wouldn’t be consistently slow. So we need to artificially throttle it. DevTools to the rescue again.

In the Network tab, there’s a throttling dropdown. I set it to 3G. This limits the browsing speed to something closer to an old mobile connection. You can also create a custom throttle profile, but 3G is good enough for this test because it makes the difference obvious without it taking too long.

The results

For the test, I used two instances of Chrome, both in Incognito mode. Incognito mode doesn’t do much for your privacy, but it is useful here because it helps avoid existing cache and cookies interfering with the result.

Both instances were throttled to 3G speed. One had prerendering enabled, and the other had it disabled. Then I loaded the website, waited for it to finish, hovered over the sign-up button for a second, clicked it, and compared how long the sign-up page took to load. Here are the results:

That’s nearly 10 seconds shaved off the page’s Largest Contentful Paint in this test. It’s significant. Although 6 seconds is still too long, but hey, we’re on 3G, what do you expect? The prerender also wasn’t complete, because there’s a script. When you click the page in this state with the prerender, you’ll notice that the heading and the structures load instantly and the rest you’ll have to wait for the scripts, and the elements that are drawn by the scripts, to load. On a slow network, this is a savior.

What websites support this?

A few, but they bring many

So far, we’ve talked about two requirements: you need Chrome to support and allow prerendering, and the website needs to implement speculation rules. That raises the obvious question: which websites actually do?

A big one is Google Search. Google has implemented speculation rules on search results, though it mostly uses them for prefetching rather than full prerendering. When you hover over a search result, Google can ask Chrome to fetch the destination page early, which helps the next page open faster if you actually click it.

Another big one is WordPress. WordPress 6.8 added speculative loading to core, which is a major deal because WordPress powers a huge chunk of the web. However, the default implementation is conservative: it uses prefetching, not full prerendering, and it does so with cautious eagerness. In normal human language, that means WordPress sites can start preparing likely next pages right before you click, but they’re not necessarily rendering entire future pages in the background.

And finally, Shopify has also been working with Speculation Rules. Like WordPress, Shopify matters because it powers a huge number of websites. If a large platform implements a web performance feature at the platform level, the effect can spread much faster than if every small site owner has to learn the API, make a decision, test it, and not break anything in the process.

More websites should support this

This is still experimental territory. Chrome flags are not permanent settings, and the exact implementation can change. Still, the direction is promising. Why don’t all websites support this if it’s so good? My speculation (haha) is that there are a few reasons.

Prerendering is powerful enough to be dangerous when handled lazily. Some pages should not be prerendered. Account pages, logout links, shopping carts, payment flows, analytics-heavy pages, personalized dashboards — all of these need care. Even if Chrome blocks or delays risky behavior, the website still has to think about what it’s asking the browser to prepare.

Second, it can waste resources. If a site speculates badly, it can burn bandwidth, memory, battery, and server capacity for pages the user never opens.

Of course, like every performance feature, whether this is good or bad comes down to implementation. But used carefully, it’s a lovely bit of technology. For now, I’m keeping it on.