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

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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.

This talk has been presented at React Summit Remote Edition 2021, check out the latest edition of this React Conference.

FAQ

Load performance measures how quickly a website or application becomes usable after it is initially loaded, including metrics like time to interactive and first contentful paint. Runtime performance, on the other hand, focuses on maintaining interactivity and responsiveness after the initial load.

Blocking the main thread in JavaScript can lead to janky animations, input lag, and a poor user experience. The main thread is responsible for executing most of the code, and if it is blocked by computationally expensive tasks, the site or app will become unresponsive.

Common issues include computationally expensive tasks, large object cloning, animations, reflows, repaints, layout changes, parsing large buffers or JSON, and memory leaks. These issues can cause the site or app to become unresponsive or slow.

You can identify runtime performance issues through profiling tools like the Chrome performance tab, performance monitor, and user timings API. Indicators of performance issues include dropped frames, input delays, and in severe cases, browser crashes.

Perceived performance is how fast a website or application feels to the user, which can be improved by reducing or eliminating animations that delay feedback. For example, turning off animations can make an app feel faster even if the actual performance hasn't changed.

Memory leaks can be debugged using tools like the Chrome memory tab. You can take heap snapshots and compare them to see what objects are accumulating over time. Identifying and removing unneeded listeners and caches can also help mitigate memory leaks.

Iteration, especially unnecessary iteration over large datasets, can be very expensive in terms of performance. Operations like `find` on large arrays can be optimized by using lookup tables or more efficient iteration techniques to reduce computational overhead.

Animations that cause reflows, repaints, or layout changes can degrade runtime performance by making the browser constantly recalculate and redraw the layout. Using CSS transforms for animations and avoiding animations tied to user interactivity can help maintain good performance.

Runtime performance refers to the ability of a website or application to remain interactive and responsive after it has loaded. It focuses on ensuring that users can continue to interact with the site smoothly, without experiencing lag or delays.

Strategies include using regular for loops instead of complex array operations, avoiding unnecessary object creation, using lookup tables for quick access, caching results, and using tools like Immer for efficient state updates. Additionally, optimizing animations and minimizing reflows and repaints can help improve performance.

Ken Wheeler
Ken Wheeler
35 min
14 May, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
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

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Watch video: Speeding Up Your React App With Less JavaScript
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
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 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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 Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
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.