Your App Crashes My Browser

We asked some of our co-sponsors to present the framework. We're bringing free articles, videos, courses, and tutorials to help you learn all about React, whether you're a beginner or a pro. Introduced in 2011, the framework has become essential for web and mobile developers alike, enabling modern apps by look and function. And while other JS tools have expanded or revised its original notions, React's popularity is still the one to beat.

Did you know that TypeScript lets you write JavaScript the way you really want to? Explore the variety of Typescript courses we compiled from our speakers and collaborators and find out what you can do with this language and how it improves the development experience. Did you know that TypeScript lets you write JavaScript the way you really want to? Explore the variety of Typescript courses we compiled from our speakers and collaborators and find out what you can do with it.

After the coolest, trendiest topic of AI, let's go to the most neglected one of JavaScript and leaks. After the coolest, trendiest topic of AI, let's go to the most neglected one of JavaScript and leaks. After the coolest, trendiest topic of AI, let's go to the most neglected one of JavaScript and leaks. After the coolest, trendiest topic of AI, let's go to the most neglected one of JavaScript and leaks. So, anybody seen that screen? Maybe not in this type of projection. Imagine, that would be cool if there is some sort of astronomy presentation and suddenly Chrome crashes. Because I know it's Chrome behind all of this, of course. So, if you can't read it, it says, oh, snap. So, if you can't read it, it says, oh, snap. Because I know it's Chrome behind all of this, of course. Because I know it's Chrome behind all of this, of course. So, yeah, if you can't read it, it says, oh, snap. Out of memory. So, how many of you have seen this? Rarely, kind of, right? Because developers will use good computers and we rarely see this. But do you think anyone ever sees it? With your apps? How dare you? Never. How dare you? Well, you may be surprised. So, no one likes to see this. Because I know it's Chrome behind all of this. But you may be surprised. So, Nolan Lawson, a few years ago, he used a one-off tool called leak, in French. And expected the ten most popular SPAs. He basically was just clicking and going back to the home page. And lo and behold, ten out of ten have memory leaks. One of them even has 186 megabytes of leaks on a single interaction.

And these are the top ten apps with really good developers who work on them. So, it's not like we are lazy or sloppy. It's just leaks are easy to create.

All right. And a while ago I was working on kind of a famous social media site. So, we were trying to do the whole single-page app thing. And we figured out we have a problem. We crashed the user's browsers. Because we leaked memory. And where did we leak? I don't know. It's a big project. We didn't have good tools back then.

So, what was the solution? After 15 or so soft navigations, we just fully reloaded the page. Give the browser a chance to start over. Turn our SPA into an MPA. Just a moment. That was embarrassing. But, yeah. Today, things are different. Today we have tools. So, let's talk about...

So, this is the plan for today. First to figure out if we do have a problem. Because if it's more of a, I don't know, MPA, maybe not. Then try to figure out where the leaks are. And talk about some common patterns on how to fix them. Oh, about me. I'm currently a Red Sea web page test. A darling of the web performance community. Spent a bit of time on Facebook and Yahoo before that.

Doing web performance frontend optimizations. I wrote a bunch of books. This is my bestseller. I don't suggest you buy it. It's very, very old. Please don't. Then I wrote a bunch of others. Like maybe one of the first for React. Even the second edition. Please don't. It's already so out of date. But enough about me.

Let's talk about your application. So, the first step in addressing a problem is admitting that you have a problem. How do you know you leak memory? Well, luckily now we have the reporting API. It allows you to get data back from the browser whenever there is an out of memory crash in real life. So, you can stop guessing. Start collecting the data and see if you do have a problem. So, you can get, you know, those out of memory or responsive crashes. There's actually other things that you can get from the reporting API. Like if your users see a security violation, the CSP. If the browser sends any notes for deprecating features. And, okay. You discover that you do leak memory.

So, what are you going to do about it? Option A, call a friend. That's a person who knows all the secrets of the universe. And can dive into your app and unearth the leak. And then you go and fix it. And then everything's fine, right? No. The thing is, there's usually not a single leak.

And even if you fix the one, the next one is just around the corner. So, the better option, start debugging and taking some memory snapshots.

So, the idea is to have three steps. You load the homepage or the initial page. Then you perform some sort of action, interaction. And then you go back to the initial state. Every time you cause the browser to garbage collect.

So, you use the memory tab in DevTools. And garbage collect, take a snapshot. And at the end, compare snapshots one and three. And see if there's any difference. Are there any objects left that shouldn't be there? And if that sounds hard or non-trivial, you're not alone.

So, luckily, we can have some help from some open source tools. So, there is this one called Memlab that I want to talk about by Facebook. It's a command line tool. It uses Puppeteer to do those three steps. Load the page, do interaction, go back. And then uses some intelligence. Not artificial, I don't think. To make an educated guess and educated diff between the snapshots. And tell you where you have leaks and what objects are leaked.

So, it's been using at Facebook. Even doing find some leaks in React itself. So, this is what it looks like. You run it. And then here are the top section. It tells you what happened. Here in section number 2, it tells you what it found. In this case, it found over a thousand leaking objects. But they're all the same kind.

So, it gives you kind of the path to find the first one. And maybe you'll find the other ones as well. So, those graphs represent the memory usage every step of the way.

So, ideally it should look something, something more. And then go back to the bottom. And if it doesn't, you have a problem.

So, this example that I just tested was something like this. Like you create 1024 diffs. Add them to the window. And never clean them up. So, this is what Memlab was able to detect.

So, Memlab uses these so-called scenario files. It's just a JavaScript file. At the very minimum, you have to implement three methods. One where to go. Then what to click or interaction. And then write something, anything that Puppeteer allows you to do. To perform an action.

And then, similarly, anything you want to do to come back. So, there's additional APIs for cookies for login state. If the app is behind a login. But that's the bare minimum.

So, this is a real example from a real life Maps application. That you'll rename nameless. So, you load the map. Then you click a button that says, show me hotels around here. And then you say, no, no, no, forget it. I'm going to go back. Clear the search. Go back to the initial state.

And this is what Memlab tells us. This is the first step there was some memory used. Second step. And then the third we didn't go back to the beginning. So, all of this showing of hotels and stuff left some stuff behind. Leaks are everywhere. It's not our fault. We're not sloppy. We're not bad developers. Everybody does it.

So, if you rarely use Puppeteer, you're not familiar, it might be a little bit of curve to get off the ground. So, that's why I published one Chrome extension to help with that. So, there's a recorder panel in Chrome DevTools. And it's extensible. So, you can click around stuff and then export in a format that you like. By default it's exporting JSON Puppeteer and whatnot. So, my extension just lets you from your actions to export scenario.js file that can be used with Memlab. And I'm happy to announce I already have 50 users. So, there's 50 people who care about memory leaks. And it says featured. So, I guess it's all right to use. All right.

So, okay. You found the problem. So, how do you go about fixing it? Let's take a look at a few common patterns. In general, most of the times it's just some objects that are left over after they're no longer needed. So, most usually DOM nodes. In this case, you just have to find what's still hanging out in memory, assign null to it, and you're done. So, you can see here that signals to the garbage collection that this is no longer needed. And now can be safely removed.

Oh, let's play a game. Spot the leak. All right. So, we start with a simple React component. I know it's a class-based component, don't kill me. But for people who are not familiar with React or haven't looked at it lately, I think it makes more sense. It outputs some sort of content. Does something. And then when it is attached to the DOM, when it mounts, it adds an event listener and listens to key presses. That's why it's called Snoopy, because it snoops on everything you press. So, where is the leak? There's not too much code, so where could it be? Really? In this area. So, what's wrong with this? Okay. So, yeah. Basically when you remove Snoopy from the DOM tree, this listener will keep on listening, and this event listener will still be around.

Spot the leak, session two. Same thing, but we added a set interval. So, there's another listener that just counts time. Where's the leak? And when you remove, there's two listeners just hanging around. So, if you debug this with Memlab, if it's minified code, it's going to be horrible. You might not be able to see anything. So, that's why a good idea is to use non-minified code for debugging, and also to name the functions, right? Instead of anonymous functions, to use named ones. Anybody remember bind? Yeah. So, yeah. Now, when you gave names to our functions, non-minified code, named functions, using Memlab recorder, and then running Memlab with the Snoopy.js that was generated, and then we can look for stuff. And then, I don't know. That's kind of white. I don't know if you can see it, but our Snoopy key down and Snoopy interval are clearly visible there. You know where to look. So, how do we plug the leak in this case? Yeah. Well, we just add a component.

We'll unmount and clean up after ourselves when we're done. Right? In this case, the event listener has to be accessible for both. Did mount and will unmount. So, yeah. Simple. So, this is React. Any framework that you use, there's got to be some sort of way to clean up after yourself after the component is removed, and we should benefit from those.

Spot the leak again. All right. So, this is what we just fixed that works, and this is a leak. I'll just switch back and forth and see if you can see the difference. Yeah. I wish I was making this up, but that's a real-life scenario, something that a memo lab was able to find out. It's just somebody decided because they're not using typing and stuff like this to spell mount with uppercase. I mean, it kind of makes sense. Component did mount is uppercase. Unmount, yeah. All this cleanup work is for nothing.

One more time with hooks. Right. So, that people are not disgusted by the class-based components. Right. Now we have use effect. Right. So, in this case, we do two things. One is the event listener, the key down, and one is the interval. They could be in the same use effect, but I know personally, I prefer to have one for each chunk of work. So, the leak is obviously, again, when the component is removed, some stuff still hangs out. How do we plug it? Well, a use effect allows you to return a function, and that is the cleanup that you do.

How do we plug it? Well, a use effect allows you to return a function, and that is the cleanup that you do. So, yeah. Again, same thing. Return a function that cleans up after yourself. So, different API, class-based versus functional components, but still the same tools to clean up after.

Spot the leak again. Wow, that one's weird. Is this a memory leak? Yeah. Turns out it is. Turns out the console, you know, retains some references to the stuff it logs. And you can actually explore this in the memory tab in Chrome when you take a snapshot. Then you can filter by, you know, just things retained by the console. But, I mean, whoever puts console logs in production, right? No one ever.

To sum up, thank you very much for your attention. So, I don't want to be paranoid, but I think they're everywhere. Leaks, man, scary. And, yeah, when you come back tonight, that's the thing to do. Try the reporting API, then check whatever your framework of choice allows you. And just use null everywhere. Try Memlab and Memlab Scenario Recorder and see how that works for you. And that's some, you know, encouraging words in the end. As you can see, leaks are hard to find, but usually very easy to fix. Just assign null to things, clean up after, and just try to use the tools we have and find your first leak today. And this will make your users, if not happy, no one can guarantee happiness, right? At least a little bit less frustrated. And with that, I thank you very much. Yeah. Thank you very much. Just one second.

Thank you very much. Just one second. Hang on, hang on. I was wondering if we have time, but I guess we do. So, I'm part of the web performance community, so is Andrei. And this is one of the things, like I run an advent calendar called Web Performance Calendar on the website called Perfplanet. So every December, we publish one article a day related to performance. A lot of it is front-end performance, because that's where most of the time is spent. And over the years, we have some fantastic, I mean, it's been running over ten years. Like there was an article about how React reconciliation works. That was very popular, because it wasn't documented anywhere. So, yeah, if you haven't, reach over from the JavaScript land to the web performance land, learn about the latest and greatest. And also, it's very open to – it's all community driven. So whoever sends me an article, I publish it. This is the editorial process. So, if you want to share a story, you want to share any type of story or research or anything you did, case study, I'll be happy to publish it. Awesome. Put your hands together again for Mr. Stefanov. Thank you.

Very early in the talk, you'd mentioned, you know, talked about leaks, and you said, of course, it's Chrome. I thought I heard that. Oh, about the planetarium, yeah, that was a bit of a joke. I don't know if it is, but Chrome is everywhere these days. Right, right, right. Bloomberg Terminal and other places, so I was just kidding. I wouldn't be surprised if this wonderful display is powered by a browser. Possibly. We know the browsers are in space, right? But, I mean, I'm going to get back to that real quickly. So, you know, is there, in your experience, have you seen a particular browser have more memory leaks than another for any particular reason at all? I don't think so.

Not so much. And since we're both in the performance space, would memory leaks be more significant, say, on a mobile browser than not? Oh, good one. Good one, yeah, well, I mean, the leak is going to be the leak, but when you have less amount of available memory, the sooner you crash the browser. So, yes. So, generally, having said that much, we should certainly pay even more attention, as you know, the world pretty much is on mobile more than not. That's true, yeah. Have I just inserted myself into your deck now, is that it?

Okay, let's get to some of these questions, because we definitely did get quite a few. And this one right here has been upvoted quite a bit. How can you tell the difference between leaked memory and growing global state? Oh, well, good one. Yeah, well, the growing global state, I guess that's more about how you architecture the app rather than silly little mistakes that make stuff just get lost, and not garbage collected properly. But you don't expect the garbage collector to take your state and wipe it out, right? So, yeah, I think that's more of an architecture kind of thing. Okay. So, yeah, if you know that, yeah, that's kind of a clue. That's going to be probably even easier than hunt for memory leaks is if you just have some sort of timer that looks at your JSON dump of all the state, and just sends beacons every once in a while, and see how the state grows, and if there's a cause for concern. I know at least one company, I don't want to, you know, they'll write probably for the calendar, so it's going to be awesome. But they know the object that they usually leak, so they know what they're supposed to clean up. So they have a custom build thing that runs every once in a while and checks. All of these are expected to be garbage collected. How many of them are not? So, yeah, these are kind of custom thing.

Where the memo app and stuff that I was showing is like, even if you don't know what's happening in the app at all, you just want to find stuff. Okay. Let's get to this question right here. Actually getting back to what I'd mentioned, but, you know, if you want to expand on that. Mark asked, how to check mem leaks on mobile? On mobile. So, yeah, I mean, you can use dev tools to connect to a phone, right? And, well, yeah. Yeah, you can manually inspect it, right? So mem lab is not going to happen in this case because it uses Puppeteer to connect to the Chrome dev tools. But if you want to, yeah, actually, yeah, you can run Puppeteer on some sort of emulation of the website. And if you have access to the developer tools, developer tools protocol, then, yeah, why not? All right. Thank you very much for that question, Mark. Let me see here.

There's another one. M asks, do you know if there's a codemark slash plugin that would add names and bindings to the anonymous functions automatically? Yeah, I don't. I think that was something that's got to exist there. I haven't looked. Or maybe that's one application of AI, just go and name my functions.

Okay. Let's go somewhere else here. What is the biggest and most common offender of web performance in your experience? Okay. Oh, tough one, tough one. Neglect, usually. Sometimes we fix things and everything's wonderful and fast, and then we check six months later and everything's back to what it was. Yeah, I mean, unfortunately, when it comes to web performance, the most common answer, it depends. It depends on the type of the app. But lately, not lately, it's been a trend for quite a while. It's just the sheer amount of JavaScript that we ship out there. It's a common issue. And that's why we needed tools like this, right?

Yeah. This was built by Facebook when there was a redesign from the kind of a sort of SBA to a completely full SBA. And the amount of JavaScript and execution was bottleneck number one, which is insane. Yeah. And I would imagine you could speak with experience, having seen what was going on at Facebook back then and what you see today. So it's still kind of comparable? Or what? In terms of like the issue? Oh, well, I don't debug Facebook issues anymore, so I cannot tell. But as a user trying to post on the Facebook marketplace with Firefox, they have work to do. Okay. I like this question actually here, coming from anonymous. Is there a way to emulate having less memory? You can memory. I can't remember. Yeah. You can slow down. Yeah, definitely.

You can throttle the CPU. But that's a good one. We should talk to Chrome folks that are here. Yeah. And Addy's here too in terms of DevTools. So that might be a question for him. But great question, anonymous. Thank you.

Okay. We did that already. Can you expand on when a developer should set objects to null? Whenever you think you don't need it anymore, but it looks like it's going to be used, or whatever your tool says, okay, this thing is still around, and then you go and think, okay, why? Basically, everything you don't need, you should discard and give the garbage collector a chance. I'm going to get some water.

Okay. Here's a question. How to detect console log memory objects? Yeah. If you take a snapshot in Chrome DevTools in the memory tab, then you can look at it, and there's an option. It's kind of a newish one that you can filter only by things that are retained by the console. And also, don't console log in production right now. How useful are WeakRefs and WeakMaps for cleaning up memory leaks? Yeah. I really hope this company publishes this article, but that's exactly what they were using, WeakMaps, although MDN will tell you not to. Yeah. I think pretty useful. Are there CI tools to regression test releases for memory leaks? Yes. Yeah. I mean, you can integrate MemLab, and that's what we're doing at Facebook. It's on PR, diff, whatever you call it. You can run the tools and see if things have regressed, and yeah, it does actually run continuously. Okay. Another question that seems it would've been nice to even have – well, it's actually a nice connection between our last talk. Is there any AI tools that can not just detect leaks but can also remove them from your code? I'm not aware, no.

But, yeah, I mean, it seems like it's probably out there already. No. But who knows? Yes, of course. I mean, how many? There's a top ten. Yeah, yeah. No, I think we're kind of very early in the memory leaks tooling, which is kind of unfortunate. So MemLab is one of the very few things that we have. Yeah. So, yeah, if we can teach like a linter or something to just go and make sure that the cleanup hooks are really used, that'd be cool. You don't even need AI for this.

Okay. You just link the whole check. You just said that we're pretty early in the tooling there. Is there a particular reason why? Well, because we ignore this problem because we don't see it. So part of why I'm here is just to raise awareness. Awesome, awesome. Because, you know, I mean, who sees that out-of-memory crash in normal life or in development with the latest Mac?

And this'll be our last question. But, again, this would be – it's almost a nice amalgam between this talk and the last one to an extent, anyhow. How far will Lighthouse reports get you? If you get nice scores on Lighthouse, is that your performance audit done or will it only get you halfway? I do like that question. Anonymous? Yeah. And we just came back with Anri from PerfNow, which is kind of our yearly web performance conference, where I think Lighthouse was kind of not the darling of the industry at this point. So, yeah, Lighthouse is a good place to start, but the scores really don't mean anything, right? It's just kind of a way to give you an incentive when you see a number to make it better. It's more useful for regression testing when you run it in continuous integration and see if the score went down. So it's kind of all relative. But, yeah, Lighthouse score of 100 doesn't mean you have a fast website. Lighthouse score of zero guarantees it pretty much. It definitely gives you an idea that things are relatively all right, but you still might want to do some additional testing to make sure everything's solid and whatnot. We can get into that another time. Folks who are not familiar with Core Web Vitals, go check them out and read about it. Yes. Yes. I mean, Stoyan's going to be around, so you'll be able to ask him quite a few more questions if you do want. And, as well, you know, there were a couple of questions around Lighthouse, I feel. I think Addy would have you some – Addy could add some insight, is what I'm trying to say with that being said. Stoyan. Yes. Thank you very much for this Q&A. Give it up again for Stoyan. Thank you.