Modern Approaches for Creating Extremely Fast Websites

Hi everyone, I'm super happy to be in Amsterdam. It's been real fun, and thank you for having me. My name is Brad Westphal, I work at React Training. I teach React on a pretty regular basis, and I love it.

Let's do some cool things. I came up with this talk, like a lot of speakers do, you have like a general concept, and you don't really know exactly how you're going to make it or what direction it's going to go in, but I knew I wanted to talk about performance. I didn't know if I was going to talk about DOM rendering performance, or maybe animations, or all of the above, and make it just a big scatter of everything.

I started asking around, and I asked some friends and some people on Twitter and stuff, what do you think of when you think of website performance? This is one of the more common responses that I got. The fastest requests you can make is the one that you don't make at all. Have you ever heard that? Whenever I hear this one, I kind of do a little bit of a, like, what? Okay, that's kind of philosophical, they kind of mic drop and walk away, like, there you go, there is performance. But we're in the business of making websites. That make requests. I can't take away all my requests. It's not really practical.

So, I started thinking about this and I thought, okay, that's fine. If that works, if that helps. But, what if you do need to make a request? Because we're all going to need to do that. So, that's what this talk is about. Let's maybe only get what we need. Pretty simple? Sounds good. Okay. Advice. Moving on. Maybe anticipate future needs. For example, fetch things in advance when you think that you're just going to need them. Sometimes it might seem like these two are a little bit at odds with each other. But you kind of pick and choose whichever one works for you in this situation. Of course you're going to want to get it nearby. Like from a cache. That would be nice.

Sometimes you need to request two things at once. And if you do that, I think we should try to do them in parallel. And don't let the slow thing hold up the fast things. So let's start right here.

If you need to make a request, only get what you need. Let's just start with something that's more standard and not so much React. With images, I'm sure most of you know, this has been around for a little bit now. We can do lazy loading, which is really great. So below the fold, if you can identify certain images as being something that doesn't necessarily need to be loaded. Maybe this is the fastest request you can make is the one you don't make at all, maybe. But only get what you need. Things that only need to be loaded when the user needs them. So the user scrolls, they get the image, very good. Okay. So that's what I'm talking about. Things that you can do to make a website just a little bit faster.

Anticipate future needs. A standard example of that would be maybe this is one that you haven't seen. Link, pre-render, lowercase l. This is not a React component. This is a standard HTML thing. I know, funny, right? Okay. So this is something that you can maybe use. If a user visits your site, whatever page they land on, imagine anticipating very easily what page they're going to go to next, because you probably have an idea, and you're downloading those pages behind the scenes ahead of time. And then the user visits the second page and then you're downloading the third and fourth possible pages they might want to go to. So this is really nice. MDN describes this as when the user navigates to the prerendered content, the current content is replaced by the prerendered content instantly. This is nice. You know why? Because it makes me feel like it makes me feel like the user is getting an experience like local development. Like, we all get the best version of our websites, right? Because we're doing local development.

It's superfast. And then you put it on the network, on the internet, and it's a little bit slower, and you just kind of tell yourself, well, it's the internet. That's how it is, right? But it would be really nice, ideally, if we can have a superfast experience for our users like we have locally. That would be the ideal, I think.

Okay. So these two things. Let's compare what it's like to build a classic multiple page application versus a single page app. I'm sure a lot of you are familiar with single page apps because that's been the popular thing for like 10 years. But I've been around long enough to remember what it was like to build the multiple page apps and the burdens that they had. There's a tradeoff between these two things. Let's build this in layers. So we might have a main layout, like a sublayout, and a page, like a lot of these types of apps would have.

Okay. So let's kind of imagine what the network requests are going to be like for the different users that are visiting the same application. The first thing that might happen is the single page application user is going to get an immediate response from the server, but it's going to be mostly a shell of an HTML file. In the meantime, the multiple page app user hasn't gotten any HML because it's all being built on the server. So what's better? I don't know. Maybe it's subjective. Maybe too early to tell, but if we have to give out a trophy at this point, maybe because the single page app did respond a little bit sooner, maybe we award the trophy over to the single page app.

The next thing that probably happens is the multiple page app gets a fully formed HTML file while the single page app is still getting JavaScript, and then we have to build the HTML. But are these two things equal at this point? Not really, because the multiple page app user is experiencing a fully formed HTML file while the SBA user is getting loading spinners. So maybe we flip this around. Maybe the multiple page app is a little bit better right now. Now, the multiple page app does have to go and get JavaScript, but this is probably just for events. And so it really didn't diminish the user's experience too much. And then at the same time, the single page app is fetching data. Notice the distance here? Where was the data fetched when we were in the multiple page app? It was on a server talking to another server. They could have been right next to each other, right? Ideally, they could be near each other. With single page app, they're probably far apart, and you have to do the same number of requests, probably, if you're doing RESTful type of backends. Some of these requests can be done in parallel, sometimes.

But oftentimes, they're done in serial, creating the classic waterfall. So single page applications are prone to waterfalls because we're fetching within the components. Ideally, we would like to do these in parallel with each other, which you can do. There's things like React Query to help out with this. There's things like the new React router, which you can use the two of them in combination with each other, which is probably the best way to do single page applications, I think, for data fetching. But you can fetch data in parallel with the new React router, because it's not fetching from within the component. So that's nice for single page apps. But ultimately, it does take more work to build a single page app as far as over-the-network traffic than it does a multiple page app.

Okay. So multiple page apps we're winning until we want to go to page 2. This is the reason why we like single page apps, because with a multiple page app, JavaScript shuts down. It's very sad. We can't do state, persistent state, in the client when this happens. This is why in the jQuery days, where would we put our state? There was no Redux or state management libraries back then. Did anyone ever do those 2000s jQuery sites? You would put the state in the DOM.

So page 2, we have to build everything again, everything we already had. We already had all this stuff, and yet we're building it again now, it's almost like a page refresh. I mean, it really is. A page refresh. Okay? The single page application just says, oh, you want to go to page 2? Okay, bam, bam, let's just go and get page 2. So I think that this is a win for single page apps. We like aspects of both of these though, right? We like the fast initial content. We like the client side navigations over here. But over here, we like the less waterfalls, and over here, we like writing UI logic once. I mean, depending on how you're building your multi-page app, if you're doing one technology on the backend and then JavaScript on the frontend, sometimes that can be different than doing it in JavaScript on both sides. Remember these link preload things, or pre-render things that we were talking about? The reason why maybe some of you haven't heard of this is because you can't really use this on a single page app. It wouldn't even make sense because you're gonna do client-side transitions. So that's something that we get over here. What about only builds the necessary UI? We had to go back and rebuild everything all over again, right, when we did the multiple-page app. And finally, states in the frontend. Sometimes you need consistent, persistent state. And so it's nice to be able to do JavaScript and not have it reset in between page transitions. Okay. So for ten years, it felt to me, at least, like you kind of had to be in one world or the other. And today you don't. You can do a hybrid of the best of both. That's really what this talk is about. We're gonna talk about Remix.

But it's not even really about Remix, because a lot of these hybrid concepts would also apply to Next or any of the other JavaScript frameworks that might be doing hybrids as well.

Okay. So let's bring in the framework. Let's build this page with Remix conceptually. And let's see. It's made from three layers. Right? So we've got a main layout. We have a sublayout. And we have the page. So you build different files for this, just like you would in Next. And there's a loader function, kind of like the get server side props, that would run only on the server.

So this is us making the request to the homepage, and it took three components to make the homepage. So these three loaders are running in parallel with each other, fetching data, giving their contents to their respective components, all together to collectively make an HTML file and return that. So at this point, it's really not all that different than... Well, it really isn't different than a multiple page app. We still gotta go and get JavaScript. Right? But what's in this JavaScript? This is where things start to change. Is it just events like the classic multiple page app situation? Not really. Is it every possible UI that we might ever want to go to, like a single page app? Not really. Because neither one of those is really ideal. So what is in here? This is a... We call it a manifest file. And it knows everything about the page that we're on, including the different components that built this page and if we were to go to page 2, because we have the... We know that page 2 is an option, because we have the links that we use to build page 1. It knows that if we were to transition to page 2, that we don't need everything all over again, because page 2 uses the same main layout and sub-layout, so theoretically it would only need page 2 information. So does that mean we have to do a whole page refresh, like a multiple page app, and just get that? Well, no, not really. Now that loader that was the thing that was used in conjunction with the component on the server to build HTML, now that loader can be duly used as a RESTful endpoint. When you want to click to go to page 2, this is going to be a client-side transition where we send back... We'll do two requests in parallel. We send back data from the loader and the JavaScript code to make that component.

Which is just a file, so it's cacheable. And now you're on page 2. So it's like a single-page application at that point. A single-page application that's already doing code splitting for you, and you don't even have to think about it. Not to mention it's doing code splitting in a way where it gets both those things in parallel. What would happen in theory if you were doing a single-page application and you wanted to code split one of your routes? You would have to go to the server to get that file, bring it back, it now wants to do some use-effects stuff, which would require a serial request back to the server to get data. This is all happening in parallel, because we know the whole story. Remix is built on React Router, and React Router knows the whole picture. Which is really nice.

Okay, so anticipate the future needs and fetch them in advance. Okay, so everything that I've explained is already pretty nice. But what if we hover over a link? Merely hovering over it, React... Sorry, Remix can do a link prefetch intent, and hovering over it will already start this process. So, it will give you just a few milliseconds of a head start. And that's kind of cool, but you know what would make it really fast? You can also do prefetch render. And being on page 2, and we're already downloading behind the scenes, all of the contents for page 2, 3, and 4. Or 3, 4, and 5, I should say. But this is not like the standard one that I showed you a second ago, that would have... For a multiple-page app, would have gone back and gotten full payloads of HTML and had them like primed and ready. This is just getting the bits and pieces that we need. This is maybe faster than static websites. At this point. Can it be faster? Well, if you're getting this prefetched data from across the world, that's one thing. But what if we cached it a little bit closer? Now you can get this prefetched data nearby. Could we make it even better? One thing that Remix can do is it can be hosted in any JavaScript server environment. I specifically didn't say node. So places like CloudFlare and WebWorkers are doing things like V8 in the servers at the edge. You can host Remix there. You don't even need a CDN at that point because you're already as close as a CDN would be but with JavaScript running. Could we make it even faster?

So let's say there's get user, get products, and get comments. Ordinarily you would run these in parallel which means you are waiting for the slowest one to finish before you construct the HTML page and return it, right? But one of the new things you can do with Remix is you can designate one of these as being not as important as the other one. So what if get user and get products are more important and they happen to resolve earlier? Why should we hold up what the user sees until we get the comments when the comments aren't as important? It would be okay if we had a loading indicator just for the comments but we had the real data showing for these other two. So what you can do is designate these two and you can start the response back early. Then the user is looking at an HTML file that's fully formed, SEO enabled and all that, and then when get comments resolves a moment later, it can be streamed into the position that it would have gone in on that page with a loading indicator.

Then the user is looking at an HTML file that's fully formed, SEO enabled and all that, and then when get comments resolves a moment later, it can be streamed into the position that it would have gone in on that page with a loading indicator.

So here's what that ends up looking like. This is Remix and we have our loader and our component. So imagine we have this promise that is waiting for get user and get product. We have the awaits keyword there. Notice the next line of code is interesting. Get comments is returning a promise, but we're not waiting for it.

So we did have to wait for the first line of code to finish before the second line of code ran, but we're not in serial waiting for the comments. We're just immediately getting the promise and returning this thing called defer. Normally in Remix you return a function called JSON. But if you use defer, you can mix promises into this, and then it's like we're building the page from objects and arrays, whatever user and product is, but also a part that is a promise.

Now, you use the user and the products as normal, and you use the promise in this thing called await. You put it in this resolve. Once it's ready. So, this is all right now being built on the server, but it's been shipped up to the client at this point. And now the client is using a loading indicator while it waits for the streamed results of the comments. Pretty cool. This is what I've been building websites in lately, and it's been really fantastic. It makes websites incredibly fast. I just checked Reacttraining.com a few hours ago to see what its performance metrics were. They had 100, which is funny because in the States they had 98 or something, but they had 100 here. So, that's great. Anyways, hope you enjoyed. Thank you very much. Thank you.

Oh, a lot of good prerender questions. With real prerender prefetch, how long is the prefetch page valid? You just set up caching the way you want to in that response so you get to figure that out however you want. Great. Easy. Cache as you would.

How has Remix solved the, quote, drawback of sometimes needing and sharing client-side state across routes? Client-side state across routes? You can use classic context providers. The page transitions are client-side so they're not gonna dump your JavaScript and reload it, so that's how I do it. There's other ways I'm sure, but that's how I've been doing it.

Speaking of performance and techniques for that, would you recommend, or have you used the worker API to fetch data behind the scenes? I haven't, so I don't know that much about that one. Sorry.

Okay, if you had a products overview page, say, and this page had 100 plus products and each product had their own page, should you pre-render everything? I don't know, if it's going to be like, if it's going to, I might experiment with it, but if it's showing like hundreds of products per page, maybe you separate on the server into that deferred value and have some things get loaded kind of ahead of time, but things below the fold could be streamed up. Maybe I would experiment with that, and then I'd probably just experiment with some other approaches. I don't know the perfect answer for that one because that sounds to me like architecture that you shouldn't have a perfect answer for something unless you play with it. So I would play with it. Maybe like an intersection type thing? Yeah, something like that. At some point on scroll? Yeah, that sounds good. I think... You want to return something so it's good for SEO. Yeah, exactly. But maybe if you can't see everything in a way. But you can't see everything when you first load the page, it's below the fold. So I mean, the user's going to think that everything was there. They're going to look at a few things. They're going to start to scroll. Those things are going to just be there and the images will be lazy loaded too, right? Yep. There you go. That sounds good to me.

Is the pre-rendering on Hover being done server side or client side? If the latter, won't moving the mouse everywhere slow everything down? Well, it's fetching things behind the scenes. So I mean, if you're on any big website like Twitter or Facebook, I mean, if you want to go to the network tab, it's always going to be doing all kinds of things behind the scenes. So I don't think it's really slowing things down. But when you go to Hover over something, we're just doing an Ajax request to get something.

Is the pre-rendering on Hover being done server side or client side? If the latter, won't moving the mouse everywhere slow everything down? Well, it's fetching things behind the scenes. So I mean, if you're on any big website like Twitter or Facebook, I mean, if you want to go to the network tab, it's always going to be doing all kinds of things behind the scenes. So I don't think it's really slowing things down. But when you go to Hover over something, we're just doing an Ajax request to get something. And if you end up not using it, I guess it's maybe using a little bit more bandwidth. So use it sparingly because if someone's on a phone mobile device, it's fetching more data but it's making an incredibly fast experience. Yeah. Mobile device is one of the interesting ones. This wasn't the save money talk. This was the fast talk.

This wasn't the you have a bad day. Do you know if Remix will adopt Reactor or Components? I think so. If you would have asked me a month ago, I would have said probably not. I don't really talk to Michael and Ryan personally about that that much because they're both busy and I'm busy with React training and stuff. But I could ask Ryan, you know, what his thoughts are. But I get some of my information on Remix just like anyone else on Twitter. I try not to bug them too much. What's your take? Do you want to see that?

Well, it seems like he's experimenting with it. He just tweeted like a day or two ago that he was running experiments with it and that it was giving him really fast performance. But I think that he's aware of some shortcomings of doing so. It's a big trade-off. And I can't imagine that this is going to be really controversial. Is this still recorded? I don't think that React Server Components are going to make something that's already lightning fast. That one's faster. I think that Remix is already going to be pretty fast, whether they decide to use them or don't. I think it's going to come down to whether or not you just like the architecture or maybe have a situation where shipping less JavaScript and React Server Components might give you that. Maybe it comes down to those kind of things. I don't think it's going to give you a performance benefit over what Remix offers. Cool. Interesting.

There's a couple of questions that I'm going to bundle into one theme, which is not everyone is super sold on prefetch and prerender. One person says if you have limited bandwidth on a mobile app, it could screw with it, or... I thought about this question before they even asked it. I thought about it earlier today. If I was really worried about that, I might make my own link component, where you pass them onto the real link component, and in my link component, maybe detect if you're in mobile, maybe have a thing where we don't do the prefetching, but in a desktop environment, it would. You could do your own regular old React tricks to figure that kind of stuff out. Yeah. That sounds like it's worth a shot. Yeah. And we have a workshop on Remix, so let us know if you want to learn more about it.

Yeah. Summon them. One last question. Can we prerender using React but without Remix? I guess that would be maybe server components. Prerender. I mean, you could always use that standards version of prerendering, if you're doing ... The thing about React on the server is there's no story for data fetching, so that's why everyone uses a framework, because you have to ... That's why Next has the Git server side props, and we have the loader, and then they're doing React server components, which So there's no ... Until React server components, there's really no story for fetching data on the server, and so you could a classic multiple page app. Yeah. Or get a framework. Yeah, without doing ... Wait. Yeah. So I wouldn't really do that, but ...

Cool. Well, thank you so much for your time, Brad. Thank you, everyone. You can find Brad in person at the speaker booth after this, and if you're at home, spatial.chat, and you can ask even more questions.