Debugging Performance With AI

I work for AG Grid but I'm not going to be talking about the grid today. I'm going to be talking about a rabbit hole that I disappeared down for several months. Debugging rendering performance is really hard, and I wanted to try and figure out how to get AI to do that for me. I've been trying to think about what to cover because it's just a seven-minute talk here, and what I think I've got time for. I'm not going to be able to walk you through the whole process, but I want to inspire you with some things that you might not have realized were possible or ways that you can get AI to tackle this really hard problem for you.

So first of all, why rendering performance is really hard to debug. It's basically hard to debug because the information we get from the tools is not very good. We're going to record a performance profile in Chrome here. You click that little button, you interact with your application, and you stop it, and you'll get this thing called a performance flame graph. The thing that I want to show you in this, there's a little video up the top that shows you your interaction. You can pick a bit you're interested in, zoom in on it, and what I want to show you is how good the information is you're getting for the JavaScript section. It shows you every single function in your application, exactly how long it spans, and this is why frameworks are so fast.

When you're trying to get your rendering performance fast, you don't get any of that detailed information. It just tells you how long you spent in each section of the application. Historically, if we want to make our apps render fast, we basically had to do science on our apps. You need to learn as much as you can about the rendering process and CSS. Then you come up with hypotheses, reasons why you think your app might be slow, and you test those by editing your app, recording another performance profile, and looking at the differences. It's basically doing science, painstaking, repetitive, time-consuming, and can be really boring. And if there's one thing AI is good at, it's automating boring stuff.

So there is a Chrome developer tools MCP, which if you install, it can do anything that you can do in that UI. It can click through your page, record performance traces and analyze them. And the most important thing that AI can do is to flatten the learning curve. So it used to be that you needed to be an expert to get results. Now you can basically start doing this and get AI to take you through the process and learn as you go. So if there's only two things that you take away from this, I want it to be these two things.

First of all, in order for all of this to work, you have to install the Chrome developer tools MCP. Without that, Claude doesn't know what it doesn't know. It won't recommend that you do this. It'll just be ignorant. So you need to do that yourself. And then my big suggestion is ask the AI what your options are. Don't say fix this performance problem. Don't even say why is it slow. Say explain to me my options. And that's how you become an expert. That's how you learn and build up a toolbox of techniques.

So I'm going to show you a few of these techniques now. Again, we're just going to be going through them quite quickly. But the idea is to show you what's possible. And just remember, anything in here, you can get AI to explain to you and then do it next week. So the first is a regression by section. So a regression is a special case of a performance problem where you have a version of your application that you know is good and a version that you know is bad. And you can automatically find out exactly. Like, you can ask Claude, find the commit that introduced this issue and it will do a thing called a git by section for you. So if you know 50 commits ago, your app was good.

Now it has this problem. You can say, find the commit that introduced it, and it will check out a commit in the middle and test it. As in it will check out that source code, build your application, open it, start the dev server, open it in Chrome, navigate to the page, do the action that you told it was slow, record the performance profile, find out whether or not it's slow, really time-consuming stuff. And let's say, OK, we figured out commit 25 was good. So it will repeat the process again, and it will go through systematically through your whole commit history to find out the exact commit. And I've gone away from a lunch break where I had this doing it for an hour, and I came back, and it's like, hey, this commit, that's your problem.

Another technique I use all the time is a standalone reproduction. So here's the page I showed you earlier that recorded a performance trace from. If I was interested in the resized performance of that grid, there's a whole bunch of other stuff up there that's just noise that's going to pollute the trace. So you can tell Claude, hey, here's a page I'm interested in. Just make a standalone version of that that just has the grid. And I asked it to do that, and it built this. Now if we're interested in the resized performance, you can make this little button here where you have a little button that just resizes the grid five times. If you record a performance trace while you're doing that, you'll get really clean data.

There's a synthetic stress test, another technique I use all the time. So the basic idea here is if you think something might be a little problem, create a crazy example that makes it a big problem so you can see it. We received reports that the more elements there were on a page, the longer our styles took to load. We couldn't see it happening normally. So I just said, Claude, build me a page that has 100,000 divs on it. And there's a little button here to show and hide the divs and a button to create a grid, which is going to add our styles to the page. Using this, we were able to reproduce the issue because it's a crazy example with way more divs than you'd normally have.