As you add more components to your React application, you'll start to notice performance issues. Maybe data isn't loading as fast or you notice that things are happening out of order. There are tools and techniques you can use to handle these kind of issue at a large scale. In this talk, attendees will learn how to analyze their React apps for solvable issues and learn some state management and async handling techniques.
Making Your React Apps Perform At Scale
AI Generated Video Summary
This Talk discusses making React apps more performant by analyzing their complexity, running performance tests, using tools like Lighthouse and the Profiler, and optimizing components and API calls. It also covers techniques for cleaning up existing apps, such as code splitting and tree-shaking. The main focus is on improving app performance by virtualizing lists, lazy loading, caching data, minimizing code and assets, and handling rendering errors.
1. Introduction to Making React Apps Performant
Hey, everybody. My name is Malisha and I'm a developer advocate with Conducto. Today I want to talk to you about making your React apps more performant. We'll discuss the initial React app, what happens over time, testing, keeping your app performant, cleaning up existing apps, and key takeaways.
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.
2. React App Complexity and Performance
So when you're starting a new React app, it's clean and empty. But over time, as you add more components and features, the code becomes more complex and the app slows down. To find problem areas, run performance tests using a production build.
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.
3. Using Lighthouse and the Profiler Tool
There's really not much point in running performance tests on a development build. Use the same version of your app that users will be working with. Make a minified production build and run it through unit tests. Use Lighthouse to get an initial performance score. Set the categories you want to check and determine if your app is up to standards. Lighthouse provides suggestions to improve your app's performance. The Profiler tool replaces the React Perf tool and allows you to profile components directly in the browser.
4. Profiling Components for Performance
This gives you a view of every single component on the page and how long it takes to load. It's a fast way to identify problem areas and find improvements.
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.
5. Analyzing API Calls with the Network Tab
The Network tab in the Chrome DevTools is essential for front-end engineers working with API calls. It allows you to monitor the data being sent and received, ensuring that the backend hasn't changed any parameter names. API requests can be a potential problem area, especially if a component makes multiple requests. The time it takes for these requests to complete can significantly impact your app's performance. By analyzing the Network tab, you can identify any bottlenecks and verify that the expected data is being retrieved. Additionally, you may uncover opportunities for performance improvements on the backend.
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.
6. Optimizing App Performance
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.
7. Cleaning Up an Existing App
To clean up an existing app, you can use code splitting to lazy load components and create individual bundles. Tree-shaking helps eliminate dead code, reducing bundle size. Check for unused packages and only import necessary parts. Unused libraries increase load time, so remove them. Unused packages should be removed entirely.
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.