Doing the Least Amount of Work Possible: An Intro to Runtime Performance

Rate this content
Bookmark

In this talk we’ll explore a variety of techniques one can employ to ensure that their apps are running at peak performance. With a couple of small tweaks, you can make perf a built-in.

35 min
14 May, 2021

AI Generated Video Summary

This Talk on runtime performance covers various aspects such as understanding and fixing performance issues, optimizing performance and perceived performance, profiling runtime performance, analyzing performance and debugging memory leaks, and dealing with memory leaks. It also discusses the use of dev tools, CSS transforms, and layout in improving performance. The Q&A session addresses questions about libraries like Immutable.js, common trends in memory leaks, and the impact of animations on performance.

1. Introduction to Runtime Performance

Short description:

Hey, everybody. My name is Ken and I am here today to talk about runtime performance. Let's get started by asking what is runtime performance. When we're talking about performance, we often focus on load performance, like site speed, bundle sizes, and parsing JavaScript. Time to interactive is crucial for users to start using your app or site.

Hey, everybody. My name is Ken and I am here today to talk about runtime performance. This is my talk, doing the least amount of work possible, which, while not only a performance tenet is a personal value that I hold.

So, let's get started by asking what is runtime performance. And you don't hear as much of it comparatively to some of the other stuff, right? A lot of the time when we're talking about performance, when you hear from, you know, I guess what would be devrels or platform advocates, the performance that they're advocating for is your load performance, right? Like a lot of conversion and retention and things like that. That all boils down to how fast your site loads and, you know, your time to interactive and things like that. You have all these lighthouse metrics and that's what's largely optimized for, right? You know, you're seeing things tooling like lighthouse scores, core web vitals now built into create React app. Things like page weight, right? Everyone's concerned with bundle splitting and keeping your bundle sizes in control. And that also funnels into things like the time it takes to parse JavaScript, like if you have a lot of JavaScript you're serving up, right? First contentful paints, right? You have these benchmarks of how fast your site's coming in and most importantly, I think, is time to interactive, which is the time until someone can actually start using your app or your site. They're in the clear to get going.

2. Understanding Performance Issues and Fixes

Short description:

While this talk is not about load performance, it focuses on staying interactive and not blocking the main thread. Issues like computationally expensive tasks, animations, parsing, and memory leaks can adversely affect the user experience. Slow performance, dropped frames, and input delay are indicators of a problem. Fixing performance issues often requires detective work.

While that's super important metrics and it's very well documented, that's not what this talk is about. This is about staying interactive, right? Once you've loaded up, once you've covered your bases, depending on what your app or your site does, what you want to do at the end of the day is continue to be interactive after you've gotten them to that meaningful checkpoint, right? And the core piece of that is to not block your main thread.

In JavaScript, you have a main thread, and it's where a lot of the party goes on. And if you block it, you're going to see things like animations are going to jank out, you're going to be typing into inputs, and there's going to be lag. All things that adversely affect the UX of your site or app, and you don't want that. So the typical issues that you might see, things like computationally expensive tasks, if you have to operate on or clone a big bunch of objects or something like that, animations is where you'll see it. A lot of the time, you got to go and start typing or start trying to click something or do a hover to see it, but if you have an animation going on, you're going to see that almost immediately if it's done a certain way, so it's going to jank out. And it doesn't even have to be like, you know, 900,000 objects. You can have your whole site get janked out just by Reflow, Repaint, and Layout. I was looking at a site for a buddy the other day, and he didn't have any JavaScript, but the site was running slow. And it was the web animations API, it was just browser layout taking place. All right? You know, other things are parsing, right? If you're parsing large buffers or JSON, right, that takes time. That's a computationally expensive task. And my least favorite of all, which you probably have the least insight into and takes real detective work is memory leaks. They're devastating. But again, that's that becomes really apparent. Oftentimes not very quickly. You have to sit there for, you know, an hour, and now the thing slows down. And then you say, oh, boy, like, you know, you have like a CSS problem, you refresh, and you can say, I changed this, I changed that with a memory leak. You have to wait an hour just to reproduce it. It's rough.

So how do you know that you have a performance issue? So I mean, obviously, you write your profile, but a lot of the time, if it's actually an issue, you'll know. Like, you know, as far as you hear a lot of talk about premature optimization, things like that. If you have a performance issue, a lot of the time, it becomes pretty apparent. Your thing will be slow, you know, unless you get used to it being slow. But that's a whole other talk, right? Your best case scenario is you're going to see a lot of dropped frames and things like input delay, right? Those will be the main indicators that you're having a problem. Your worst case scenario is an aw snap, right? And then this is where it memed out, and you know, it's totally crashing your website. So those two points and anywhere in between, it's indicative that, you know, you should probably take a look at the code and think about optimizing it.

So how do you fix it? You've identified that there is a problem. You're not sure what it is, but how do you fix it? And I'll tell you right now that a lot of it is like detective work.

3. Optimizing Performance and Perceived Performance

Short description:

Performance is not prescriptive. It's about finding clever ways to do less work and achieve your goal. Using a regular for loop instead of chained maps can save time. Unnecessary iteration in array operations can be avoided by using lookup tables. Creating new objects and arrays can be costly, so direct mutation or structural sharing can be more efficient. Perceived performance can be improved by turning off animations and providing instant feedback.

Performance is not prescriptive in the sense that I can't tell you a checklist of things like I can with, you know, like Lighthouse. I can't be like, well, you know, do you bundle splitting and put this stuff in the head and this stuff at the bottom. You know. A lot of the time it's a problem that you've created the way that you've coded it. And you have to untangle that, right? It's a thing that you have to get clever about. Sometimes it's the reality of the requirements of the app. And then you have to find a tradeoff or a sneaky way to do less work. Right? When you're optimizing for performance, if you want it to go better, you do as little work as possible. Not you personally, your application. You want to do the smallest amount of work possible to achieve your goal. Otherwise you have inefficiencies, and at scale they blow up. Right?

There are some semi-prescriptive things that I can get into. Right? Obviously it has to apply to your situation, but... Things like using a regular for loop. If you're saying, hey this takes too long, how can I make it go faster? Where can I get a little here? If you're sitting here getting all fancy with all of these chained maps and all this, this and that, if you do it in a regular for loop, at the scale where it would matter, you can absolutely get some of your time back using that. A lot of array operations, right? Like if you're doing a find in an array or something like that, right? One of your biggest enemies in performance optimization is iteration. Especially unnecessary iteration. So if you have an array of like 500,000 items, and you're gonna do a find on it, or you're do any of these array prototype operations that are gonna run through the entire thing until it either exits or completes, that's expensive, right? So if you have like an ID, say, I have this ID, I wanna find this row that has this ID. You can create a lookup table. And a lookup table is a stupid term for, I mean, maybe not a stupid term, but if, you know. It's an object, right, where the key, right, would be your key, like an ID, like the thing you wanna look for, right? And then you could have the value of that be the index position of your thing in the array, right? So it's a very cheap way to find that thing, right? So you're saying like, oh, well, I have to update thing ID equals this, say, hey, lookup where is it? And it's just, bap bap, bap bap, and then you're good to go. Rather than saying like, find with a predicate function that looks for the ID or something like that. Another thing that you wanna check out, especially, especially costly, is creating a bunch of new objects. And that's objects and arrays, right? There's a lot of fanciness going on in dev these days with ES6 or Next or whatever we're calling it these days, where you use spreads all the time and spreads create new objects, right? So if you're dealing with things on the magnitude scale of hundreds of thousands of things, and you're creating new objects, what that's gonna do is that's gonna force garbage collection and it's allocation costs as well, but that is gonna hose your stuff, right? If you can do a direct mutation, and I know that's a dirty word, but if you can do a direct mutation then you can see some savings. An alternative is to use something like Imr, where you have structural sharing, right? Where it's not performing a clone to do an update, right? It's not necessarily mutation or imperative, but it's a way to do it that's much cheaper. One thing that's really funny that I wanna talk about for a second is perceived performance, all right? So there's performance where things are actually slow and actually blocking the main thread, but there's also scenarios where you can make things feel faster without it actually ever being faster. And you could do that by turning off animation in a lot of cases, right? So if you, I had an app where I was redesigning it and people were like, wow, it is blazing fast right now. What did you do? And I just turned off animation, right? If you have this animated hover type thing, while it looks cool, right, the perception as you're going through is that it's slower. If everything is instant feedback, it feels faster. So perceived performance, you know, that's kind of like you go back to like the suspense with the loading spinner thing.

4. Perceived Performance and Profiling

Short description:

Perceived performance is important, as it affects the user experience. Avoid reflows and layouts that cause the browser to redraw unnecessarily. Caching can improve runtime performance by memoizing expensive operations. Pay attention to performance minutiae, such as using 'undefined' instead of 'delete' for faster object deletion. Profiling is key to solving performance issues, and tools like Chrome performance tab, memory tab, performance monitor, and user timings API can help. Let's explore using dev tools and optimizing performance in a React app.

There's something to be said for perceived performance, especially in the UX area. Another thing I might go into is to avoid reflows and layouts. And I'll show that in a little bit, how that can happen. Yeah, you don't even need expensive things to be happening. If you're animating things or popping things in and out, and it is causing the browser to redraw, then that's not great. That's gonna—that doesn't even need computation because the browser redraw itself will jank everything out.

Caching is an easy way to improve your runtime performance. A lot of the time, you'll see on every single render, people will call a date format or something like that, and a date format is expensive, or create a date object. If you can memoize that, if they're not changing and you don't expect to rack up this 2GB cache of date objects, then what you're doing is a sneaky trick, where you're saying, I'm gonna format these dates once, and then any subsequent call to format for that date, if we're rendering this, if we're clicking a checkbox and it's just enabled or not, it has nothing to do with the date changing. It's gonna serve up the string BAP BAP, and you're not gonna take this hit on every single item getting date formatted.

And then there's minutiae. And the minutiae, a lot of the time, it's overkill. But when you're really grabbing for stuff, especially in large row count iteration kind of things, doing something like if you're gonna delete a bunch of things out of an object, it's way faster to set it to undefined instead of using the actual delete keyword. And like anything else in performance, there's a trade-off, where those things are still gonna come up and it has own property or something like that. But then you just have to be wary of it, because there is a trade-off for everything.

So, I wanna talk just for probably the rest of this talk about profiling, because that's how you're gonna solve these issues. And outside of the semi-prescriptive stuff that I just mentioned, you wanna find your issue and identify it so you can begin architecting a solution to it, right? And some of the tools that I'm gonna show and that we're gonna use are the Chrome performance tab, the Chrome memory tab for memory leaks, your performance monitor, which is very helpful with CPU, and the user timings API, which is amazing. So let's learn how to use dev tools a little bit. So I have this little create React app business going on here. And in here I'm gonna create a million rows in an array here in this initial list. And then we're just gonna push them, right? And then I was gonna Live code it, but I'm not gonna do that right now because we're running out of time. And I want to get to this. So we have this list, this initial list, million things, right? It's got an ID and a value that's random. And then we're just going to use that as state here with the initial value, right? Then on mount, right. do an interval. Every 500 milliseconds, what I'm going to do is I'm going to call set list with our list, right. So this is going to this is a set state, right with the list. I'm going to spread out that list, clone it to create this new list. And then I'm going to iterate through and spread the old values in in this spread. Remember what I said about the spreads, so this now it'll get its ID, which, you know, Ridiculous because it's just the index, but it's contrived bear with me.

5. Profiling Runtime Performance

Short description:

And then we're just going to add a new value and return the new list. Let's take a look at how we can profile this. Open the dev tools, hit record to start profiling, then hit stop. In the profile, you'll see the main thread, raster, GPU, and compositor. Each update goes from parent to child. The anonymous function runs internal React stuff and tries to render the app in response to the state. Creating many new objects leads to garbage collection and 10ms delay. The red indicates blocking, with an enormous amount of missed frames.

And then we're just going to add a new value and then we're going to return the new list. So we're updating that list here every 500 milliseconds of a million things, right? So let's take a look at this. And I'm going to show you how to how do we how do we profile this, right?

So we have our slow app here. So I'm going to bust open my dev tools here. And we're going to we're going to take a look, because we're gonna learn how to read this today. You hit record, right, and it's going to start profiling your runtime performance. You hit stop. And now we can look in here. And if you see, so first of all, this is your main thread. I'm going to just walk through this for a second. This is your your raster your GPU your compositor. If you have workers that will be on a separate line. Now it's having a really bad time here. I might drop that countdown.

So each one of these right here is one of those updates that you're seeing. And it is going to get it's going to go from parent to child in the call, right? So you're going to see I have this anonymous function here. It's going to run through a bunch of internal react stuff. It's going to try to render app right in response to the state thing. We get down here into our state reducer. This is the actual internals of that. And then you're going to see this. These are all anonymous because it's not a named function. The reducer on that set list. But you're seeing this and when we're creating that many new objects, that's where you get this garbage collection. That's taking 10 milliseconds, right? So in order to do that, right? We're looking at 375 milliseconds. When you look up here and you see this red up here, that means when you're actually blocked, right? And you'll see down here, it's going to say total blocking time. So it'll show you that. And you have an enormous amount of missed frames in here. The red is bad. And I mean, if we go and look, I mean, I think it's having a pretty bad time right now.

6. Analyzing Performance and Debugging Memory Leaks

Short description:

So we can go to more tools and we can go to performance monitor. It's gonna tell us that we're almost at 100% CPU. The heap is humonganoid, not that many dom nodes. Let's go back for a second. We're gonna run a profile again. It's still pretty bad, 60 milliseconds, like several dropped frames. We can look at memory here and debug memory leaks. Take a snapshot, sort by shallow or retained size. Look at the diffs, what is accumulating. Our problem is in this anonymous function. We want to take a look at the minutiae. Use the user timings API and do performance.mark, list clone start.

So we can go to more tools and we can go to performance monitor, right? And it's gonna tell us that we're almost at, you know, 100% CPU here and there. The heap is humonganoid, not that many dom nodes.

So let's go back for a second. I'm going to take this down to 20,000. All right. And then we can come over here and it's not so bad anymore. Orders of magnitude less, but it's still not great. We're gonna come in, we're gonna run a profile again. All right. So for less things it's not as bad, but it's still pretty bad. It's 60 milliseconds, that's like several dropped frames. We can go and look at memory here. And this is how you debug memory leaks, right? If you take a snapshot here, a heap snapshot. Um, one common way that I'll do that. There's a lot of objects in here, so it's thinking and I'm screen sharing. God, relax. Yeah, so you have here. And then what you can do is you can, sort by shallow or retained size. And then if you take subsequent snapshots, you can go through and you can see what is what? What is happening? What's more, you can even go and you can, um, if you do two, right, there's a good diff. Right? I'm not going to do it again because it takes a while to do, but so this, you can see objects allocated before snapshots. You can look at the diffs of, you know, what is what is accumulating in here. And that's pretty helpful. Um, wait.

So here, right. We know that our problem is, you know, in this anonymous function. But the problem is, is that this kind of gets like quantized into, um, these blocks. Uh, so what we'd want to do is take a look at the minutiae and the way that we would do that, what I'm going to do is I'm going to do 5,000 just so it's not so devastating. Um, but what we can do here is we're going to use what's called the user timings API. And it's amazing. So you can do performance.mark, right? And we'll call it list clone start.

7. Profiling Performance and Analyzing Animation

Short description:

And then we can come down here and I can say performance dot mark, list clone stop. And then right here I can say for each one of these, well, before I do that I'll say performance dot measure, right? And you have your measure name, so we're going to call it list clone. And then you have your beginning and end, which are going to be list clone start. And list clone stop. Down here I'll say performance dot mark and we'll just call this one, two, right? We'll call it one and two, right? And we're actually gonna be able to see granularly what's happening here, which is going to help you and your profiling. This might take a second. You can do it. You can do it, I believe in you. Now we get to see granularly what's happening in here. So you have the mark measure, that's in there. But if we go up top into timings here, we can zoom in. And we can see exactly how long these things take. This is a great way where you can granularly take a look at what's causing problems. Now I'm already over time, but before I bounce, I'm going to show you an example of when it's not even JavaScript that's doing it. We have this rascal rotating and this animation takes place on a different thread, so it's not a problem. It's also using transform, so it's composited, which means it's drawn as like a layer on top of your website.

And then we can come down here and I can say performance dot mark, list clone stop. Right? And then right here I can say for each one of these, well, before I do that I'll say performance dot measure, right? And you have your measure name, so we're going to call it list clone. And then you have your beginning and end, which are going to be list clone start. And list clone stop. Down here I'll say performance dot mark and we'll just call this one, two, right? We'll call it one and two, right? And I can hit save there, then we can come back here. It's probably going to yell at me. Let's refresh you, come back here. And, you know, rather than that bucketing into the, the wild stuff, you know, we're actually gonna be able to see granularly what's happening here, which is going to help you and your profiling. This might take a second. You can do it. You can do it, I believe in you. All right, I'm gonna do a quicker one. Nobody's got time for that. Come here, you. Okay, now, now we're talking business. Okay, so here now, above main, you see a new thing called timings, right? And previously, when we looked over here, and we look down here, and we see these anonymous, right, that's where it topped out. Now you get to see granularly what's happening in here. Right? So you have the mark measure, that's in there. But if if we go up top into timings here, we can zoom in. And we can see exactly how long these things take. Right? Like, this is an iteration, right? So you see the one, two, iteration, and that's in that's in microseconds. I'm trying to see if I could see a one of the clones. It's probably in the beginning here. Yeah, so you see the list clone takes a fraction of a millisecond. Obviously, if we were up at a million, there'd be quite a few of these, and I probably just do the clone rather than the individual ones. But yeah, this is, this is a great way where you can granularly take a look at what's causing problems. Now I'm already over time, but before I bounce, I'm going to show you an example of when it's not even JavaScript that's doing it. Right? So before, and let's take a look at like, when we go here, right, you're seeing some information in the summary right here, and then it's going to say the aggregated time and it's almost all scripting, right? So that's telling you like, your JavaScript's the problem but a lot of the time JavaScript is not the only culprit here. So we have this rascal rotating and this animation takes place on a different thread, so it's not a problem, right? It's also using transform, right? So it's composited, which means it's drawn as like a layer on top of your website. When you use like translate or rotate, it's not actually updating layout, it's not moving things around on the screen it's kind of just like in place.

8. Understanding CSS Transform and Layout

Short description:

So if you translate, right, like the area where it is is still there. It's just up, right? Because it's being composited, right? So you don't take the perf hit there and then that's why they say to use the transforms if you don't want it to be janky. But if I come here and I do a layout forcing thing, like if I were to animate height for example, so if I were to come here and I was going to say height and we're going to go like 200 pixels height to 400 pixels, right? And we come over here, all right, you're going to see it kind of jank out, right?

So if you translate, right, like the area where it is is still there. It's just up, right? Because it's being composited, right? So you don't take the perf hit there and then that's why they say to use the transforms if you don't want it to be janky. But if I come here and I do a layout forcing thing, like if I were to animate height for example, so if I were to come here and I was going to say height and we're going to go like 200 pixels height to 400 pixels, right? And we come over here, all right, you're going to see it kind of jank out, right? You might not be able to see it on the stream, but what's happening is when this gets bigger, every single time the browser's internal layout system has to recalculate where all this shit is supposed to go. So if I come back over here and now we profile this, it's going to tell a very different story. Probably not as clearly as it did with the more expensive things. But if we come in here, right? What you're going to see is a lot of green and purple. And what that is and see all these drop frames? What's happening is this is style recalculation and layout and then repainting, which means the browser constantly has to redraw the entire thing that you're looking at because the height is changing, which is invalidating the layout. And you can see in here it's saying rendering, painting, and not just that, you could see the compositor here is going absolutely bananas and you're getting GPU hits over here on the paints. You don't need JavaScript to destroy your runtime performance. You can do that all your own just with CSS.

QnA

Runtime Performance and Q&A

Short description:

So today, I've put the spotlight on runtime performance and explained dev tools. Thanks for joining the talk. Now, let's address a question Ken asked earlier. He inquired about using the performance panel in Chrome DevTools. The poll results show that 64% of you have used it but aren't fully familiar with it, while 22% know how it works. For those who haven't tried it, I highly recommend giving it a go. Now, let's move on to the Q&A session with Ken Weaver.

So I hope that today I've done a good job of putting the spotlight on runtime performance and also explaining dev tools a little bit better and giving the tools you need to make your sites continue to stay interactive and fast.

Thanks so much, everybody. Awesome. Thank you so much for that cool talk. I really, really enjoyed it. I hope you enjoyed it too. The awesome Ken Weaver.

Let's go and check out a question that Ken asked us earlier. So Ken asked if you have used the performance panel in Chrome DevTools. And the poll is yes! Well, 64% of you said yes, but you're not 100% sure on how it works. 22% of you know or said yes, and you know how it works. And 14% said no. I highly recommend them. I think they're awesome. So definitely, try them. But before we go on, I'm going to invite Ken to answer your awesome questions. Ken, how are you doing? I'm outstanding. How are you doing? I'm doing good, I'm doing good. You know what? I love your setup. I love the vibes. I can just picture some lo-fi beats playing around in the background. Just a quick question. This is just for me. What's your favorite kind of music to play while you're just chilling? When I'm chilling or when I'm coding? All. Both. All right. So if I'm coding, I don't like stuff with words in it, right? So I'll listen to like lo-fi beats or like the Westworld soundtrack, that sort of thing. Trent Reznor albums or something. Because it doesn't take much to process. But if I'm just chilling, like usually like some fun trap music or something.

Dealing with Memory Leaks

Short description:

If you suspect a memory leak, the first approach is to try and reproduce it. It often takes time and patience to identify the cause. Snapshotting and monitoring the memory usage can help in finding the buildup. Hunting down memory leaks can be challenging and frustrating.

Awesome. Nice, nice. I could talk about music with you all day. But we've got some actual developer questions that I want to answer. The first one I find it hilarious, but I'm still going to ask it anyway. If you suspect a memory leak, do you try to debug it or do you smash it with a code review hammer or do something else? What's the first approach to deal with it? If I suspect a memory leak, I go get like a glass of water or coffee or something. Because most of the time, when I encounter memory leaks, you know, it's the sort of thing where you have to sit there for like 45 minutes to reproduce it. You know, like very rarely do it like one of these things like just like, you know, you get the OSNAP and the browser crashes, right. It's always this thing where like over 45 minutes it grinds the halt. So, like, all right, well, you know, I'm gonna sit here and do something else while snapshotting here and there and then we can see what's building up. I've definitely been in that position trying to hunt it down before. And it can suck sometimes.

Q&A: Libraries like Immutable.js and Memory Leaks

Short description:

Have we got another question from W Warrior? What do you think about libraries like Immutable.js which create new objects by design? I mean, Immutable is cool but, Immer is pretty much my go to now. Someone asked about just a different memory leaks that you fixed. Have you ever seen any sort of common similarities or common trends across them? Well, I mean, like one thing that happens a lot is like listeners, right? Like if you add listeners and then don't remove them, that's one that happens a lot. And the last question, someone, Alex, has said thank you for sharing how animations can be a performance hit. Animations can still be really important though, so the answer, so they're asking, should they just use animation sparingly or are there other techniques for having performance animations? You know, I think that there's, I don't think all animations are bad. I think the ones you need to watch out for are animations that are tied to user interactivity, right? So like if you're like moving through, if you're highlighting something or highlighting rows or something like that, that kind of thing, I wouldn't animate that because it's putting a buffer on the feedback to the action, right? But I mean, if you want to have like a Josh Camus, like whimsy style animation, that's, yeah, go ahead. That's awesome. You know, that's not necessarily directly tied to the that sort of thing, right?

Have we got another question from W Warrior? What do you think about libraries like Immutable.js which create new objects by design? I mean, Immutable is cool but, Immer is pretty much my go to now. You answered the second question which was, do you see any alternatives? Is there anything specific you like about it? It's pretty straightforward, right? Like, you know, you use the produce function and then, you know, mutatively edit whatever you want to do and it applies it. Nice, nice. So we've got another, sorry, say again? I was just saying it's simple and it's fast. What more can you want? Nice.

We've got another question from Pop Linguy. Could Firefox performance tools be a concurrent of Chrome developer tools or Chrome dev tools? I think comparing the two. I honestly couldn't speak to it. I haven't used Firefox in quite some time. But the last I checked, you know, they do have some interesting features. Same can be said for Safari. There's some interesting graphic debugging stuff in there too, but I spend 99.9% of my time in Chrome. Yeah, same as well.

I'm a big fan of Chrome. Someone asked about just a different memory leaks that you fixed. Have you ever seen any sort of common similarities or common trends across them? Well, I mean, like one thing that happens a lot is like listeners, right? Like if you add listeners and then don't remove them, that's one that happens a lot. Other times, you know, you can just have something that's building up over time, right? So say you cache some data, right, every time you load a page, right? But if it's a single-page app and there's hundreds of pages, you know, if you navigate through hundreds of pages and that cache isn't periodically cleared, right, depending on what's in there, right? It's not just like markup, but like, if you're loading like 500,000 row datasets for each thing and, you know, you're navigating between those, eventually that'll build up. Other times, it's kind of just like iteration and timers, right? If you have like real-time data and you're iterating through things, little caches and stores can build up.

Cool. We've got another question. It's another joke question, but, you know, I feel obligated to read it out, so I'm gonna go for it. This is, do you do a regular check of your memory profile or do you wait for problems to come knocking at your door? Not, I mean, it depends, right? Like if I'm making like a Ken Wheeler joke, like if I'm making like a kenwheeler.blog I'm not really checking the CPU on that, but if I'm making like a, like a high-performance canvas control or something like that, like, I'm definitely going to pre-emptively look at where the CPU is, like in early to mid-stage development just to make sure, you know, set baselines so that later on, as it gets more complex, right? You can say like, you know, what are we getting and what are we losing? That makes sense.

And the last question, someone, Alex, has said thank you for sharing how animations can be a performance hit. Animations can still be really important though, so the answer, so they're asking, should they just use animation sparingly or are there other techniques for having performance animations? You know, I think that there's, I don't think all animations are bad. I think the ones you need to watch out for are animations that are tied to user interactivity, right? So like if you're like moving through, if you're highlighting something or highlighting rows or something like that, that kind of thing, I wouldn't animate that because it's putting a buffer on the feedback to the action, right? But I mean, if you want to have like a Josh Camus, like whimsy style animation, that's, yeah, go ahead. That's awesome. You know, that's not necessarily directly tied to the that sort of thing, right? Yeah, no, I get you, I get you.

And right before we go, because I know we're running out of time, but you're off to do a DJ set. Is there anything you can tell us about what to look forward to for your music set? Not really, I'm just gonna play some shit that I like. I mean, you know, it's not like, my Porter Robinson up here and I'm just gonna, you know, drink wine and play some nice beats, everybody else should grab a beverage. Well, once I'm done, I'm gonna go and grab some wine and listen to some beats. Thank you so much for hanging out with us. I love the tour. And hopefully I get to see you again soon. I'm definitely going to check out the music you'll be playing. Thank you so much and I'll see you around. Thank you.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn