Chrome DevTools: State of the Union 2024 - Debugging React & Beyond

Hi folks, do you know what it's like when you're working on a React component and you think to yourself, you know, maybe this could be just a little bit better. I had that experience with my cover slide last night, didn't get a whole lot of sleep, but I did decide to play around with this just a little bit and I wanted to show you what I spent my night on. Hopefully it'll be worth it. It's just a brief little thing.

So let's go ahead and refresh this and hit play. If debugging is the process of removing bugs, does that mean programming is the process of putting them in? What's new in React and Chrome DevTools? I believe that good tools are the silent partners in every success story. I'd like to say that the quality of your outcomes very often depends on the quality of tools that you use. And so it's really important to make sure that you're choosing ones that set you up for success.

Now, as web developers, we often deal with complexity on a daily basis. And over in Chrome DevTools, we've been wondering if AI can help transform some of that complexity that we run into with debugging into some clarity by mindfully adding it where we think it can add value. So how about helping you debug and tweak styles? So we just added a new AI Assistant panel to DevTools to help you with UI. And you're able to chat with our AI model Gemini. So here, what we're doing is we're selecting an element. I'm able to use the AI Assistance panel. And I can ask AI to do things like help me with tweaking styles. In this case, I'm asking it to add a gradient to the sound ethics text. And it's going to go. It's trying to figure out the exact best way to approach this. It'll give me some insight into how I might do it. So it's going to give me a solution. And it'll also give me this little button, continue, lets me apply it. Now it's almost got it right, but it looks like some text clipping is needed here. So let's just tell it that maybe we need to tweak that up. And in just a sec, we hit continue, and boom. So it helps us out with that. We're also able to continue iterating on this, doing things like asking it to help make it pop or make it glow a little bit more. And this just changes how we approach things like tweaking styles and getting insight into our pages. What about explaining errors? Now we have a sample React Stocks app here. It's using some data. And when I click on buttons to view more details about a stock, I get an error in the console.

I'm not entirely sure why, but I'm able to use AI in the console as well to get a summary of both the problem based on all the context that's available to us in DevTools from the error from the source. We're able to suggest a few different ways to solve this problem. So you have to make some fixes to the handle stock details logic here. But thankfully, with the new Gemini support in DevTools, I can explain the error and get some fixes I can apply right away.

What comes next? Well, just this week, after AI assistance, we have tried to make this even more powerful. Now you can ask questions about your source files and the sources panel, network requests and network, or even ask it about your flame graphs in the performance panel. So we hope that you'll be able to get instant answers and this will help you on your debugging journey. It looks a little bit like this. Basically we include that file or that resource as part of the context and you can start interacting with it alongside other contexts we can include.

Next up, extensibility. So extensibility is a really important principle for us in Chrome. And there are lots of great Chrome DevTools extensions out there that really help amplify what is possible. And that includes the React DevTools. So a few tips and updates here. First tip, I really love using the highlight updates feature in React DevTools. So we've got a React app here. It's a movies application. I'm going to go over to the components panel. I've got React DevTools installed. And I just go to settings and I can check highlight updates when components render. And this just helps me identify unnecessary re-renders so that I can optimize my application's performance a little bit more.

You'll see these just glowing as we're interacting with the UI. Next up, React DevTools now supports server components as of v6 and above. I heard one person excited about it. A few more. All right. So server components are now visible in the DevTools components tree. They're displayed with a special server badge to distinguish them from client components. And this helps you just identify which parts of your app are running on the client or the server. I've been finding it really helpful.

If you're a Next.js developer, you're also able to now get server logging. So console log works the same way as it would in the browser, but with a server tag. And that just means that you're able to view server-side logs directly inside the browser console so you can debug those server component experiences just a little bit more.

Another tip for you, using React DevTools, you're also able to toggle your suspense fallbacks. I tend to find this useful if I want to update and refine the styles of my loading screens without having to just repeatedly trigger the loading state in my app. So here you can see this in action. We just click the single button and we're able to just see that loading screen experience. I can then inspect it using elements and tweak it, and that can just help improve your iteration process a little bit more.

I just mentioned React server components. React Compiler support is also now available in the React DevTools. So this includes memo badging for components that are optimized by React Compiler. And I just love these badges because although they look like they're a small thing, it can really help you quickly identify what components have been optimized, potentially helping you focus on the places that haven't been. If you're somebody that enjoys writing custom hooks, the DevTools of the React DevTools, of course, also help you inspect your current state and props of hooks in your components that can just be useful for debugging complex state management situations. And another quick tip, you are able to use useDebugValue. It's a hook to display custom debugging information, and it's especially useful if you're somebody that does like creating and using custom hooks in their apps. I know a lot of people do like doing that.

Next up I want to talk about a few ways that you can go about experimenting freely without necessarily touching the original code in your apps. So everybody kind of remembers the first time that you sort of used browser DevTools, whether it's Chrome DevTools or something else, to just inspect a page and change some text. I have a colleague, Chris Bensell, who used to work on Chrome. He introduced the DevTools to his five-year-old when they were trying to order food from Chipotle. And it kind of went as well as you could expect.

This is great, but it doesn't persist. I want to talk about local overrides, which are kind of an even more powerful version of this. Before we do that, let's talk about color contrast real quick. I love the Stripe book site. It's one of my favorite experiences out there. I'm a big reader. But I do notice that as I scroll through here, color contrast isn't as good as it could be. We see some oranges on top of blues. We see some oranges on top of greens. It's not very easy to read this.

Now inside of DevTools, we actually have functionality to help you automatically fix color contrast issues so that they're AA or AAA compatible. We just click that button there, and it made the text darker and a little bit more accessibility friendly. You didn't have to think through it a whole lot yourself, but you can also tweak these values if you want. Now if I were to reload this page, these changes would, of course, be gone because I'm not pushing to production. I don't have magic access to Stripe. But DevTools does give you a few superpowers to help out here. Now if we wanted to persist these edits, we could use local overrides. Basically what they allow us to do is make a tweak and allow DevTools to save those changes to a file location of your choosing so that anytime you then go back to that domain or that page, it's going to load that version instead.

So basically what I want to do here is apply those same color contrast fixes. And what I'm going to do is inside of here, I'm going to go to sources, I'm going to enable local overrides, and what this will allow me to do is then start making changes. So I want to find out where I need to make these changes. It looks like it's going to be in this CSS file. I'm going to take that fixed value for my color contrast. I'm going to save it. And what we want is when we reload this page, we want it to show us white text instead of orange.

And there we go. This is persisted. So you're able to effectively edit live pages and save them locally, which opens up all kinds of useful use cases.

Now we've been building on top of the overrides feature over the last few years with a few value adds we think you might find useful. The first one is that you can now override the content of XHR and fetch requests in addition to their response bodies. With those kinds of overrides, you can mock things like API responses to debug your page, even if your back end and your API aren't ready yet or you don't have access to it.

We support overrides for a number of different request types, including images, fonts, XHR, scripts. And we gray out overrided content options if you're inspecting this in different places in DevTools. So that's overriding the content of XHR and fetch requests. We also now allow you to override HTTP response headers. So if you've ever wanted to locally experiment with response headers, DevTools can now override those headers, including cores. We also let you set your own custom headers. So if you want to play around with this locally, you now have a lot more power and ability to do so.

If you happen to be browsing some docs and they talk about, you know, specific header values, you can paste entire strings to override them. You don't have to necessarily go parsing and breaking up the text yourself. We'll just do the hard work of interpreting them for you.

Now since we're talking about the network panel, quick tips here. We did add a checkbox to help you focus on what matters most to you. We want to hide Chrome extension requests. Many of us use Chrome extensions, but we don't necessarily want to see like, hey, they're happening to be loading in their own React code or their own library code. So if you just check this hide extension URLs box, what it will do is just let you see your own requests. And I tend to use this feature a lot myself these days.

We've also now added to the network panel the ability to get human readable HTTP status codes. So you don't have to necessarily memorize all of these yourself anymore. We will show human readable text next to them. So for 204 for example, we will say no content. And it just helps you avoid having to look up docs yourself.

Another random tip here. So if you're somebody that works with input a lot, you might know that if you switch focus from a page to dev tools, sometimes overlay elements will hide if they're triggered by focus. And it makes it easier for you to emulate a focus page. So you can just hit that and it will force that state, meaning that you can go and just start tweaking the styles of any custom input components you've been working on without having to deal with a lot of forcing the state yourself in your components. This has been really helpful for YouTube. It's also been helpful for many teams that happen to be using React and other kinds of libraries.

Next up, I'd love to talk a little about performance. So I say that lab data shows you what's possible and what's actionable. Real world data often shows you what's real. We've been trying to make that more actionable over the last couple of years as well. And DevTools tries to now help you optimize for both of those things. So let's zoom out and talk about what's new in performance tooling. And I'll also talk a little bit about React performance.

Chrome DevTools now lets you monitor your local and real user performance, your Core Web Vitals, via the performance panel. This used to be a completely blank panel, but we now give you lots of rich insights in there by default. If you open up the panel, you immediately see how your local experience performs.

There's no recording that's necessary there. And as we've learned through efforts like the Web Vitals extension, having access to even local Core Web Vitals performance can be a real game changer for people. So we've taken everything that we've learned from some of those efforts over the years and really tried to make sure the performance panel has all of this by default.

We've also recently been adding recommendations in our live metrics as part of this work. So our live metrics can provide metric-specific recommendations to help you configure your development environment or steer you in a direction that maybe you didn't know you should be focused on. Like, for example, your real users may have slower interactions because they have slower CPUs, or they may have an abundance of smaller screens which can change how you think about a metric like largest contentful paint.

For your lab data, we also now enable you to get insights right inside the performance panel. So you can get actionable insights inside of our new insights subtab. What that allows you to do is get consolidated insights from Lighthouse as well as our previous performance insights panel. It's all now in just one place, and it tries to provide you guided analysis and actionable insights into performance issues that might be slowing down your experience.

Another ask folks have had over time is that often performance is not just a one-person thing but it is something that you tackle as a team or something that you want to often share your performance traces with other people around. And so one of the things we've been working on recently is trace annotation. This is really powerful. What it basically gives you is a new annotations tab that streamlines the process of creating notes for your trace explorations. It makes it easier to do things like collaborate. You're able to do things like label and connect events with arrows. You're able to highlight time ranges right on the trace itself. And then you can save, you can share this with other people. If you're a performance expert or performance-minded, you might know that previously people had to screenshot and kind of do all these annotations themselves. There are also people who used to actually like print this out and just do annotations. So hopefully this will help if you care about performance.

Another quick tip, I know that many folks take a look at things like Webpack Bundle Analyzer to get insights into what's happening in their bundles. DevTools actually has a Bundle Analyzer built in. If you use Lighthouse, we actually have a little Lighthouse tree map feature that provides a graphical representation of your JavaScript bundles.

So hopefully this will help if you care about performance.

Another quick tip, I know that many folks take a look at things like Webpack Bundle Analyzer to get insights into what's happening in their bundles. DevTools actually has a Bundle Analyzer built in. If you use Lighthouse, we actually have a little Lighthouse tree map feature that provides a graphical representation of your JavaScript bundles.

So we're going to just use this with BlueSky. And what we're going to do is we've taken a Lighthouse trace. I'm just going to click on View Tree Map. This will give us that graphical representation. So this is everything that is in the bundle or bundles, rather, that get sent down to the user. We're able to inspect individual chunks. We're able to do things like take a look at the unused bytes across your entire graph. You can see that there are certain dependencies here. Things like ProseMirror that maybe aren't entirely being used at all on initial load and could potentially be deferred. And you can use this view just to give you a little bit more insight into how you can optimize your pages.

I'm going to talk about Core Web Vitals for just a moment, but I wanted to share this. This is probably my favorite example of a layout shift from Lee Robinson. This happens to me a lot. Basically, you try to go clicking on a button and oh. Doesn't happen to me with missiles, just to be clear, but like buying stuff.

Now I'm not going to talk so much about layout shift, but I do want to talk to you very quickly about input responsiveness. Simply stated, input responsiveness means how quickly web pages are able to respond to user input. So when a user interacts and then they're able to see results of that interaction. I'll give you an example here. It could be like you're opening a menu of a site. How long does it take before it appears and the user is able to do anything at all? Or if I click a button to add an item to my cart on a shopping site, how long after I interact am I actually able to see that my item was added? It's a nuanced metric. So INP, interaction to next pane, is really the latest interaction metric available to the web. Interactions can be things like clicks, a key up, or a pointer up. It's broken up into three phases that can help you target optimization efforts.

I wanted to talk about this really good case study I saw. So Veo is a large React app that have been optimizing for their interaction latency. They were actually able to make their app 69% faster where interactions are concerned. I wanted to very quickly go through some of the things that they did.

Their first big win really came from upgrading to more recent versions of React. The key benefit of React 18 was really concurrent rendering. So things like high priority tasks, such as user input, could interrupt rendering. That single change alone was able to give them a 46% improvement to their INP on desktop and similarly sized improvements on mobile. Insight there is that sometimes even framework level changes can have a lot of impact. So do consider that when you're considering upgrading or not.

Analytics and tracking events were also an area that were causing them to be slow. They were creating long tasks that were really blocking the main thread. Instead of completely removing any of those, because often businesses can't just remove them, they implemented a simpler solution. They opted to yield to the main thread between different operations. You can do this using things like scheduler API. That broke up their long tasks and it improved INP by another 19%. The key learning there is that sometimes even basic features, using a new API that's available in the web platform, can really help solve complex performance problems.

The final piece was addressing React rendering issues. They identified a few different key problems. Things like breaking down complex custom hooks. We were talking about hooks earlier. Breaking down some of those complex hooks into simpler ones. Replacing some of the React router APIs with alternatives, like window.location where they could. And then improving things like Redux selector memoization. That gave them another 45% improvement in INP. So overall that's what led to that 69%. This is a really great case study. Very, very detailed. If you're interested in performance, do check it out. Now I like to say that a seamless user experience often comes from sweating the small stuff.

And DevTools can help you often get these details right. I'd love to walk you through some of my favorite features for debugging UI. But before that I just wanted to acknowledge that I really love it whenever I see developers trying to push the web forward. And I've seen some fun examples of where they've been getting, let's say, creative.

So for example, unsubscribing to newsletters is usually a little bit too easy. I know that I want nothing more than for this to be disrupted. Thankfully DevTools can come to the rescue here. So we're able to go and inspect. This is great. We're able to inspect that button. $0 will give you a reference to the last element. So we're just going to $0 there. We're going to click and... Oh. We're so close. Let's try another one.

So in some cases it's way too easy for users to delete their accounts. You want them to stick around a little while longer, right? So what if we made them reconsider? So let's try this. We can get this right. It's only three options here. Let's try delete. Oh. All right. Let's use DevTools. So elements panel. Let's just use the search here to look for a button. And we can do something like force this, I'm sure. So $0 once again. Click it and... All right.

OK. We were able to remove our account. Wonderful. One last example. Volume control. Surely this can't be disrupted too much. Who needs boundaries?

So there are some things that even DevTools can't help you with. For everything else, we do try our best. So I love how interactive and delightful the web has been getting over the years. We've seen developers continue to invest in things like web animations. And to complement this work, they need good animation tooling. So DevTools has an animation inspector. It lets you do things like replay or slow down animations, modify timing, delays, play with durations. And it's really powerful for tweaking your animations in real time. You can find this under more tools.

So the animations panel now does one additional thing. This is another site that I've been playing around with recently called Wild Things. One of the reasons I picked this is I can scroll through and you'll see that it's got some cool animations. So I'm just scrolling and you see these things just being thrown across the screen. Now what the animations panel does now is that animations that are already in progress, we already capture those. So you don't have to refresh the page, you don't need to re-record anything. Those are already waiting for you. And you can replay them, you can tweak them, you can edit key frames. We're just trying to make this panel a little bit more powerful for you.

Now this is an app that I built using View Transitions and Next.js. It uses the Next View Transitions work from Vercel. So I have some hover effects in here that I would love to show off. Let me just see if this is going to play properly. I have some hover effects that transition between pages here. Now in the animation inspector, what I'm able to do is actually slow these down.

I'm able to do things like make sure that these are replaying correctly and it's just generally useful for view transition debugging as well. So if you happen to be using view transitions in Next, you can use this panel too.

Finally, let's talk about 3D very quickly. Although most developers conceptually understand how nested DOM elements affect the way that the browser layers CSS, the fact remains that the browser displays a 2D plane. However, DevTools has a feature that allows you to view DOM layering in 3D. This is the lesser known layers panel. So you go to more tools or our toolbar and go to layers. So in this case, this is a parallax experience and I'm kind of curious how the layers are structured and how they interact as I scroll. So here's a 3D view. You're able to see like what is sticky, what is not, what moves. And if you're designing interactions, this can just be really powerful for helping you tweak and refine those to just get the right experience in place.

Final thing from me, I wanted to cover a few fun tips that can help with your logging workflow. Now styled console logs have been around forever. They help you spice up your debug messages. You can use format specifiers to kind of format the console messages. Here's one that I made a little bit earlier. You can go as crazy as you want with these. You can use whatever typography that you want. Now I'd like to show you one small trick, because we can use CSS to style things in the console message. We can also do fun things like set a background image in here as well. So you can log memes if you want. You can log a bunch of different kinds of things. You can also animate SVG in the console. And I wanted to show you this very quickly.

So I have a question for you to end this talk. What is the best Christmas movie? I'm hearing Elf. I'm hearing Elf. So we're going to answer this question using a new feature I've added just for this talk called console.Christmas. So we're going to use console.Christmas. And let's see what console.Christmas has to say. There was one person in the audience that got this right. I animated this myself a couple of years ago using SVG while I was watching Die Hard. It was built using SVG Gator. Reminded me a lot of the Flash days. But you're able to use inline SVG and CSS to animate SVG in the DevTools. It's really, really fun. This is a simplified version. It looks very roughly like this. But you can have all kinds of fun with logging. Please do. So I hope that you found this talk a little bit helpful. Let's debug the web forward. I've been Addy Osmani. Thank you.

How do you prevent users or devs from forgetting they have local override toggles? Seems like something that could be easily forgotten and cause confusion. That's a great question. We added additional badging to different places in DevTools. I believe we use a purple color. So you're able to tell exactly what files have been overwritten and spot those and differentiate them from everything else. Nice.

What version of Chrome are these features available in? The vast majority of stuff I talked about today is available in Chrome Stable. The AI features are Chrome Canary for the most part. Sick.

Sick. All right. Let's keep moving. How is your code shared from DevTools when you hit Ask AI? They are concerned with app security proprietary code. Great question. So every time that you use this feature, we actually have a privacy dialog that asks you to consent to share the current session. So it doesn't persist across absolutely everything that you do. Within each session, we will ask you again if you want us to share that context. And we generally only share the minimum amount of code that's necessary to be able to help refine the answers that we can give you. So we tried to build this with privacy in mind. Awesome.

How shareable are overrides for things like XHR requests a la Postman? How could we share overrides across users? That's a great question. I'd actually... I'll throw the question back. I would love to know how folks would like us to make that a little bit easier. Very often these efforts start with just better documenting what people are doing. So if there are specific use cases you have in mind, throw them into a GitHub repo, create a new Chromium issue. We'd be happy to chat with folks about that. Amazing.

Do you ever remove features from DevTools? We do. We absolutely do. So sometimes there are features that look amazing on a screen, but we're at a conference we realize, you know, either the assumptions we made at the time are no longer true, or the UX we thought we had maybe wasn't the right one. To give you an example of a feature, we used to have a promises inspector, specifically for helping you visualize promises and just use UI to tweak what happens throughout your chain. And we realized that it was actually the wrong thing. At the time we ended up removing it. We're regularly revisiting these decisions, and so if there's ever anything that folks feel like, hey, you guys look like you're going to remove it, the layers panel is actually a great example. The community pushed very heavily back on us trying to remove the layers panel. We were like, this looks like it's very expert only, or enough people using it.

The community pushed very heavily back on us trying to remove the layers panel. We were like, this looks like it's very expert only, or enough people using it. So always feel free to say if you're using stuff. We do try to listen. Yeah. I'm stoked to hear that, because I did hear the layers panel was going away. So glad to see that's not the case.

Last one. Chrome can be quite memory intensive. How expensive are these new features when using? So two answers. We have been investing very heavily. I know that Chrome is very well known for all the memes around memory consumption, of course. We have been putting a lot of work over the years into trying to mitigate that as much as possible. I'd actually say we're in a decent place now for the most part. For these features specifically, it's going to depend on the kinds of experiences that you're building. So if you're building something that is heavily using WebGL, very complex web animations, lots and lots of different layers, obviously that's going to consume more memory. And the tooling is also going to be consuming more memory as a result. So I tend to recommend that folks just keep an eye on their memory consumption. If you spot somewhere where it looks like DevTools is the cause, we're happy to take a look at it. Sick. Amazing. Thank you so much, Addy. Let's give it up for Addy Osmani one more time.