Perfecting Your Profiling

A bit about me. I've got four kids and two dogs so profiling life is very important but unfortunately it doesn't seem like anyone's made like a DevTools for life. If you have or if that's your business idea, let me know. I'll be one of your beta testers.

But in my professional capacity I work at AGGrid and we've got both AGGrid and AGGcharts now. So these are React components you can drop into your application and everything's batteries included, you've got your grid, throw your data in, you've got your charts, and you can produce these beautiful visualizations with very little effort at all. So if you want to know more about that, come and speak to us at the booth.

But I know why you're really here is to talk about profiling. So this is going to be or this was the content of my talk until a few weeks ago. So I'm going to start with the React DevTools. We're going to look at the Web Vitals extension DevTools performance panel in Chrome and then I'm going to throw some quick fire hints at you from things that I've learned while profiling AGGrid.

But as I said, this was the talk and then Chrome made a big update where they deprecated the Web Vitals extension and they've moved this into the performance panel and it's now called the real-time metrics view. So this is a really quite exciting change because it's bringing all this features and usability that I think was underrated and underused in the Web Vitals extension directly into your performance panel. And hopefully you'll see by the end of this talk just how valuable that information can be for you.

So first of all, the React DevTools. Now this says it's been downloaded 4 million times, so I'm guessing pretty much everyone here has got it downloaded. Yes, that's good. As many of you here have downloaded it using it. A little bit more quiet. So yeah, so once you've installed the extension you'll have this profiler and also a components option in your DevTools. So you can find it in there. You might run into this issue initially saying profiling is not supported. So make sure your version of React is recent enough and also that you're in development mode because you can't profile against production because this profiling inside of React adds extra delays and work. So React strips it out in production so that your apps are as fast as possible. So you're either going to be developing against React development mode, which you have to remember does additional checks, but then React does also have this dot profiling version of the code as well. So it doesn't do all the dev checks but it still has the profiler to give you the information.

But once you've done that and it's working you can record a profile. So here on this beta version of AgGrid I was doing some performance testing on dragging columns and resizing them. So I recorded the profile, did my action and then here we have this profile. So we can look through the different frames, so each one of these bars or 254 of them are individual renders, and we can go down and we can start interacting with this flame chart and click on these individual things and see okay which component is it? And also this is going too fast let's slow it down. Or I won't, I'll come back to it in a bit.

And it can then drill into that and say okay from this component which hook is causing this to render a lot? So what you maybe saw here or maybe it didn't catch up with is the thing to take away from this profile was there's a lot of rendering happening while we're resizing these columns. And then we can go down into that flame chart and it gives us the component names and we can click on it and it will say well hook 30 changed. And then once you've clicked on the component you can actually click from the profile to the components I guess tab in your dev tools and then look down the list of all the hooks.

And for us number 30 is this state width. So it's a very quick way that it's enabled us to pin down to the exact state hook that is causing our component to re-render. So then we can dive into that code and we'll see something like this. We were using the width property which was being updated to then change the style on this on this div element. And so every time the style was changing you know as we were dragging things around React was re-rendering all of these cells and so that was the 254 kind of events that were being fired. So we can actually make these change and this is the topic of a whole nother talk. We can just actually change this style directly. We're not changing any of the structure of React we're just pinpointing this DOM element and saying actually we're going to take care of the styling and we're just going to tweak the width. We don't need everything to re-render we're just going to change it and the result of that is now in Azure Grid when you're resizing columns there is no re-rendering. So here there's two renders here instead of the 254. So you're getting a much smoother much more like kind of native experience with these moving of the columns. And this was all very easy to diagnose via the React dev tools. And these are some important settings which you need to enable to give you this useful information. So in the profiler you can say record why each component re-rendered while profiling. That's not on by default I don't think. So if you turn that on it then gives you that information of actually it was hook 30 that caused this component to re-render. So this is really key information. And then also there's this other bit under the components panel which says you know parse the hook names. So instead of on the left where you just have these states and their values you actually get the name. So again this is just going to make you much more productive in being able to say okay it was this hook and then this is actually the one in my code that I know I need to look at. And then also another useful thing I think we've seen in some of the talks before is even if you're not profiling you can enable this flag to highlight the updates. And again we could see it here we start dragging the columns and you can see all these cells re-rendering.

So it gives us I guess a quicker way of just interacting with our app and seeing all the things that are changing. So I thought this was a useful video if you want to kind of watch it in your own time. And there's quite a lot of videos out there I think this one has a good mix of content and also it dives into the different formats of the charts that you can use within the React DevTools. So I'd recommend watching that one for a little bit more of a slow-paced talk.

Another thing that I want to cover is Core Web Vitals. So these are metrics which are really important for your application, especially if you're looking to improve your SEO, your result in search, because it's kind of how Google will rank your website. So it's really important that we do metrics for that motivation, but also it gives your users a better experience. So you've got benefits in that sense, the people will want to come back and use your site. And the one I'm going to focus on is interaction to next paint. So this is new as of March this year and it observes the latency between when a user interacts with your site and when they actually get some visual feedback.

This is something which React Concurrency and all those concurrent features are able to really help you do and improve. So as I was going to say, the Web Visuals extension was a really good way of viewing this information, but it's been deprecated. So I think it's important to notice here, this has only been downloaded about 100,000 times, compared to the 4 million times, or even more than 4 million, but the React DevTools have been downloaded. So it's clear that the information here just isn't reaching the wide audience that it could do. So that's why I think it's really exciting, thank Chrome version 129, a lot of this information is moving directly into your performance panel in the, what they're calling, real-time metrics view. So in this, we'll see, I'll open up a profile in a bit, but it's giving you the same information and also there's some really useful ways that it can compare it to your field data if your website meets the criteria for the crux database. And also then it can tell you, well actually, your development machine, your interaction to Nextpaint might be really good, but compared to what we're seeing as real life traffic on your website, it's very different. So maybe then you should go and enable some of these throttling settings. So you can slow down your network, slow down your CPU, and then rerun your tests and see what real users might be experiencing on your website.

So maybe then you should go and enable some of these throttling settings. So you can slow down your network, slow down your CPU, and then rerun your tests and see what real users might be experiencing on your website.

So this is an example which would work in the performance panel, but this is using the Web Vitals extension. So when we were testing, I was testing this on our website and typing into this quick filter. So the quick filter then passed that text off the grid to filter, I think in this case it was a hundred thousand rows. And what the Web Vitals extension and also what you'll see in the interactions list in your performance panel is you'll start getting these red interactions, saying well actually the time between the user typing and them seeing the browser repaint is too long. And so you're not having to profile or anything, you can just open this up, start interacting with your website and see whenever this goes red.

So what was happening here is that the quick filter text was being passed directly into the grid and so every time that the quick filter text changed, the grid was then refiltering everything. And so what we can do is we can just defer this filter text. We use the use deferred value hook and then what this hook is going to do is say well actually this value is not critical that it updates immediately and synchronously. Actually what I want you to do is make sure that the browser has the possibility to update and re-render. And while the browser is, while we're yielding to the browser to do that, just wait with this deferred value, the last one, until the browser is finished doing its work and then you can get on with your filtering. And so if we make that simple change we can now see, we can type into this filter box, we're seeing every single key press and we're just getting logs of green interactions to next paint. So that's how you can use those those metrics to interact with your site and see where things are that you need to improve.

And once you've done that, or you've worked at that level, sometimes we need to go even deeper. And this is, that is the phrase of the conference isn't it, let's go deep. So the Chrome DevTools Performance Panel, when you start recording these profiles, this is when you really can go deep. You can find individual methods that are taking longer than you expected, or you can start getting into the world of forced layouts and css and all these kind of thrashing issues that you might find.

So this is something which I've done for EduGrid as well. So I'm here on profiling the performance of our scrolling, and the grid here is the vanilla js one. So I've recorded the profile and then we get this table. And what we're actually going to do is dive into this together. So you can save profiles in, once you've recorded them, and then load them and share them. So we've got this view. So this was the result of creating a profile while we were scrolling. And what we can do is we can zoom in here to a particular section. We can see we've got all these different tasks.

And what I'd like to do is come down here to this bottom up panel, because what this enables us to do is quickly see, well, based on this self time, this is the place where most of the time is being spent while we're rendering. So you've got total time and self time. Total time is, say, your method ends up calling down in a call stack to some other component. That takes a long time. So the total time at that top level will include all the time of the children methods. But that's not quite so useful, because the time isn't spent in that top level. You want to know where is the function that is actually taking all this time. And so that's what self time gives you.

And what we can see here is that actually it's this parseHtml is taking up about 34% of our rendering times. And now we can start drilling into this. Maybe I'll make it a bit bigger for you. And we can drill in and say, well, it's coming from set in the HTML, which is within our cell component. So now that gives us a way of being able to say, well, actually, okay, I can go and check and see, well, what is the code that is causing this thing to happen? Because the other way you can see this is if you zoom all the way down here, zoom in, zoom in, you get your method names of what's being called. And then it's all these little blue boxes at the end is the parseHtml. So you can see if we can speed those up, we're going to speed everything up. And that's exactly what we were able to do.

If I load another profile. Oh, that's saving it. Sorry. This one. So after the change, and I'll show you the code that we actually changed, you can see things have really improved. And we've lost that method from this chart. So we can see, okay, we've done a good job. We've managed to identify what the slowest part is, and we managed to get rid of it. And this was the code change. We just simply changed from setting something from innerHTML to text content. Because when we weren't in React, we were managing these things ourselves. So innerHTML, just for a bit of context, it can accept a string which contains HTML elements in it. So there's added overhead here of checking what that string is, matching things and saying, do I need to parse it and turn it into some DOM elements. So if you're just setting text itself, it's much quicker to just use text content, because the browser is like, well, this is just a string, I'm just going to display it. And so in doing that, we got some massive performance improvements within the grid.

Another thing, which I guess is another area of performance that you might be interested in debugging, is if you see these big purple bars in your performance profile. So this one is called recalculating styles. And so you just the bar being there is quite disconnected from what actually caused the browser to have to recalculate. So you don't get this big blue arrow. This is me just trying to make it possible for you to see it, because it's here. But it's very thin. But what it will do is it will draw an arrow back to the code, which has changed the DOM in such a way or made a request for like a container height, that is then forced the browser to have to redraw all the layouts.

So as an example, where we had this issue in our grid, so new rows were added to the viewport while we were changing the sort, we had some animations. So rows were being animated out. And now to do that in a nice way, we were adding rows, destroying rows, and then the animation would query the container height so that it could animate these rows just off the screen. Because you don't want them flying out too fast. You want a kind of consistent speed with which they are, I guess, animated out. But the problem is we were then asking what the viewport height was after we had changed the DOM structure. So because we'd changed the DOM structure, the browser goes, well, I don't know what you've changed. I need to force layout so that I can give you an accurate value. So the changes in one and one were actually invalidating the height value. So when we read it in three, the browser was forced to recalculate styles. So the fix for this particular use case was that we'd add new rows. The old rows were destroyed and we set up the animation. But critically, we would use a cached value of the container height. Because it's not critical that we knew exactly to the pixel what the container height was for. So by taking this approximate value, we don't have to force the browser to re-layout everything. And we're still getting the same effect without forcing the layouts. So this is all about layout thrashing, if you want to dive into this topic more.

All right, I've got time. Oh, the time is not working.

Quick fire hints. So these are some of the things which I've learned day to day, which you might find useful.

Does anyone use NX here? Not that many. If you use NX in a, you know, monorepo type setup, you can give it this NX underscore profile, run your command, and then you can upload that to DevTools again. And that will give you a timeline of all your jobs. So if you have a complicated build chain with lots of dependent tasks, this is a nice way of visualizing that. And it can tell you, okay, this is the thing that I want to need to be able to optimize. So say here, we've got this long one here. So that's just a node task. Can we actually dive into that and profile that? And the answer is you can. So if you run the node task directly with this dash dash inspect break, and give it the task that you want to do, and then go to Chrome, colon slash slash inspect, there's a dedicated DevTools for no processes here. So this is an example of what we do here. So I'm going to start the task with this inspect breakpoint. I go to my Chrome on that URL, and I can open up the dedicated DevTools. So I'll get a breakpoint here where it's waiting for me, I can go to the performance panel, start recording. And then I've hit F8 so that the task can carry on. I'll go back to my IDE. So the task is done here. Let's go back, stop the performance profile. And then we can use the same techniques and same skills that we've learned previously to now profile this node task. And so I can dive in and see, okay, where is it in this task that I need to improve? And then once you've got some fast performance, you might want to keep validating that you don't break it. So there's benchmark test that you can do in VTest. And also I'm interested in the talk later saying, you know, can AI help performance testing? So if you're also interested in that, maybe go see that talk as well. Another thing is, it's possible to performance profile or have benchmark tests for your TypeScript types. So this is something which I did for 8igrid as well. We had a complicated recursive type so that if you tell us what shape your row data is, we can tell you all the possible field names. And some of these field names can be nested with dots so you can drill down into these deep objects. And so it's really nice to give autocompletion for all of that.

But that can be an expensive type. So I used this library, ArctypeTest and set up a test. And it tells me how many instantiations were done while doing this. So, I mean, that maybe isn't something we all need to worry about, but it's good to know that these tools exist. And also, if you're not familiar with the web.dev site, this is just a treasure trove of articles and information. So if you want to learn more about these things, go to this URL and just start reading. This is from the Chrome team, Google team, and there's a lot of good information in there. And finally, we've still got our good old friend, console.log, for when you want to try something a little bit simpler.

Thank you very much. Amy Henshaw Tell us a little bit about your process for checking for performance issues, especially in a space that is so voluminous as grids and charts. Do you do it daily? One per sprint? Only when necessary? What's your process? David Wilson So, I think this is something which, for us, I guess we've got the releases. So a regular kind of time to repeat these performance tests is when we're then releasing a new version. And this is something where the benchmark tests really come into their own. So we've got this set up for our charting library, where we've got some examples which load thousands and thousands of points into these charts, and we run these set of performance metrics so that we can then say, okay, this is what it was in one version, and this is the next version. So that's kind of like a nice timeline to then be able to...

Amy Henshaw Do you automate that, or is someone in charge of doing that every time? David Wilson For that one, someone is in charge of it. The benchmark profiling test is a very tricky thing, because there's factors in terms of, well, what CI box was it running on? Were there loads of other tasks running at the same time, which has then slowed it down, which is why it looks like there's a performance regression, but actually it wasn't. Someone else was just running a build on the same box. So you do have to take all these things into account. Amy Henshaw Like a lab, kind of? David Wilson Yes. You need to be able to control. Amy Henshaw Is there any other sort of automated testing that you do for stuff like performance, or is it just the benchmarks? David Wilson It's just the benchmarks. But then also, it's that kind of why every so often come back and do it probably a bit more manually. But then I think this is something we can all, I guess, work on, improve on, is that once you've made these improvements, trying to have those tests in place is a good thing. But it's not a straightforward thing like testing or unit testing. Amy Henshaw Well, we wouldn't be here if it were easy, right? Let's talk a little about those types of scenarios where you might get not quite right data. What are common mistakes people make when profiling? Or what are the common misconceptions about what a correct profile is? David Wilson So I guess you want to try and profile as close to the user's experience as possible. So for React, that's definitely not profiling against dev mode, or with strict mode turned on, because that double rendering, there's lots of other checks going on, and that is slowing down the application. So you might think you're doing worse than it was. So that's where React has that profiling option. So it depends what build tool you're using about how you enable that. But there are instructions on the React website for how to do that. Amy Henshaw That is a very good tip. Dev mode is tricky that way. The performance temp, like we said, has a lot of information. It has a lot of hidden corners. It has a lot of stuff that evolves and is improved by the Chrome team or whoever. You mentioned web.dev.

Do you have any other resources that you have to sort of learn more about it, or someone that maybe is not as good at it could get started? David Wilson So I think there's nothing quite beats diving in and just looking and trying to tie things up with what you're doing, seeing how it interacts, and start recognizing maybe what the names are. And this is where there's a contradiction, I guess. Because if you're profiling against a minified file, you can't see what's going on. So then you do need to run against the unminified code so that you get a little bit more of that kind of information where you can see, well, actually, it's definitely... Amy Henshaw Get a land. David Wilson Yeah. But in terms of resources, I think the Chrome team are doing a lot of work on this performance panel at the moment. So the release notes that pop up when you update your Chrome, and then you go to the DevTools to the first time, it tells you what's new. There's often a video there or a blog post. And so that's a really good way of learning about these new things. So like for all this, the new web vital metrics, there's a post explaining what the motivation behind that. And it's that, as I was saying, there's lots of information here which developers aren't able to access easily. So putting it in front of us, there, gives us these metrics which we can work against.