Blazing Fast Page Navigation with Speculation Rules

Hi, everyone. I hope you are enjoying the conference so far. I'm so happy today to talk to you about something very interesting for me personally, and I hope it will be for you. It's about building pages that you can navigate almost instantly between them using a new, relatively new technology called speculation roles. Allow me to introduce myself real quick. My name is Matt Haddawoud. I'm a senior software engineer working for a company called Miro. And I'm also a Google Developer Expert and Web Technologist Specialized in Web Performance. If you like what you see today, feel free to follow me on Twitter or X on this handle or find more links about me and more articles about performance on my personal blog, MattHaddawoudDev. So yeah, let's get started.

I will start with a fun fact. Fun fact is that humans are slow and in the same time, they are impatient species, that they are always looking for something to be fast. However, they are very slow. And I'm going to prove it to you. First, we are impatient. Web-wise, I mean, is meaning that in 1999, people were perceiving pages that lose in eight seconds as fast-looting pages. And seven years later, it becomes only half of it, four seconds in 2006. And nowadays, we're perceiving pages that lose in two seconds as fast. Anything below that or takes more than that time is being perceived. It's all about the perception that you feel that this is fast or this is slow. And who knows where we are going right now? Using the technology that we're talking about today, this might enhance as well.

Talking about slowness, it takes statically time between one second to two seconds for any user without any stress to click on a link. Moving the mouse, take their time, make sure that this is the link they want, and then click. This also indicates that we are very slow on the Internet. However, we need, after clicking, to be pleasing fast. And this without stress. Imagine if you are in a similar situation to this one and you need it to be very fast. You would think like twice or maybe 10 times before clicking any link. But still, it takes time. So how can we make use of this slowness to make the user perceive this page navigation to be very fast? This is what we are going to talk about today.

I would get to step back a little bit and talk about how web pages are load very fast, very briefly as well. We are requesting a web page. So simply request HTML. We start parsing it and we find out there's some assets to request. Go ahead and request it. And there's a waiting time for the network coming back with assets. Start prerendering and boom, you have these pages loaded in front of you. This takes a few milliseconds, maybe a few seconds, and it can be like three seconds on average or something. And loading these assets might be the problem, how big or how small it is. And also about the latency that happens between your user and the server.

And if the user decided to click on P1, like another link inside this page, imagine what would happen. It's the same exact thing. Loading HTML, parsing it, getting assets, loading assets, rendering it. And bam, you have this page. This might take a little bit less time this time because most of the assets could have been cached or something, but it will take the same exact thing.

But what if you know that this page is being requested or there's a high probability that the user is going to click on it and you think about it. So the current situation is that without speculation rules, you're loading the first page, takes some time, and you do some navigation event to P1. So you do the exact same thing. Another navigation event, you do another process of requesting everything, another navigation event, and so on. With speculation rules, actually, we are not affecting the first load because it's a different optimization that you need to work on in a different way.

Speculation rules help in the other navigations, in the other loading of the pages after you load the first page. Imagine with speculation rules, with some configurations that we're going to learn today, you're going to make the loading fast a little bit. It's going to be, yeah, that's a good enhancement, like half the time. And with Prover configurations for speculation rules, it can be like that. Can be just instant. When you click on any navigation, it would be just loading the page as if it was living in the browser of the user for a long time. So let's dive into that. We want the user to be able to flick between the pages as if they are flicking a page in a book.

Imagine that you're holding a book in your hand, and this ink is being loaded just async. You are waiting for it to load. That looks nice, right? This is from Harry Potter, indeed. But imagine that this pleasant and funny experience would be very horrible if you find out this, oops, four, four, ink not found. What would happen? Actually, this would be very annoying to you. So what you would do is speculating that the user is going most probably to flick to the next page so we can load it ahead of time so it feels like flicking a page in a book as you have it right now.

Speculation rules to the rescue. So you can use speculation rules for that to pre-render pages in advance, actually speculating or guessing what the user is going to do next. And based on that, you are going to load it. If you remember this example from the beginning that you're loading first page or index HTML, we're not going to change that with speculation rules. But during this parsing, you find that there is some speculation rules written for you saying that maybe P1 and P2, these two pages, we need to speculate them, pre-render them in the background.

What would happen? We will learn how to write speculation rules, but let's imagine what is happening with speculation rules. Browser is taking that and start loading these two pages in the background. Imagine that they are happening in a hidden tab inside the browser. And it's actually like that. I'm going to show you during the demo. And everything is happening, like requesting HTML, parsing assets, everything is happening in the background. If the user decide to click in P1 right now, what would happen is that instantly just the pointer will move from the main thread or the main tab to the parsed tab or the pre-rendered tab, which was hidden. Now it is visible, but it will be instantly. This is simply how the speculation rules behave.

So the speculation rules to write it, it will be like a script tag inside your HTML with type speculation rules. And this will have three main things. You need to decide the action. It will be pre-render or pre-fetch. You will decide as well the target. And this will be URLs, maybe URLs that end with this or include this part. Regular expressions, CSS selectors, sky's the limit. You can choose whatever links you think that you need to pre-render or pre-fetch ahead of time.

And eagerness. Eagerness is an interesting one because it decides how this behavior will happen. We will learn about it in a bit. We have immediate, moderate, or conservative. Moving to eagerness a little bit so we can dive into it. If you decide the eagerness to be conservative, which is the least of them, you click on any link. The event of clicking is happening when you K out, but this is happening starting from K down. Starting from K down, we're trying to pre-fetch or pre-render ahead of time.

If you decide to go with eagerness moderate, this gives you a better head start, which is if you hover over any link for more than 200 milliseconds, means that this user most probably is going to click on this link. It's not 100% sure, but most probably they will. This gives you a head start of 400 milliseconds kind of, and this is also two first in first out for pre-fetch and pre-render. This means that a point down or over 200 milliseconds, we start loading this page in the background in a hidden tab or something until the user clicks. We remember we are slow. So it takes one second to click, but we get this head start because of the hover over.

It loads up to two links only with eagerness of conservative. And this means that when you just click on a third link, the first one will be just discarded and the new one will be loaded and so on.

If you decide to go with eagerness moderate, and this gives you a better head start, which is if you hover over any link for more than 200 milliseconds, means that this user most probably is going to click on this link. It's not 100% sure, but most probably they will. This gives you a head start of 400 milliseconds kind of, and this also is two first in first out for pre-fetch and pre-render.

This means that a point down or over 200 milliseconds, we start loading this page in the background in a hidden tab or something until the user clicks. We remember we are slow. So it takes one second to click, but we get this head start because of the hover over. And finally, the eagerness, the highest, which is immediate. This means that anything that the target can't fetch, like URLs or CSS or something, can be maxed because when we find it in the page, it's going to be loaded, just loaded. As example, I just gave it to you. So when the user click, there is no time, waiting time to load. It will be loaded already.

And this comes with great power, but with great power comes great responsibility. You need to think about the user machine as well. Pre-render can be up to 10 pages or 10 links, can be pre-rendered, pre-fetched up to 50. This is a lot, but this might be not a very good idea if your user machine or browser is eating a lot of memory and this might be not a great idea. Just think about it so you can get this as a progressive enhancement. It's not for every user.

So how can we measure the head start so we can see how the speculation rules are going to enhance our thing? To measure the head start, we have some metrics to measure. If the user says, is it happening? This means that they see something is on the screen. We measure it in our dev tools as first contentful paint. And if it is useful, means that the viewport has the biggest part already filled. This for us is called LCP or largest contentful paint event. This is coming with something called Core Web Vitals created by Google.

Thankfully, research shows us what is a good LCP, what's a bad LCP, and what's an okay LCP. This is important. Just would like to grab your attention that speculation rules are something that is not fully supported everywhere yet. It's supported only on Chromium-based browsers, which means that people who are using Firefox or Safari at the moment are not going to enjoy it. So as I said, you need to make it as a progressive enhancement for people who are using browsers that support it.

With that, you will find any Chromium based browser has this div tools inside it. You will find it handy in your div tools. You can open it, debug speculation rules, find it out as we are going to see in the demo right now.

So time for a quick demo to see it in action. And now it's time for us to move to a quick demo to see this in action. Let's go with the demo. This is a demo that has been created by the Chromium team or Chrome team to test speculation rules. To find the speculation rules, you will find an application. You'll find a tab called speculation loads. This means that we have some pages that have been coded by a rule.

If you click on rules, you'll find that there's one rule. If you look at it, this is actually what is inside this page in a speculation rules script tag in the HTML of common fruits. This means that it can fit any link except some links. So for a quick demo, we click on speculations. You will find that all these pages are being waiting to be hovered over so we can pre-render. So for example, I will start with speech as the first one. I click on it. Now as you can see here, it becomes ready.

Without clicking on it, I would like to show you as well something very interesting. You find here in the top main means that this is the main page which is loaded in front of the user. You click on it, you'll find pitch which is pre-rendered. Now if you click on it, actually this dev tool has been switched to this hidden tab that loads pitch everywhere. If you click on console, you will find that yes, I am pitch HTML. This is fantastic. You can debug it as if it is loaded in front of the user and see what has been pre-rendered for the user without switching.

If I switch back to main, this means that we're on the main. We're going back to speculation and now pitch is ready. If I click on it, look at this. It takes 54 milliseconds. This is huge. To measure how fast it is, I'm going to clear cache and hard reload. So for the first hard reload, this means that this is not using speculation rules. You can see normally the LCP time. If I click here, you'll find that it takes one second to load. With speculation rules, which is only on navigation, it takes just like 90 percent less or maybe more. So let's try again.

Pitch is ready. As you can see over here, click on it. This is even less. If I click on Apple, it's ready. Click on it. Very small. If I click on maybe Kiwi and there you go. If I go back, you can see on the right hand side, when I load something, when I load a new one, a third one, it is actually discarding what we have loaded before and load the new one as we go because it's two of them, first in, first out. This is fantastic and you can very easily apply it to your application today. Just add a rule that is just matching what the user flow you have and the expectation. Speculate the user behavior and do that. You click.

You get very, very good. This is not loaded actually with speculation rules. You can go back to Cherry and Cherry is ready. There you go. This is speculation rules.

If I reload the pitch, this is just cached. If I empty cache for the first load, LCP will be a little bit big. So that's simply it. Speculation rules have a lot more things that you need to learn. But it's just the tip of the iceberg. Moving on.

You might come to your mind that, can I pre-render all links ahead so I can give the user the maximum experience everywhere with a YOLO? Simple short answer is no. No because of two things. First of all, you have some regulations. Chrome is not opening it for everything. There's some regulations that will stop this speculation. And also there's some recommendations not to do for some specific links.

Start from the regulations. Chrome will prevent speculations in cases that the user is doing in their browser, like saved data. If they are in a limited quota of data, they are going to enable saved data. So we are not going to pre-render things that the user is not really clicking on it ahead of time. Pages are open in the background tab. This is not going to run speculation. User-enabled energy saving or preload has been disabled with AdBlocker or something. Memory constraints, if your browser again has used maximum memory that it has and speculation will take more memory, speculation wouldn't work.

During the plugin, cross-origin iframes are not pre-rendered due to regulations set by Chrome. Recommendations advise against pre-rendering for sign out URLs, sign-ins requiring authentication, language switcher links, user allowance increment URLs, add-to-cart URLs, and server-side tracking URLs. To debug speculation, developers can use dev tools and check the network tab for pre-render status indicated by headers. Avoid pre-fetching or pre-rendering content not meant for search engines to index, to manage bandwidth usage effectively.

Speculation rules present a challenge in bandwidth usage, especially for large pre-rendered pages. Implementing dictionary compression on the server can significantly reduce page sizes and bandwidth consumption. Combining dictionary compression with speculation rules enables fast navigation between pages, reducing bandwidth concerns. Using view transition APIs can further improve the user experience by minimizing flickering during page transitions and optimizing loading times.

Utilizing bonus steps like dictionary compression and view transition APIs can enhance page loading efficiency. Dictionary compression allows loading multiple pages with the bandwidth cost of one, while view transition APIs minimize flickering and optimize loading times. These techniques, when combined with speculation rules, offer a seamless and efficient browsing experience for users, reducing bandwidth usage and improving page loading speed.

For these links, it might or might not be speculated by mistake. To debug that, you will find out as I showed to you that you can switch to these pages in the dev tools and you will find in the network tab whether they are speculated or not. And this is using these headers. You will find safe purpose and it will be prefetched or prefetched pre-render. So you can find out that anything that has been prefetched or pre-rendered by mistake. Simply anything that you don't need the search engine to find using the robots.txt will be also not recommended to be prefetched or pre-rendered.

So the challenge for us with speculation rules now is being usage of the bandwidths. If you're using, you know, or pre-rendering pages that are pretty big, this will be a challenge for some users and might be something that they would like to avoid. Here comes some bonus steps. Bonus step number one, dictionary compression. Actually, it's a relatively new thing as well that you can enable in your server. So you can compress pages very, very small if they are not updated completely. So you can load, imagine that you can load like 10 pages with the cost of only one page.

If you combine this dictionary compression with speculation rules, you will get a blazing fast navigation between pages. So try it out. This will reduce the bandwidths dramatically and you are not going to be concerned about using a bandwidth. Bonus number two is using view transition APIs. Because even for big pages, if you are switching between them, that will be flicking a little bit to have the rest of the page loading. If you get a hit start of like 400 milliseconds, or for the full page to load takes one second, so you will get like 600 milliseconds, a flicker loading time. With view transition API, this will help a lot.