Fast Websites: The New Speculation Rules API

Welcome to Syntax.

On this Monday Sanity Treat, we're gonna be talking about the new speculation rules API for fast websites.

Wes, I don't know much about this. But according to your, little intro here, it's about preloading, prefetching, and prerendering. So I'm all ears, and I'm excited to learn. My name is Scott Tolinski. I'm a developer.

I currently live in Denver. With me JS always is Wes Bos. What's up, Wes?

Hey.

Not too much excited to talk about prefetching, prerendering, the benefits, the downsides, all that good stuff because this is is like, maybe let me give you the the quick rundown of of where where my brain is coming from this. So couple weeks ago, a tweet on the McMaster Carr website went pretty viral.

And it it basically, it was like, the McMaster Carr website is so fast. Like, how is this 100 year old company making such a fast website? And so I was like, well, I'm a web developer. I can figure that out. So I I dipped into it really quickly, and then, I ended up making a little video on the techniques that they're using to make the website feel as fast as possible.

And one of the techniques that they're doing and and I would I would wager to say the biggest bang for their buck of techniques is that they are preloading the HTML of the pages JS you hover over top of the links. Preloading, preconnecting, that's been a tactic for quite a while, and it's actually baked into a lot of frameworks like Next. Js. But now we are getting a speculation rules API Mhmm. Which is going to be built into the browser, and it's actually gonna be able to do even more than than that. So it's pretty interesting. Yeah. And I saw Harry, CSS wizardry.

He already shipped it in his website in his website, csswizardry.com.

And, it's it's pretty nifty pretty nifty. So, yeah, we're gonna we're gonna get into it. Let's talk about Century really quickly.

I'll I'll talk about Century in regards to this, the speculation rules thing. So I, as I was researching this episode, I messaged some of the folks that work on the perf team at Sanity, and I was like, hey.

Mhmm. Wouldn't it be cool? Because the whole idea behind speculation or, the speculation rules is that you prefetch pages because you think somebody's gonna go to it. Mhmm. And then when you actually go to the website, it will be already loaded. Right? So there's this, like, kinda concept of, like, well, are they going to, and what percentage of the pages are just wasted because you downloaded it? So I messaged them and and already there's already a chat of, like, oh, is there maybe something that could be brought up in the dashboard for this type of thing? It's it's it's not a thing yet, because it's obviously the spec is is not in all the browsers just yet. But, there's already some talk of like, oh, maybe that's a good metric to show in the dashboard. Check it out. Sanity Scott I o forward slash syntax, and you'll get all the insights into bugs as well as performance of your application. I'll let you know when you're doing slow things.

Alright. So let's talk about, preloading, prefetching, preconnecting. So in the browser, for a while, we've already had a link tag that you can put in the head of your document, and you can say link rel equals. You can say preload or preconnect.

And what that will do is it will tell the browser, hey.

This is a resource, whether it's an HTML page, whether it's a font, whether it's an image.

I'm going to need this at some point in the the document. So go ahead and either, a, start downloading it, which is preload, or, b, preconnect JS you can actually tell it, don't download anything just yet, but figure out where it JS. Because part of the request cycle is that you need to figure out okay. This this font is loaded at cdn.coolguy.net.

Mhmm. And that cdn.coolguy.net, I gotta figure out what the IP address is for it, and we Scott do the whole SSL handshake to make sure that's right. So do all that stuff right away so that when I do want you to download something from that that, URL, you're gonna be done all of that overhead, and we can simply just get to to downloading. Yeah. I wonder if this is a good metaphor for this. So what like, a a preload could be like, get your shoes on, get in the car, we're leaving. And then preconnect

would be like, hey. We might be going somewhere.

Let's pull out the GPS and get instructions. So that way, when we are ready to go, we we know what we're doing. Figure out how far it JS. Yes. Know exactly where it's where we're going. Yeah. Exactly. And

both preload and preconnect, what can be really handy is because the way that HTML parsing works, you can put a preload or preconnect in the head of the document, and you can tell it things like like web fonts or style sheets or whatever, and the browser is going to start downloading them before it even encounters them. Because, like, for example, if you have a web font, you gotta load the HTML, and then the HTML is parsed. And then Yeah. The HTML figures out there's a CSS, and then the CSS is parsed. And then part of the parsing of CSS, it goes, oh, there's a web font. Let me go download that. Right? You're kinda you're waterfalling your request. So if you can tell the browser before it even gets to the open body tag, I'm gonna need this font, or I'm gonna need this image for the header, then it will start downloading it way ahead of time, and you're gonna get a perceived faster website.

What was the sorry. When was the 1st time you encountered this in in your web development? Google Google Fonts is is really good for this because,

yeah, there's when you're using Google Fonts, you're on a different domain. It doesn't necessarily know where the the IP addresses for the domain is. So when you copy paste the little, snippet from Google Fonts, it will give you the preload

URL for that you just paste into your head of your document. Yeah. I remember that, but I also remember the first time I tried to use Gatsby, like pre alpha Gatsby or, like, early early Gatsby.

And you load up everything, and you're like, how the heck is this so fast? And then you pop open the network panel.

You see all of the, the preloading being done. Yeah. It's it's pretty good even, like, if you have, like, pagination. Right? If you're on page 2 Yeah. You could preload page 3 so that chances are somebody's gonna click it, and you can preload it. And what that does is the browser will simply just go and download the HTML and have it hot and ready, and it will also in the case of a link tag, it will also crawl through the entire page looking for its resources as well. So if there's image tags and CSS on the page, it will download those as well. So we've had that for a while, but it it has to be done resource by resource on a resource basis. Right? So there's this new API called the speculation rules API, and what this does is it allows you to pop a script tag into your page with a script of type of speculation rules.

Now inside of that, you can specify both a prerender and a prefetch. So a prefetch will go ahead and download the HTML for that document and, sort of just have it hot and ready. And a prerender will go 1 step further and literally render it in, like, kind of like a new Bos. So it will both download the HTML, parse it out, lay the thing out in the DOM, download any assets that are required, like images and fonts and whatnot, and have it ready so that when you do click on that link, it will instantly be cut in. Now these rules for speculation rules JS you can say, prerender where the links match this regex or when there's a selector that matches x, y, and z. So, basically, you're just writing a whole bunch of jQuery or CSS selectors Yeah. To say, when a link matches this, download it. And when a link doesn't match this, don't download it. And same thing for the actual prerender.

Interesting. So couldn't that get out of hand really quickly

in terms of what you're asking the client to download? Yeah. Absolutely. Like, anytime that you you talk about prefetching and prerendering, people go, okay. Mhmm. Because, like, Next. Js has had this for for quite a while. And if you are too aggressively prefetching and prerendering, then your your bill can can go on up. Right? So, like, you have to you have to really think about, is it worth prefetching and prerendering these values here? But before I get into that, let me just talk real quick about Node more part of the speculation rules API, which is how aggressive you want this thing to be, which is called the eagerness.

Good name. Yes. Which is immediate, eager, moderate, or conservative.

And even if you tell it, hey. These are some links I might want to preload based on those immediate, eager, moderate, or conservative, the device has to make a decision. And things like the user's network, the speed of their phone or whatever, Those things play into whether the browser decides to do it, even like the battery. Right? If your user has a, 4% battery, probably not a good idea to waste their their battery just downloading a bunch of of pages ahead of time. Right? But cool. Yeah. Yeah. It's it's nice that that's, like, sort of built in because, yeah, at a certain point, the browser needs to make those decisions given that the things that it knows about.

But, like, Next. Js has had had this for a long time. A lot of frameworks have had this for a long time where they simply just preload it when the link is in the viewport, or they'll preload it when somebody hovers over top of the link but still hasn't clicked it. Right. But it can be a little bit expensive, depending on how much does it cost. Like, if you imagine loading the Syntax home page, if we were then to start preloading the last 10 shows, that means the amount of work that our website is doing will go up 10 x. Mhmm. And does that mean your bill is now going to go up 10 x? So here are some questions, that you should sort of think about. Like, an average HTML page that's being prefetched, not prerendered, but simply just prefetched, is 30 to a 100 k. Right? And you think about, okay, a 100 k fairly large HTML page, what does that cost us to load? If you're loading that on off of a CDN, like, it's already a static like, for example, my website, if it's just a static page, a lot of the blog posts are just static pages, that's gonna cost me almost nothing to load on there. But if I had to actually, a, if you're paying for bandwidth on on your your host, that could get expensive really quickly because, you're pnpm x ing the amount of bandwidth you're paying for. Yeah.

Or, like, does it cost the server anything to actually render this page? So now if you're preloading 10 extra pages when somebody lands somewhere, now you're using 10 times the server resources. Right.

10 times the database time. And is that worth it to you, that incremental speed update to your user? In the case of the my McMaster Carr website, I think that they have a lot of caching

aggressively caching in there. So it's well worth the prerendering, do you think they're doing prerendering as well? Because that feels like that would be a big part of it. They're not doing prerendering because

I I think that prerendering is a browser level thing.

Meaning that, like I guess if you were in React land, you could prerender the whole things off screen and then just swap it in. But all they are simply doing is just predownloading the HTML.

And then when you click on the link, they're just swapping the HTML on the page. Not the whole page, just the part of the website that changes.

I would see. Yeah. I was thinking prerendering, like, when you like, almost, like, static site prerendering. You know? Oh, yeah. Yes. You prerender at build time.

Like a like a server render, you mean? Yeah. Because you could Yeah. Because in in SvelteKit,

to do that on any route, you just put prerender equals true, and it renders that as a static route.

Yeah. So you can either do that, or you can do it, like, with stale while we're validate.

So if you have a CDN in front of your your website, you can throw some caching headers on the response.

Mhmm. And then your server is not going to do the work to regenerate the page every single time. You might say, alright. Cache JS for 3 minutes. Some pages, you can do that because it's it's the same for everybody, and other people other pages, you can't because it's, like, user data. Right? Like, if it's your your profile, you can't cache the user's profile in a global CDN.

But it's a good argument for putting state in query params.

Right? Yeah. You you put your state into the URL, then what, you can could you prerender those URLs so you can at least

cache them? You you can prerender them if you know them ahead of time, but in the case like, for example, on the syntax website, we have shows.

And you go to page 2 or you filter for hasty treats, that goes in the URL. Theoretically, we could figure out there's a 100 pages and there's 80 different combinations, but then you're thinking at a certain point, there's probably a couple 1,000 combinations of how many per page, what type of episodes do you want, you know, before you know Wes, it gets out of control. Generating a 1,000 HTML pages for Yeah. But what you can do is just just cache them after they're rendered. So the 1st person that visits, it's gonna they're gonna get a a fresh version. Right? Mhmm. And then you'll stick that in the cache, and it's not necessarily that it's slow. JS a syntax site, it's not slow to do it without a cache, but it's expensive that we have to use server time to regenerate that page every time. So what you do is you just stick the result of hasty treats page 32.

Stick that in a cache or throw a caching header on there, and then the CDN will just save the that version of the cache and and serve it up the next time around. Yes. Another thing to consider is, like, what does it cost for the user to load this as well? This is less of an issue now that unlimited bandwidth has become so widespread.

In fact, who did we have on on the show that they were saying about, like, Africa and, like, like, slow Internet connections? Yes. Yes.

The from Tory, man. Yeah.

All the comments Wes he's like, you don't know about, connections in Africa. And, like, all the comments are there, like, brother, I'm from Africa, and we have faster Internet than the US. Yeah. Which I believe that. Yeah. So, like, you have to think about, like, is there is it is the user on a limited data plan? Are they on slower connections? You know? And that's where I think the the device itself will, play into these speculation rules of should it be done or Scott. Because, again, you could burn up a 2 gig data plan real quick on some of these websites, if you just why not? Let's load absolutely everything in there. Yeah. Interesting along the whole McMaster Yarn website is, a couple folks built, this thing called Next Master, which is they reimplemented the Yeah. McMaster Yarn website in Next. Js, and it's really cool. It's it's obviously not the exact same website. There's there's a little bit to it. But I messaged them. I was like, post a Vercel bill because everybody is like everybody says, oh, yeah. But you're just gonna cost a bazillion dollars to preload all of these things. So they did post it. So they had 45,000 unique visitors, about 1,000,000 page views, meaning that each person that visited visited 20 pages.

I don't believe that people clicked on 20 things, but I I bet that means that twenty pages were preloaded Mhmm. On the page.

And their entire bill for 45,000 unique visitors, a 1000000 page views was $513, which is is that a lot? It it really depends on on your product. Right? I would say that's a lot. You know? 45,000 I would say that's a lot. I would say that's a lot. And if you look at the breakdown, over half of that was edge Wes.

And then so $220 was Wes the Vercel edge Wes, and then another $160 was the image compression or sorry. Image optimization. So that only has to happen once, because they had literally a 100,000 images that needed to be resized. So that 160 is really only happening once and the other big the rest of it was kinda incremental static regen, write reads and writes. There's nothing else that was, like, really popping out, but that's on Vercel. Vercel is is notably expensive, for these types of things. But for a lot of people, my ourselves included, it's it's worth it because trying to host this stuff yourself can be a little bit tricky. So I bet you could do this for quite a bit cheaper if you were, like, gunning for making this very cheap. Yeah. Yeah. That they weren't gunning for that. They were gunning for how do we make a Next. Js website that feels the same way. In fact, it doesn't even have spinners. It it loads even faster.

Dope. Man, this is the 1st time learning about this. So what's the, did did we did we discuss what the, what the prevalence of this is yet?

It's in Chrome now, and it is not in any of the other browsers just yet. Okay. So we're waiting on on Firefox and Safari. However, this is the type of thing that can be very easily polyfilled, especially the prefetching because you can simply just take these regexes.

I'm I'm sure there is a speculation rules polyfill.

In fact, hold on. Oh, yeah. That makes so much sense. You did you just prerender it yourself or pre preload it yourself?

Yeah. Yeah. There there is a potty polyfill pottyfill. There is a potty so you can do that. In in the case of, like, Next. Js, I don't think that they're even using this because Next. Js has even more control over they're not fetching the entire page. Right.

You can you can simply just fetch the component that needs to change at a component level, which is pretty nifty.

So it's just this whole idea of of prerendering a website can be a very good thing to make your website feel fast. Because that was another thing JS the McMaster Carr, awful page speed insight scores.

All the performance people are like, no. This is awful, and it's hilarious to see just real world people. I got so many messages from people that were not web developers being like, I love this website because it's so fast. And, like, this is my favorite website in the world, and it's great to see that because those are real users that it's just they don't care if it has a high page speed score or whatever. They just know that it they tap the button, and it shows up as fast as it possibly can. Yeah. We have mentioned before on this show that page speed is not the end all, be all. It's a tool,

but, man, if you're using the site on even, like, slower, mid medium ESLint Internet and you're noticing it or seeing, you know, the actual usage being fast, then that you don't need you don't need a perfect lighthouse score at that at that point. It's just about, the experience of the users because that's all that matters anyways, not the not the score.

Somebody was, screenshot shaming me on Twitter the other day, that my Wes only got, like, a 76 on mobile, but, like, a 90.94 on desktop, and my mobile was, like, a 78 or something like that.

And I was just like, it show me show me a website that is real and not just, like, your personal blog with a list of links in a div, but show me a website with images that gets a good page to get insight. Like, you think, like, who's top who's top, performance in our industry? Vercel? Let's go over vercel.com. See what Go to big it has to have a lot of images, though.

Let's see. Does Vercel have Vercel has lots of images, don't they? I Sanity imagine. And I can imagine a lot of CSS.

Oh, they got they got they got lots of images. Okay. Yeah. Quite a few. Yeah. My personal website, I got a I got an 80 yesterday, and today, I ran it again. I got a 50. That's all over the map with the these things. If if you don't like your page speed insight score, just run it a few times. I'm just not using images. There we go. Vercel gets a 44 on performance on that. And, like, go to their website. It's fast as hell, and it's so frustrating that this is the, like, golden score when like, show me, like, a real website that has real customers that it's getting. And if you go to the desktop, it's usually better, but it's it's like, oh, if you're running us on a throttled, like, old feature phone with really poor 3 g, of course, it's gonna be Scott. The every the whole website's gonna be slow. And that that's not really excuse to make crappy websites, but I don't think that this whole lighthouse score is,

is the thing that we should be going for. I don't know. What do you think of that? Well, I think my my dog is, like, going nuts right now. I don't know what she's doing. She I I think she heard something she thinks is outside, so she's huffing and puffing a little bit. I don't know why.

That's what I think about it. I think, whatever. She might have urgency to go out outside to the bathroom. And I think that's no. I I I don't know, man. I think it's, I Wes is super important.

These preloading and prefetching techniques combined with other things is the the true path to really, really fast feeling things. The information's ready to go. You click. It's either cached or it's loaded. It it's in it's in the site, whatever.

It feels good, feels fast for the user. And that's kind of what I've been getting at a bit with even client side rendering stuff with local first sites. Yeah. Like, these are apps. The information comes in super duper quick. Now I have no idea what the the page speed is going to be on those. It's not server rendering any of the data. It may be server rendering the shell of the site. But those sites, it's not about the score that you might get from something like that. It is just how dang fast they are to use.

And that's what matters the most. Yeah. Especially, like, you think about the local first stuff, you're loading I don't know. You'll you have to load a bunch of JavaScript to be able to do it. Right? And you might get ding there, but then every single time that you add something or hit enter, I guess that's the difference between that, like a website and a web app, though. Yeah. Cool. Alright. Well, that's speculation rules. Check it out, on MDN, and, let us know what you think.

Peace.