In this talk is focused on performance-optimizations and standards-based approaches to achieving the fastest version of your site that you can have. We'll also talk about modern tooling and frameworks like Remix which help make your site fast with very little effort.
Modern Approaches for Creating Extremely Fast Websites
AI Generated Video Summary
The Talk discusses performance optimization in software development and engineering. It covers topics such as optimizing requests, anticipating future needs, and comparing single-page apps to multiple-page apps. It also explores the advantages of single-page apps and the use of Remix for building pages. The Talk emphasizes code splitting, optimizing data fetching, and solving client-side state. It concludes with a discussion on pre-rendering, Remix adoption, and prerendering with React.
1. Introduction to Performance Optimization
Hi everyone, I'm super happy to be in Amsterdam. I teach React on a pretty regular basis and love it. Let's talk about performance. The fastest requests you can make is the one that you don't make at all. But what if you do need to make a request? Let's only get what we need. Anticipate future needs and fetch things in advance. Pick and choose what works for you. Get it nearby, like from a cache.
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.
2. Optimizing Requests and Anticipating Future Needs
Sometimes you need to request two things at once. And if you do that, I think we should try to do them in parallel. Only get what you need. Lazy loading images can make a website faster. Anticipate future needs by pre-rendering content.
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.
3. Comparing Single Page Apps and Multiple Page Apps
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.
4. Optimizing Single Page Applications
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. React Query and the new React router can help with this. However, building a single page app requires more work in terms of over-the-network traffic compared to a multiple page app.
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.
5. Advantages of Single Page Apps
Multiple page apps lose when we want to go to page 2. Single page apps allow for state persistence and fast content. They provide less waterfalls and enable writing UI logic once. Link preload and pre-render are not applicable to single page apps. Building necessary UI and maintaining consistent state are advantages of single page apps. A hybrid approach combining the best of both is possible with Remix.
6. Building Pages with Remix
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.
7. Code Splitting in Single-Page Applications
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.
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.
8. Optimizing Performance with Remix
9. Optimizing Data Fetching with Remix
With Remix, you can prioritize important data like user and products, and start the response early. The HTML page is fully formed and displayed to the user, and when the comments resolve later, they are streamed into the page with a loading indicator. This approach makes websites incredibly fast.
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.
10. Streaming and Deferring in Remix for Fast Websites
The user can view a fully formed HTML file while waiting for the comments to load. The comments are streamed into the page with a loading indicator. Remix allows mixing promises into the page, making it incredibly fast. The client uses a loading indicator while waiting for the streamed results of the comments. Reacttraining.com has achieved a performance metric of 100. With prerender prefetch, the validity of the prefetch page depends on how caching is set up.
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.
11. Solving Client-Side State and Pre-rendering
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.
12. Pre-rendering on Hover
Is the pre-rendering on Hover done server side or client side? It's fetching things behind the scenes, so it doesn't significantly slow things down. Hovering triggers an Ajax request, which may use more bandwidth if not used. Use it sparingly for mobile devices. This talk focuses on speed.
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.
13. Remix Adoption and Prefetching
Do you know if Remix will adopt Reactor or Components? It seems like he's experimenting with it and it's giving him really fast performance. React Server Components may not make something that's already lightning fast. Remix is already pretty fast, whether they use them or not. It may come down to personal preference and specific architecture needs. Some people have concerns about prefetch and prerender, especially with limited bandwidth on mobile apps. You can create your own link component to handle different environments. We have a workshop on Remix if you want to learn more.
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?
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.
14. Prerendering with React and Data Fetching
Can we prerender using React without Remix? React on the server lacks a story for data fetching, so frameworks like Next and Remix provide solutions. React server components are the latest addition. Until React server components, fetching data on the server was limited. It's recommended to use a framework instead of a classic multiple page app.
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.