855: Fast Websites: The New Speculation Rules API

Scott and Wes dive into the Speculation Rules API and why it’s a game-changer for building blazing-fast websites. They break down how pre-loading, prefetching, and pre-connecting work together to boost performance while weighing the costs for both users and developers. Show Notes 00:00 Welcome to Syntax! 00:49 Pre-loading, prefetching, and pre-connecting. CSS Wizardy. CSS Wizardy on GitHub. 02:06 Brought to you by Sentry.io. 03:16 Benefits of pre-loading, prefetching, and pre-connecting? 07:02 The Speculation Rules API. mdn web docs. 08:20 Isn’t that expensive? 08:53 Eagerness of the Speculation Rules API. 09:55 What is the cost for the site? 14:42 What is the cost for the user? 15:49 Next Master. Next Master. 18:07 The current prevalence. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  Welcome to Syntax on this Monday hasty treat. We're going to be talking about the new speculation rules API for fast websites.

• 0:18Scott Tolinski?

  Wes, I don't know much about this, but according to your little intro here, it's about preloading, prefetching and pre-rendering. 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 as always is Wes Boss. What's up Wes?

• 0:34Wes Bos?

  Hey, not too much. Excited to talk about prefetching, pre-rendering, the benefits, the downsides, all that good stuff, because this is like, maybe, let me give you the quick rundown of where my brain is coming from this. So a couple of weeks ago, a tweet on the McMaster car website went pretty viral. And it basically was like, the McMaster car 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 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,

• 1:18Wes Bos?

  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 as 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 NextJS. But now we are getting a speculation rules API,

• 1:44Wes Bos?

  which is going to be built into the browser. And it's actually going to 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.

• 2:00Wes Bos?

  And it's pretty nifty, pretty nifty. So yeah, we're gonna, we're gonna get into it. Let's talk about Sentry really quickly. I'll talk about Sentry 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 Sentry and I was like, hey, wouldn't it be cool? Cause the whole idea behind speculation, the speculation rules is that you prefetch pages because you think somebody's going to go to it. And then when you actually go to the website, it will be already loaded, right? So there's this like kind of concept of like, well, are they going to? And what percentage of the pages are just wasted because you downloaded it? So

• 2:44Wes Bos?

  I messaged them and we're ready. 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. Cause 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. Sentry.io 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. All right. 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

• 3:24Wes Bos?

  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 is you can actually tell it, don't download anything just yet, but figure out where it is. Because part of the request cycle is that you need to figure out, okay, this, this font is loaded at cdn.coolguy.net. And that cdn.coolguy.net, I gotta

• 4:09Wes Bos?

  figure out what the IP address is for it. And we got to 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 going to be done all of that overhead and we can simply just get to, to downloading. Yeah.

• 4:28Scott Tolinski?

  I wonder if this is a good metaphor for this. So what like a preload could be like, get your shoes on, get in the car, we're leaving. And then pre-connect 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 know what we're doing.

• 4:47Wes Bos?

  Figure out how far it is, know exactly where it's where we're going. Yeah, exactly. And both preload and pre-connect, what can be really handy is because the way that HTML parsing works, you can put a preload or pre-connect 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 the HTML figures out there's a CSS, and then the CSS is parsed. And then part of the parsing of CSS goes, oh, there's a web font. Let me go download that. Right? You're kind of, you're waterfalling your request. So if you can tell the browser,

• 5:30Wes Bos?

  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.

• 5:45Scott Tolinski?

  What was the, sorry, what was the first time you encountered this in, in your web development career?

• 5:51Wes Bos?

  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 paste into your head of your document.

• 6:10Scott Tolinski?

  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.

• 6:26Wes Bos?

  Yeah, it's, it's pretty good. Even like, if you have like pagination, right? If you're on page two, you could preload page three, so that the 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 has to be done resource by resource on a resource basis, right? So there's this new API called the speculation rules API.

• 7:05Wes Bos?

  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 pre-render 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 pre-render will go one step further and literally render it in like, kind of like a new tab. 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.

• 7:50Wes Bos?

  Now, these rules for speculation rules is you can say, pre-render where the links match this regex, or when there's a selector that matches X, Y, and Z. So basically just writing a whole bunch of jQuery or CSS selectors 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 pre-render.

• 8:19Scott Tolinski?

  Interesting. So couldn't that get out of hand really quickly in terms of what you're asking the client to download?

• 8:27Wes Bos?

  Yeah, absolutely. Like anytime that you, you talk about prefetching and pre-rendering, people go, okay. Cause like next JS has had this for, for quite a while. And if you are too aggressively prefetching and pre-rendering, 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 pre-rendering these values here? But before I get into that, let me just talk real quick about one more part of the speculation rules API, which is how aggressive you want this thing to be, which is called the eagerness.

• 9:07Scott Tolinski?

  Good name, yes.

• 9:08Wes Bos?

  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 battery just downloading a bunch of pages ahead of time, right?

• 9:45Scott Tolinski?

  That's cool.

• 9:46Wes Bos?

  Yeah, yeah, 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, NextJS has 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 hasn't clicked it. But it can be a little bit expensive, depending on how much does it cost? Like, if you imagine loading the syntax homepage, 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 10x. And does that mean your bill is now going to go up 10x?

• 10:31Wes Bos?

  So here are some questions that you should sort of think about. Like, an average HTML page that's being prefetched, not pre-rendered, but simply just prefetched, is 30 to 100k, right? And you think about, okay, 100k, 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 going to cost me almost nothing to load on there. But if I had to actually,

• 11:08Wes Bos?

  A, if you're paying for bandwidth on your host, that could get expensive really quickly, because you're 10x-ing the amount of bandwidth you're paying for.

• 11:17Scott Tolinski?

  Yeah.

• 11:17Wes Bos?

  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 10x the server resources,

• 11:29Scott Tolinski?

  Right.

• 11:30Wes Bos?

  10x the database time. And is that worth it to you? That incremental speed update to your user? In the case of the McMaster car website, I think that they have a lot of caching, aggressively caching in there. So it's well worth them.

• 11:46Scott Tolinski?

  And pre-rendering? Do you think they're doing pre-rendering as well? Because that feels like that would be a big part of it.

• 11:52Wes Bos?

  They're not doing pre-rendering because I think that pre-rendering is a browser level thing, meaning that like, I guess if you were in React land, you could pre-render the whole things off screen and then just swap it in. But all they are simply doing is just pre-downloading 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.

• 12:18Scott Tolinski?

  Hmm. I was, yeah, I was thinking pre-rendering like when you like almost like static site pre-rendering.

• 12:24Wes Bos?

  Oh, yeah.

• 12:25Scott Tolinski?

  Yes. You pre-render at build time.

• 12:27Wes Bos?

  Like a, like a server render, you mean? Yeah.

• 12:29Scott Tolinski?

  Yeah. Yeah. Because in Svelte kit, to do that on any route, you just put pre-render equals true and it renders that as a static route.

• 12:39Wes Bos?

  Yeah. So you can either do that or you can do it like with stale while or validate. So if you have a CDN in front of your website, you can throw some caching headers on the response. And then your server is not going to do the work to regenerate the page every single time. You might say, all right, caches for three 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.

• 13:12Scott Tolinski?

  But it's a good argument for putting state in query params, right?

• 13:18Wes Bos?

  Yeah.

• 13:18Scott Tolinski?

  You, you put your state into the URL, then what you can, could you pre-render those URLs? You can at least cache them.

• 13:26Wes Bos?

  You, you can pre-render 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 two or you filter for hasty treats. That goes in the URL. Theoretically, we could figure out there's 100 pages and there's 80 different combinations, but then you're thinking. At a certain point, there's probably a couple thousand combinations of how many per page? What type of episodes do you want? You know, before you know it, it gets out of control.

• 14:00Scott Tolinski?

  Generating a thousand HTML pages for a couple pages.

• 14:03Wes Bos?

  Yeah, but what you can do is just, just cache them after they're rendered. So the first person that visits, it's gonna, they're gonna get a, a fresh version, right? And then you'll stick that in the cache. And it's not necessarily that it's slow, because the syntax site'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 that version of the cache and serve it up the next time around.

• 14:41Scott Tolinski?

  Yes.

• 14:42Wes Bos?

  And 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, oh, internet connections?

• 15:04Scott Tolinski?

  Yes, yes, uh, from Tori and.

• 15:08Wes Bos?

  Oh, yeah. All the comments where he's like, you don't know about connections in Africa. And like, all the comments are like, brother, I'm from Africa and we have faster internet than the US.

• 15:19Scott Tolinski?

  Yeah. I believe that, yeah.

• 15:21Wes Bos?

  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 not? Because again, you could burn up. A two gig data plan real quick on some of these websites. If you just might not, let's load absolutely everything in there.

• 15:48Scott Tolinski?

  Yeah.

• 15:49Wes Bos?

  Interesting along the whole McMaster car website is a couple of folks built this thing called Next Master, which is they re-implemented the McMaster car website in Next JS. And it's really cool. It's obviously not the exact same website. There's, there's a little bit to it. But what I messaged them, I was like, post the Versal bill because everybody is like, everybody says, oh yeah, but you're, it's going to cost a bazillion dollars to preload all of these things. So they did post it. So they had 45,000 unique visitors, about 1 million page views, meaning that each person that visited, visited 20 pages.

• 16:30Wes Bos?

  I don't believe that people clicked on 20 things, but I bet that means that 20 pages were preloaded on the page. And their entire bill for 45,000 unique visitors, a million page views was $513, which is, is that a lot? It really depends on, on your product, right? I would say that's a lot, you know, 45,000.

• 16:58Scott Tolinski?

  I would say that's a lot.

• 16:59Wes Bos?

  I would say that's a lot. And if you look at the breakdown, over half of that was edge requests. And then, so $220 was, was the Versal edge requests. And then another $160 was the image compression or sorry, image optimization. So that only has to happen once because they had literally 100,000 images that needed to be resized. So that 160 is really only happening once. Any other big, the rest of it was kind of incremental static regen, right? Reads and writes. There's nothing else that was like really popping out. But that's on Versal. Versal is, is notably expensive for these types of things.

• 17:41Wes Bos?

  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.

• 17:56Scott Tolinski?

  Yeah.

• 17:56Wes Bos?

  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 loads even faster.

• 18:07Scott Tolinski?

  Dope. Man, this is the first I'm learning about this. So what's the, uh, did, did we, did we discuss what the, um, with the prevalence of this is yet?

• 18:18Wes Bos?

  It's in Chrome now, um, and it is not in any of the other browsers just yet. So we're waiting on, on Firefox and Safari. However, this is the type of thing that can be very easily polyfilled, um, especially the prefetching, because you can simply just take these regx's. I'm, I'm sure there is a speculation rules polyfill. In fact, hold on.

• 18:45Scott Tolinski?

  Oh yeah, that makes so much sense. You just pre-render it yourself or pre, preload it yourself. Huh.

• 18:52Wes Bos?

  Yeah, yeah, there, there is a potty polyfill, potty fill. There is a polyfill for it. So you can do that. And in the case of like NextJS, I don't think that they're even using this because NextJS has even more control over, they're not fetching the entire page.

• 19:07Scott Tolinski?

  Right.

• 19:08Wes Bos?

  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 pre-rendering a website can be a very good thing to make your website feel fast. Cause that was another thing is the McMaster car, awful page speed insight scores. Uh, 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

• 19:52Wes Bos?

  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.

• 20:00Scott Tolinski?

  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, medium, slow 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, uh, the experience of the users. Cause that's all that matters anyways, not the, not the score.

• 20:28Wes Bos?

  Somebody was screenshot shaming me on Twitter the other day that my westboss.com 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's 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 inside. Like you think, hmm, like who's top, who's top performance in our industry? Versal? Let's go versal.com. See what they get.

• 21:10Scott Tolinski?

  Go to big, it has to have a lot of images though.

• 21:13Wes Bos?

  Well, let's see, does Versal have, Versal has lots of images, don't they?

• 21:16Scott Tolinski?

  Do they? I can't imagine. I can't imagine a lot of CSS.

• 21:20Wes Bos?

  Oh, they got, they got, they got lots of images.

• 21:22Scott Tolinski?

  Okay.

• 21:22Wes Bos?

  Yeah. Quite a fee. Yeah. My personal website, I got a, I got an 80 yesterday and today I ran it again. I got a 50. It's all over the map with the, these things. If you don't like your page speed insight score, just run it a few times.

• 21:36Scott Tolinski?

  I'm just not using images.

• 21:38Wes Bos?

  There we go. Versal gets a 44 on performance on that. And like, you 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 that's, it's like, oh, if you're running us on a throttled, like old feature phone with really poor 3G, of course it's going to be slow. It's every, the whole website's going to be slow. And that's not really an 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?

• 22:22Scott Tolinski?

  Well, I think my, my dog is like going nuts right now. I don't know what she's doing. She, 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, uh, whatever. She might have urgency to go out outside to the bathroom. And I think that's, no, I don't know, man. I think it's, um, eye test is super important.

• 22:46Scott Tolinski?

  These preloading and prefetching techniques combined with other things is 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'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.

• 23:11Wes Bos?

  Yeah.

• 23:11Scott Tolinski?

  Like, these are apps. The information comes in super duper quick. Now, I have no idea what 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.

• 23:33Wes Bos?

  Yeah, especially like you think about the local first stuff. You're loading, I don't know, 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 like a website and a web app, though.

• 23:50Scott Tolinski?

  Yeah.

• 23:51Wes Bos?

  Cool. All right, well, that's speculation rules. Check it out on MDN and let us know what you think. Peace.

• 23:59Scott Tolinski?

  Peace.