Making Your React Apps Perform At Scale

Let's take a look. Hey, everybody. My name is Malisha and I'm a developer advocate with Conducto. And there we make these cool CICD tools where you can deploy your apps without using YAML, which is pretty awesome. And you can find me on the Internet, typically on Twitter at Flipped Coding.

So today I want to talk to you about making your React apps more performant, because we know how great it is working with a React app that has over 100 components. So before all of my talks, I'd like to give you a quick overview so that you can decide when to tune in and tune out of the talk. But to get started, we'll talk about your initial React react. So that shiny new create React app base. Then we'll talk about what happens over time and how you add these different layers and all of these new components and what happens to slow down your app in the first place. And we'll get into some of the testing you can do to find areas to improve your app. We'll talk about what you can do to keep your app performant, different tools and techniques you can use. And the fun part is talking about cleaning up an existing app to make it run a lot faster and get those precious milliseconds shaved off of your load time. And finally, we'll wrap up with just a few key takeaways and some things that I hope will be really useful just in your day to day job with React.

So to get started, we all know about that initial Create React app and how clean and empty it is. So when we're starting, we have this shiny new React app. It has basically nothing in it. There's this one really simple test. And our app is all of, what, 26 lines, basically. So you see, it's not really much structure here. Everything's clean. And if you just start adding on, it can get complex really fast. But you know what that looks like. We've all been there.

So what happens over time is that the software development lifecycle basically destroys all of that simplicity of having everything in the root folder, pretty much. And the reason for that, it's a lot of things. There are architectural decisions that are made. There are different features that are added. People organize folders and files differently. And so as you keep adding these components, not only does your project code get more complex to read through and find different bugs, but these components take rendering time. So as you add more of them, whether they're nested or it's on a new page or however you're using your app, as you add more components that need to be rendered, this naturally just slows down your application. So you'll have API calls that you're making, you'll need to do a sync page updates, and this triggers a lot of state changes and use effect hooks. And all of that takes time. And at first it seems like those few milliseconds, oh, whatever, 500 milliseconds, we can deal with that. But when you have 30 components that take that much time, you start to see that noticeably slower moving app and your users especially notice that.

So over time, this is more of what your app starts to look like. You have some different folders. You have a bunch of new components and helpers and all of your packages, of course. So things just get bigger and then you start having API calls and we'll get more into this a little bit later in the talk, but you see there's just more things going on. You have functions that are hit. You have just all of this stuff happening in one component. So imagine this 80 more times on the same page and you can see how quickly it will slow down your app. So to kind of help us find those particular problem areas in our application that really take the most loading time, we run some tests to see where we can improve things. So the first thing you want to do when you're running performance tests is make sure that you're using a production build.

There's really not much point in running a whole lot of performance tests on a development build, even though there are some benefits. If you want to see the improvements where the users are having problems, you need to use the same version of your app that the users are going to be working with. So that is why in the beginning, go ahead and make your minified production build, get it through all of your unit tests first to make sure there's no other bugs you need to work out. Because sometimes when those tests fail, they're showing you places like, hey, this spot might need some refactoring because it's overly complex, or maybe you have a bug in there that's hitting an API that returns a 404. And it just keeps making that request because you have it on some kind of, I don't know, time out, click the button type thing. But use production build so that you get the most accurate results. And the first thing, one of the most common things is that you'll be using lighthouse to just get that initial performance score. So using this app as an example, you see it has some modals, there's some different pages, functions, APIs, all that good stuff. And what this looks like on the page is just a little budget app, nothing too fancy. And I have not spent this much money in one day, just for the record. That's just some leftover data from some stuff I was playing with. But anyways, the main thing that y'all want to see would be Lighthouse. So this is a React app. We know that. But when you come into your developer tools and you go to the Lighthouse tab in particular, what you can do is set the different categories you want it to check for, and determine if your app is up to standards. So desktop isn't as hard to develop for, so I always run my reports for mobile. And as you can see in the background, Lighthouse does this cool thing. It goes ahead and puts it in a mobile view, and it runs all of these different performance tests to see, well, is your app running fast enough? Is it gonna work well for people with a slow internet connection? Is it accessible? Things like that. So as you can see, this app is pretty bad on performance, but the cool thing about Lighthouse is that down here they give you a lot of suggestions on what you can do to improve your app. So this first contentful paint, basically, how fast can you get your initial page load? Nine seconds is way too long. So I'll have to dig in and see what exactly is the problem. I'm guessing it has something to do with this graph, just a guess. But as you can see, they give you screenshots, they give you some different options, and this right here Minify JavaScript, that's why we run on a production build, but this is just a demo, so gotta show you what I can show you. But again, Lighthouse is a great tool, it gives you all of these tips and ideas of what you can do to make your app more performant. And so now that you've seen Lighthouse, if you're not familiar with the Profiler tool, but you have heard of the React Perf tool, this basically replaced that Perf tool. So there used to be some kind of React add-on that you could put in your code, and surround the particular component that you wanted to figure out how long it was taking to load with, and it would give you this whole report on, from the minute it starts rendering to the second it stops. But now that just happens in the browser, which is pretty awesome. So going back to our page, I'm clearing out everything. We'll go over here to this Profiler tab, which is really cool, but basically you can start profiling and refresh the page. It didn't profile for me.

Okay. So now it's refreshed and we are waiting on it to finish profiling whatever it's profiling. So I think I'll go ahead and stop it. But this gives you a view of every single component on the page and how long it takes to load. I'll try to make that bigger so you can see. But overall, you can see that the page took almost, what is that, almost half a second before I hit stop. But this is just a breakdown of how every single component on that page down to the router, how long it takes for those different elements to load. So clearly the chart is where the problem is because it's taking the most time out of all of these components. But this is one of the fast ways you can figure out, hey, where should I be looking for those kinds of improvements? This just gives you a really broad overview so that you can see those particular problem areas really fast, really easily.

And so back to here, the Network tab. This is every front end engineer's best friend when we're working with those API calls, trying to figure out what data we're working with and making sure that the backend didn't change any parameter names. So when you're making those API requests, sometimes that is where your problem area is because one component could potentially make many, many API requests. And depending on how long those requests take, like how much data they're returning or how much data you have to send to them, that could be a huge bottleneck for your app because your page won't finish rendering until you have that data back. Or maybe you'll just get an error. But the main thing is that you want to see any calls you made. Like in my case, one of the backend APIs was this get all items. And you see how long it took if we just go back here. So this only took 24 milliseconds. Probably not a big problem. But it also gives you a chance to make sure that you're getting the data you're looking for, that if there are any performance improvements that can be made on the backend side, you might find them here.

Okay, so we got to the network tab. And then, of course, there are other Chrome DevTools. So maybe one of the problems you have is that there are just way too many nested components. So you can come over here and look at your components and just see like, oh, fullscreen. Okay, you can just see like how many components deep everything is, the props and everything that they have on them. And it gives you a better idea of how things are actually being loaded onto your page.

All right, now that you know all about testing, let's talk about how you can keep your app performant. So remember, we were talking about those API requests that return a lot of data? Go ahead and try to virtualize those lists. So if you can do any type of pagination, or what is that the infinite scroll thing, if you can do that instead of loading a thousand items onto a page at once, that will definitely help your performance a lot. And then lazy loading. If you have, let's say, just a bunch of on-screen components, but they don't necessarily need to be available immediately, you can do something kind of like, where is that? This, maybe it's on a different one. OK, maybe it's here. Yes, it is here. So, pretty much, you can lazy load a component that you import. And basically, this makes sure that the page continues rendering until you have that component available. So, in its place, will be some kind of placeholder until that component's ready. And that saves you from your page hanging up on loading time. And, of course, you can cache your data. That's always fun and React comes with that service worker just already there. If you need something more advanced, definitely look into Google's Workbox. It has a lot of great ways to implement caching that won't frustrate you to tears. And, of course, make sure you're minimizing everything. All of your JavaScript, CSS images, whatever it is, make sure that it is minimized in your production build. Especially if you're using Webpack because it can do some weird config things. Handle your errors. We know sometimes you don't necessarily need to explicitly handle them. But make sure that you are handling the ones that have to do with rendering in particular. Because the last thing you want is an OnPage component that is infinitely loading and it just stops the rest of the processes from running. And last thing, make sure that you are chunking your bundles. So when you implement this lazy loading that I mentioned earlier, React has some package that if you're using Webpack, it'll go ahead and chunk every individual file.

So you end up with a bunch of tiny little bundles instead of that ginormous one that takes three seconds to load. So fun part, how do you clean up an existing app? The first thing you can do is code splitting. And code splitting is basically what we just mentioned, where instead of having that giant bundle at the end, you lazy load in all of your components and it makes individual bundles for each of those files. And tree-shaking, which is a funny term to me, but all it means is that you go through your code and make sure there isn't any dead code. If there's any code or any lines in your code that aren't being used, just delete them. All they're doing is taking up space and adding on to your bundle size, which makes it a little bit longer to load a page than it needs to because you're not using those values. And the fun one, always check for those unused packages because if you don't need the entire Lodash library, you can probably get away with just importing the parts that you need. Unused libraries are a huge problem for performance just because they make that bundle size so large that the upfront load time, it's just longer than it has to be. So if you have any unused packages, if you have any packages that you could just take certain methods or parameters from, try to do that. But definitely, if you're not using a package, get rid of it.