Transcription

How is this website, which is 100 years old, it's not 100 years old, but the 100-year-old company, how do they have the fastest website on the internet? That's a tweet from Kenneth Castle last night. And I did a quick look into, like, why does this website feel so fast? But I thought, let's make a quick video in detailing why it is. Because from a high level, it looks like an old website, and you know, good old HTML, it's nice and fast, but that's not the case. I believe that the engineers behind McMasterCars website are doing everything possible to make this website as fast as they possibly can, and they are using all of the tricks in the book. So let's dig into how I figured that out, as well as explaining how a lot of these things work. So first of all, they are server rendering all of their HTML, right? It's not using any JavaScript framework or anything like that. It's simply the server returns HTML, and the browser is very good at rendering out HTML. Now, they are also prefetching HTML. So watch, when I clear this out, and I hover over some of these links here, you'll notice that my network is going crazy. And if you click on one of those, you'll see that it is returning some HTML. So what's happening is when you hover over top of a link, they send the request to get the HTML for that page, and then if you do end up clicking on it, they're able to, watch, when I click on this anchors right here, watch the URL bar and watch the actual page. The page renders before the URL changes. And what's happening there is they are simply just taking this HTML, swapping out the, they call it a shell, I understood from viewing source. They're just replacing the part of the website that does change, and things like the nav, and your order, maybe your shopping cart, those things don't change from page to page. So obviously they change that. That's not new. We've been doing that for a long time with push state, however, they are doing that so it feels nice and snappy. So between pre-rendering it, pre-downloading it, and then using push state to put it on. Now, they are also using caching pretty aggressively. So if we take a look at the headers of this one of these requests, you can often see something like these headers here that will tell you if it's been cached or not. This one looks like it was not cached, but you're often gonna see something like hit or miss in here. And then this Akamai Technologies also tells you that they're using a CDN to store the pre-rendered HTML. That TCP underscore, what that means, that's using something called squid cache, and that's just a little proxy that will cache a lot of your HTML. Now, they are also using a service worker for the HTML. So if you take a look at your network here, and if I clear it out, click on the homepage again, you're gonna see that on that case, it was 65 milliseconds to load that page. That's very, very fast coming from the server. But I think if I refresh this page here, you'll see now it's seven milliseconds, and it's because they're caching it in both on a CDN around the world, but they also are caching it in your browser using something called a service worker. And what that allows us to do is you can intercept requests with a service worker and then serve up the cache version. That's especially helpful for offline progressive web apps. I believe they're using this to power their iOS app, and the mobile app is also really, really good. Now, a viewing source on here, you take a look around at what they're using. These capital letters tell me immediately they're using ASP. That's just a thing that ASP.net does quite a bit, but there's some good clues into what's going on right here. These right here, these link preloads and DNS prefetch, these preloads tell the browser, hey, I'm going to need this right here is, that's their logo, and these are all web fonts. And it's telling the browser, hey, I know you don't know this yet, but I need you to go ahead and pre-download these fonts for me so that when I do need them, they're going to load instantly. If you don't do this, what tends to happen is the HTML will load, and then once it's downloaded all the HTML, it'll start to parse it out, right? And the parsing of it will often come across things that it needs, links to external CSS, links to JavaScript, links to images. But what often happens is that you, oh, I found a CSS file. The CSS file, oh, I found that I need a web font. So it takes two or three waterfall requests before you actually get to it. And by preloading it in the head, before it even knows it needs CSS, it will already have those files hot and ready for you, like little Caesars, right? This also DNS prefetch. Part of the request cycle is, of course you have to go download the actual image, but part of that is simply just finding out if the image is on images1.mcmaster.com, where is the server for that, right? It has to do a DNS lookup, and that takes some time, right? So you can tell the browser, hey, figure out these domain names, figure out where those actually live, so that when I make a request for an image, you already know that part, and there's not gonna be a DNS lookup, and it's gonna be much faster. They're doing a whole bunch of other preloading here as well. We'll get into how they do images in just a second. But what is also kind of interesting is their CSS. So if you scroll and scroll and scroll, and if you look for a .css on the page, you're not actually finding any link tags that load in CSS. So what they're doing here is they are loading their CSS in a style tag before you even get to the body. And what that does is, this is called critical CSS, is the browser has already downloaded the CSS, doesn't need to stop and go and get it, and it just has to parse all of that CSS before you even load any HTML on the page. And what that has the benefit of doing is that as soon as this HTML is rendered to the page, the browser already knows what CSS to apply to it, and you're not gonna get any weird page jank or whatever, just, eh, immediately. That's called critical CSS. There also is some JavaScript here. It looks like it does load in additional CSS that is needed, but the stuff to load the actual homepage, and so the sort of layout is loaded right in line, right as part of the HTML, and they must have some process for figuring out what is actually needed. Also, with CSS, if you take a look at the performance tab here, you'll see 174 milliseconds for their largest contentful paint. That's how long it takes the browser to render the largest element on the page. And if you have a bunch of CSS, oh, then it loads in an image, then that moves, and oh, download some more CSS, and then a web font, okay, we gotta re-render that, right? There's several times it goes, duh, duh, duh, duh, duh, to re-render. This is extremely fast, 174 milliseconds, because they have that pre-loaded CSS, and nothing, there's no jank, right? Look at this. The only thing you see change is a split second while these images are downloading, but nothing else moves on the page when we're doing that. Now, let's talk about the actual images on the page. So one thing they're doing, if you inspect element on these things here, is they have fixed width and heights for their actual images. And what that allows you to do is, if the browser doesn't know how large an image is going to be, it's going to give it zero pixels by zero pixels, and then it downloads, and then it has to push down the content, right? That's another re-render. But if you explicitly give an image tag, or in this case, they're using background images, I'll get to that in a second. If you explicitly give it a spot, and then the image loads, and it fits exactly that spot, you don't get any jank on that actual page. By the way, I know I'm going to make performance people mad about this, because I'm not a performance guy, but I do know how to make websites fast. I might not be using all the correct words, but not too worried about that. The actual images on there, they're using an age-old technique called a sprite. Look at this. If you open this up in a new tab, this is all of the images for that page in a single image. And what that does is, it cuts down on the amount of requests that are actually needed to download it. So it just downloads one image, 93K. So yeah, 93K worth of actual images, pretty nift. That's probably smaller than one image on Amazon. Now let's talk about the actual JavaScript needed on the page. So if we go to our network, and we do a hard refresh of the page here, and we filter for JS, you'll see they are loading quite a bit of JavaScript. So this one is, that's a Burst. So this is a Burst, and you can see that it's loading quite a bit of JavaScript. So this one is, that's a browser extension, but everything else, I believe I calculated, it's different for every single page, which is what they're doing, is they're figuring out what JavaScript is needed on what page. And they're only loading that JavaScript on that page. I call that dependency injection in the tweet. People got mad. They're essentially saying, I need these dependencies for this page, so only load them on that page. And if you take a look at, if you start clicking around here, and look at one of their product pages, in the response, there will often be some data in this little metadata, which tells it what pieces of JavaScript it actually needs. Here we go, JS include file paths. So they must have some tooling on the backend that will split up the JavaScript by page. That's very easy to do if you're using a server-rendered React framework, and you don't have to worry about it. But there are lots of websites out there that simply just load all the JavaScript on all the pages, because it's too hard to figure out what JavaScript is actually needed. So it looks, I don't know much about ASP.NET. This might be just part of their web framework. But the server knows about their CSS, their images, their JavaScript, and they're able to bundle it in such a way where they only load the actual necessary JavaScript on the page. Now, what JavaScript are they actually using? I took a dip into that as well. So if we go to our JavaScript tab here, take a look at some of these. First of all, if you see window.performance and performance.mark, you know that they care a lot about this type of stuff, right? So they are measuring absolutely everything on this page to make sure that it works really well. But I was clicking around trying to see what they're using, and they're using YUI, which is YUI, copyright 2008. This is a very, very old library, a free open-source JavaScript and CSS library for building richly interactive web applications, right? This is a long, long time ago. It was from Yahoo, and they also are loading in jQuery on this page as well. I'm not sure if you can do it from the console or not. Yeah, there, jQuery right there. So a wicked fast website does not matter what framework or whatever you're using. You can be using 15-year-old tech, and it's still loading a fair amount. I think it was 800K of JavaScript, but it feels fast because they're doing it in such a way that it's not getting in the way of the actual important stuff, which is loading the HTML on the page and not blocking and not re-rendering, doing a whole bunch of funky stuff. So this stuff can be done with server-rendered React. This stuff can be done with 20-year-old ASP tech, which is really interesting to me. There are parts on the website where they will be slow because I'm sure they have 700,000 products on here. They have to do, database lookups can be slow, right? I'm sure they spent a lot of time improving the perf on that. They have to render it all out. They gotta cache it all. So there are, look at this. So in that case, that was a pretty good spinner showing on that page. Not brutal, but I'm on pretty fast internet here. I'm sure I'm close to it. But because they're using all the techniques that we just talked about, the website feels really fast. It works really fast. And the people that are using this website here, they need to be able to find lid support hinges that have gas springs and work up to 392 degrees. And I need a 19.49 inch version of that, right? Being able to quickly dive in to this catalog and absolutely get all of the information. People that are visiting this website are fat fingered machinists and fabricators. They have OtterBox on their six-year-old iPhone that is very, very dirty. They don't want to fuss with it. Otherwise they're gonna pick up the phone and try to call them to actual order. They're gonna go back to the paper catalog because that's what they want. So this is a very, very impressive website. I thought it was fun to dip into it. Let me know if you see anything else about it.