Supercharge Your Debugging With the New Features in Chrome Devtools

Hello, everyone. I'm Eva. And I'm Bari. Just in case it wasn't clear who's whom. Thank you so much for coming back after the coffee break. I know it's a bit late in the day, but I hope you still have a little bit of energy left for all the DevTools magic we're going to show you today with Bari. Let's get started.

We've seen a lot of interesting talks today. One of the universal conclusions we can draw is that web development is becoming increasingly complex, especially with the rise of AI tools and processes. The developer tooling landscape is developing quickly, and Chrome DevTools are no different. Developers tend to stick to what they know, even missing out on productivity gains. A conference like this is a great opportunity for a fresh perspective on new features.

Today, we'll discuss various improvements in DevTools, particularly in performance debugging and AI insights. The performance panel improvements aim to make it easier to find and fix issues without overwhelming new users. Changes have been made to tackle the intimidation issue while still catering to power users. The focus is on a gentler introduction to performance analysis, ensuring a smoother experience for all users.

Even when they're there in the UI, straight in front of our eyes, our trained blindness teaches us how to simply go around them. And a conference like this one is a great opportunity for us all to take a step back, take a fresh perspective, and soak in all the newness that was introduced.

In this talk, we will try to inspire you to try out all the new features that were added to Chrome DevTools recently and to get a productivity bust as a result. Today, we're going to be talking to you a little bit about a lot of the various improvements we've been making to DevTools, primarily in the performance debugging space and also some exciting AI insights later on. Because let's be honest, what's a conference talk today if it didn't involve AI?

So let's start with some updates that are near and dear to my own heart, the performance panel improvements. Over the last couple of years, we've completely reimagined the performance panel to make it much easier to find and fix performance issues. We've tackled the problem with a number of changes in the panel that we believe solves that intimidation issue, and we're going to talk through them today. It all starts when you first open the panel.

A performance trace includes an awful lot of data, and it's really great for being able to dig dive into that issue, but it's really overwhelming, particularly for new users, and it takes a long time to really understand how to use it properly. Well, we wanted to fix that, but at the same time not ruin the experience for all those hardcore developers, power users that do depend on this complexity. So we've tackled the problem with a number of changes in the panel that we believe solves that intimidation issue, and we're going to talk through them today. And it all starts when you first open the panel.

This is what you used to see, a big old empty space with not much information on it at all, and just telling you to do a full performance trace. We wanted a gentler introduction to performance analysis, something that didn't require taking a trace immediately, even before you know what you're looking at. We're calling it the live metrics screen, and it's the first improvement we're going to talk about today. Now, when you open the performance panel, this is what you see. It will immediately show you some details about the performance of the page that you're visiting. And it really is live. As you click, type, and interact with the page, and scroll down, and even click on other pages, the panel is continually updating with your performance metrics. This helps you identify exactly what performance bottlenecks you have, whether it's on page load or through particular interactions.

The live metrics screen is centered around the three core web vitals. These are three metrics that Google introduced five years ago to really measure, give a quick summary of how your page is performing. We have LCP, or large contentful paint, which is the loading metric, and shows how long it took from your click until the largest bit of content was shown on the page. CLS, or cumulative layout shift, says how much the content moved and jumped around, which is really quite annoying. Whenever you load a page, and you start reading, and an ad pops in, and you lose your place, and you're like, what's going on? And finally, interaction to next paint, which says how responsive your website is to interactions. When you click on something, do you immediately get some sort of visual feedback, or does it take a while and you're not even sure if the click's been registered?

It's all green. Well, Barry, it's all green and nice, because maybe you're developing it on your fancy laptop and on a high-speed internet. Are you sure that our users are experiencing the same on their real devices? We've heard today from Alex how it looks in real life, right? We know that there is a disconnect between developers, what they see on their powerful laptops during the development process, and what users see on their devices.

Actually, a huge part of the Core Web Vitals initiative was to convince the site owners of the importance of using field data, which is measured by real users on their real devices. Now, we've made it really, really easy to see this real user data directly in DevTools in the performance panel. You can use the button on the top right to pull that field data on. Data comes from Crux, the Chrome User Experience Report. It's a source of anonymous real user experiences collected by Chrome.

Once you set it up in that field, the data is pulled from Crux. And DevTools will automatically display the field metrics next to your local metrics for the URL you're currently viewing. If you develop a localhost and there is no real URL to speak of, you can map your localhost to your production URL to still get that matching numbers next to each other. This allows us to compare the performance metrics we're seeing to what our real users are seeing. Oh, and as you can see, maybe loading's a little bit slower for the real users who aren't on fancy high-end laptops.

Oh, and as you can see, maybe loading's a little bit slower for the real users who aren't on fancy high-end laptops. And that's the desktop data. But when we switch to mobile, we automatically load the mobile data and you can see it's even worse. So at this point, we know we've got two issues to solve, our LCP and our INP. Fortunately, you can configure your DevTools to act more like what to better emulate what your users are actually seeing. Use the settings panel on the right.

If we zoom in, you can see for a start, the Crux data tells you exactly the breakdown of your website and your website visitors. Here, we see most of our visitors are on mobile. And that's pretty normal these days. As Alex said earlier, we're in a mobile-first world. It also tells us that 75% of our users are on slow 3G, slow 4G throttling. So rather than having to guess what to do, you can use your real data to actually set that. So let's set that.

And we're also going to set some CPU throttling here. Now, it recommends 4X slowdown, but to be honest, that's just a default. It doesn't explain exactly why you're doing that. Now, this data that we're going to set here doesn't come from Crux because we don't have that data in there. But we do have this nice calibrate option that we've added at the bottom. And when you click on that, it will give you this option and actually calculate some calibrations for your laptop. So you simply run the calibration. It'll run some hardcore processing, see how fast your computer is, and then suggest some custom multipliers for you to use.

Here, we say, we see a 3X slowdown is recommended for my laptop for a mid-tier device. So we choose that. And then when we reload the page, we see that our local metrics are more closely matching the field metrics that we saw our users getting. So at this point, we're now in a good place to actually debug this performance because we should be able to replicate exactly what they're seeing.

Performance trace can actually give you much more information than the live metric screen alone to really help you understand the performance issues. It might take a longer while to record though, so it is best to use the live metrics that I just showed you to do some quick checks or experimentation and only record the full trace when you want to dig deeper into some specific problem. You can record the trace using the buttons on the bottom right, or there are also available two smaller shortcuts in top left for your convenience.

You can either record the specific user interaction like a series of clicks or a scroll using the record button or trace a full page load using record and reload. Let's go for record and reload for now. After a few seconds, you'll be presented with this. And I say this detailed kind of scary view. Now, we've made an awful lot of improvements to try and make this view more useful and make it easier to navigate around the... Ooh, sorry. It's not... To make it easier to navigate around this trace view. Some of these are shown in the video.

We're not going to have time to cover all of these today, but check out the blog posts at the bottom and some of the other blog posts in this series get more details on that. And the reason we're not going to have time is I want to talk about one particular improvement we've made with the Performance Insights panel. Many of you may be familiar with Lighthouse which presents a summary of your page experience, including the well-known performance score. As well as those scores, Lighthouse has a wealth of data in its performance audits. But Lighthouse can't show you the deep performance data that the trace view shows. And flicking back and forth between the Lighthouse panel and the Performance panel is a bit annoying, to be honest.

What if we could bring those two things together? And that's exactly what the Lighthouse sidebar... Sorry, the Insights sidebar does. You get a number of insights here in Lighthouse style... Sorry, you get a number of Lighthouse style insights in this sidebar. And they're listed in rough order of what we think is a priority for you to look at here. We didn't just transfer these insights from Lighthouse. We looked at them, we retired some old ones, we merged some together, we tried to make them more useful. So we did a complete audit of Lighthouse, if you will, and came up with better insights. And we're now bringing those insights back to Lighthouse.

Because we want the same experience whether you're looking at Lighthouse support or whether you're looking at the trace view, rather than this disjointed experience that you used to have. But the really powerful thing about the insights in the Performance panel is that the insights in the trace view are fully interactive. Clicking on any of the insights automatically zooms the trace to the appropriate time span. It filters out the irrelevant data and highlights the important data. We even overlay additional data, such as LCP subparts, to really help you understand the trace view. With Performance Insights, you can quickly see the render blocking requests, layout shifts, network dependency trees.

You can use insights to zoom into exactly where large DOM is causing your page performance issues or highlight third parties or force reflow issues. But we aren't done yet. All that information is fantastic. But what if you don't know what it actually means? We want to make the insights sidebar as user-friendly as possible, independently of your expertise level. So for Performance experts, but also for newbies alike. So we added one more friendly feature to it, the Ask AI button. When you click on the Ask AI button, you're taken directly to the AI assistance panel. And it passes to the AI for the context, the details of the insight you're looking at, and the part of the trace. You can have a conversation with Gemini here, based on your performance page data. You can even suggest some example questions, but you're free to type whatever questions you want. If needed, it also has the ability to probe back to the trace for extra information as your conversation progresses. In the end, you should get an exhaustive explanation together with suggested actions that you can try out to fix the issue.

Speaking of AI assistance, you can find it in other places too, in Chrome For example, here I'm looking at one specific insight, which is called Legacy JavaScript. And here I can see the name of the script that is causing some trouble in my performance. But it's not instantly clear for me what script that is or what does it do. By clicking on the script name, I'm taken straight to the sources panel. In the sources panel, I can see the source code of that script, but it still looks fairly cryptic to me. Fortunately, I can use the little SKI icon next to the script to ask a question directly about the script. For example, what does it do or what it is responsible for? Here I learned that it is the core part of my Next.js page setup and it is responsible for routing and rendering of my Next.js app. Very similarly, in the same insight, I can click instead of the name, I can click on the icon, network icon next to the script's name. This time, I'm taken to the network panel. And here again, in a very similar way, I can use the same AI icon to invoke the AI assistance panel. And now, it's my network request that is being passed in as context. So I can ask questions regarding headers, caching, payload, security, or get ideas of possible network-related improvements. You can use the predefined prompt as starting point or craft your own queries to drive your investigation further. As you can see, this AI assistance panel is fairly versatile and you can do a lot with it.

Now, with the new AI capabilities built into DevTools, you can even fix code for you straight in DevTools. Let's have a look at that. When you inspect element in the elements panel, the little AI icon lets you interact with Gemini and ask for advice regarding this element's layout or styling. With prompts like, can you center this element on the page for me? Or why is this text overflowing its container? It can not only give you an actionable piece of advice but even produce a patch of code that would fix the issue.

If you are more visually inclined and prefer to use images instead of text, now, thanks to the multimodal input, you can do it too. Here's an example. This is a website. And on this website, we have a few video thumbnails listed. And we immediately notice that one of those thumbnails stands out and it's not cropped like the others. When with the camera icon next to the prompt, I can easily grab a snapshot of that part of the page to help the element stand which thumbnails it should fix for me. Gemini analyzes the page and proposes a patch for me.

With just a few clicks, we get the issue resolved and now all the thumbnails are nicely trimmed and aligned. Gemini proposed a code patch that we've seen briefly on the previous screen. As well as seeing the changes in the AI conversation flow, you can see the code it alters on the page highlighted in the changes panel. The change AI made on this page is temporary, though, a bit similar as if you were editing styles by hand in the Elements panel.

Let's say the website I was just developing a moment ago with the help of AI assistants is actually a local project and it runs on my local host. In my case, the folder containing my project is called DevTools Cinema. Now, we can take the AI assistance to the next level. Let's say I'm happy with the patch AI suggested earlier and I would like to save it to my local code base. All the magic happens in the unsafe changes section at the end of the AI conversation.

Let's say I'm happy with the patch AI suggested earlier and I would like to save it to my local code base. All the magic happens in the unsafe changes section at the end of the AI conversation. Because my local folder is connected to DevTools Workspace, I can see the name of the folder, the DevTools Cinema, and this nifty apply to workspace button at the bottom of the section. When I click it, thanks to the source maps and some more AI magic, the AI agent will find the most appropriate file and appropriate place in that file to apply my fix, even though my code is compiled from SAS or uses a JS framework like Next.js, for example. This allows me to proceed the change to the local files and make my fix permanent.

How can we set up that workspace? Generally, you need to connect the local folder to DevTools and grant appropriate write permissions. You can either do that manually in the workspace tab in the sources panel, or just the same way you would do for in any modern IDE, or you can rely on the new automatic workspaces discovery mechanism. It works like this, you need a JSON file that describes a path to your local folder. If you are on local host and expose this JSON on the particular URL you can see on the screen right now, it will be automatically detected by DevTools. And an option to connect will be displayed in the sources panel. You can add such endpoint to your local server yourself or you can use one of the integrations. For example, Angular has support already built in and for V-based applications, there is a plugin that you can use. Nuxt also showed interest and we hope to get more frameworks on board soon.

To learn more about what is possible with AI assistance in DevTools, make sure to check out the AI assistance home page on developer.chrome.com DevTools section. And the great thing about this is we're not showing you the future. These features are all available in production Chrome now, from Chrome 1.37, which is the production version that you should all be using. They're available without Gemini subscription, so we'd really encourage you to have a go, try them out. If you've been afraid to go into performance tracing before, have a play, it should be much more friendly. And the AI features are not just AI features we're throwing in there for the sake of them, we really find them quite useful for debugging and getting help understanding your code. If you use AI assistance, you'll need to be logged in and to explicitly enable in the settings.

The first time you try to use it, it will direct you to the screen to turn these settings on. And if you're in an enterprise policy, you can also use to control the feature if you prefer to turn it off. All the AI features are still under active development, so we do want to hear feedback from you. Play with them, have a look. If you discover any bugs, any issues, then let us know either in socials, contacting Eva or myself, or by using our public bug tracker.

Well, today, we covered a lot of topics. We talked about performance panel improvements, including live metrics, field data, environment settings, and performance insights. We showed you the dedicated SKI feature in insights and how AI assistance can help you in sources and the network panels. Finally, you've seen how AI can fix some styling bugs and generate code that can be saved to a local workspace. We really hope that you enjoyed the talk and you get a chance to try out all the new features next time you open DevTools. Give it a try and hopefully, you will see some productivity soar as a result.

To stay up to date, please subscribe to our YouTube channel and check out regularly Developer Chrome for our updates. I've been Eva and I'm mostly DevNook on socials. And I've been Barry, and you can find me at TuneTheWeb and the most social websites. We hope that was useful for you, and I think we have a little bit of time for questions. I would also encourage you to come to us afterwards in the Q&A section where we can show this working on your site. Thank you very much.

There are quite a few questions about sensitive data and AI, as you might have expected. So let's group those together a little bit. One of them is, when using the AI button, how can I be sure that no sensitive data is sent? The AI that we use is in the cloud-based AI. We've experimented with on-device AI that Tom talked about earlier, but it's just not quite powerful enough for many of the features that we're looking at here. It does send data to Google, and that's why you have to opt in and accept those settings.

In most cases, it's the public data you see on the website. Obviously, if you're developing on localhost, it's separate. We do know that some companies have restrictions, which is why we have that enterprise policy, which can also be set by individuals. It will be sending data to Google, and there is a detailed page on our privacy policy explaining exactly what the data is used for.

We try to make it very explicit how to ensure data is not sent to the AI. You need to be signed in and enable it proactively in the DevTools settings to be well informed about what is being sent and when. On a website, this data is public anyway, and for most website tracing, it's public data. Improvements to the memory heap panel are not immediate, as tracking memory leaks is still challenging, but it's a feature that many encounter issues with.

Thank you so much. Let's see what is the next question. There's a couple of more questions, like how do I make sure that this is not sent to the AI? We try to make it very explicit. You need to be signed in and you need to actually enable it proactively in the DevTools settings so that you are very well informed what is being sent and what moment, so you can adjust it to your preferences. And again, I would remind you, on a website, this is public data anyway. You might not like it being public. Obviously, if you've got your source code mapped, then there might be comments and stuff that you don't want to do there. But for most website tracing, it's public anyway.

Are there plans to make improvements to the memory heap panel as well? Tracking memory leaks is still a bit cumbersome. I think we got this question previously. You get that a lot, Barry. Yeah, exactly. Memory leaks are a difficult thing to track. I'm not aware of any immediate work being done at the moment. It's kind of a, I don't want to say a niche feature because a lot of people do have issues with that. But for most people, what we have there kind of works and it's really hardcore people that really want extra changes to this normally. And yeah, at the minute, that's not being prioritized compared to some of the other features that we're working on.

I've seen that question popping up a few times, though. So the link we shared for the DevTools bug, I encourage you to submit this as a question or as a feature request and then I'll vote it. And the team is very responsive for feedback. So if it's important for many developers, definitely will be looked into eventually. Absolutely. And particularly if you have suggestions of what you want to improve, just make this better means that we might try something that doesn't work for you. So, hey, no debugger does this. And it's fantastic if only Chrome DevTools did something similar. That's much more actionable feedback. Awesome. Can I submit the AI changes to a project in a dev container? So you can certainly do the changes in the browser.

Awesome. Can I submit the AI changes to a project in a dev container? So you can certainly do the changes in the browser. I mean, they're just like kind of like you locally editing and stuff like that. Whether that can map back to the dev container depends whether the file path is actually mapped and viewable by the browser for the source code or whether it's completely closed off and you're just running it with a port open. Like a lot of cases like Docker uses your local file system and particular part of that. So in which case, again, as long as it's got right access, it should be able to move back to it.

Nice one. Is there an API in Chrome that testing frameworks like Playwrights can use to analyze performance in automation tests? Not yet. Well, in Chrome, not yet. But that is something we've got active interest in and we're doing an awful lot of work on that. And I expect we'll have some updates on that later in the year. Saying that, there's lots of other tools we use. We have a PageSpeed API. We have the Lighthouse CI tool. But yeah, for performance traces, watch this space.

Oh, that's exciting. Maybe next year, JS Nation, we have some news there. Maybe what Gemini model is used in DevTools? Generally, this changes. So we talk to Gemini and Gemini is evolving pretty quickly. It will always be Gemini, but the exact version will differ depending on the browser version and the particular time frame. Perfect. Which features are part of Chromium and which are Chrome specific? I assume, this is the person asking the question, not me. The AI insights are only in Chrome? Yes, so the performance improvements I showed you are in Chromium core base. We have a shared DevTools. Some of them do slightly different things. Edge likes to use different icons, but most of the code base is the same. So they're available everywhere. And yes, you're correct. The AI features of the minute are specific to Chrome. I think we heard earlier Thomas was saying that Edge is looking at those and I expect that they will build upon those and use their AI's and similarly for other ones.

But yeah, the AI features at present are brand new. And literally just launched on Chrome only at the moment, not Chromium. Thank you so much.

Can I simulate a slow socket connection in the performance step? There has been, oh, you're throwing me here. There's definitely some changes we've done to the throttling tab for web sockets. I'm going to say yes, and it's in our documentation. I can't remember exactly, but I'm sure we changed there. And I'm annoyed because you can't do it for general things, only for web sockets. So yeah, web sockets are ahead of the game here a little bit. But check out our documentation, because there is something about that. I think it was a blog post on it.

Well, it's Gemini then. But what was used for AI training to produce those hints and explanations? What do you train it on? So we pass the context window is whatever we're doing. So you click on an element. We pass that element. We pick on a bit of the trace. We pass the bit of the trace or the insight data that's showing there. Similarly, the sources panel will, if possible, send a whole source file. Again, we're getting context limits for really large files. As for the model itself, that's beyond me. And that's the Google AI geniuses that unfortunately aren't represented on stage today. Hey! Okay. Sorry. Generally, the data that is in the context window, which is part of the trace or your prompt or some additional data you're putting in your prompt, is not used for retraining purposes.

Again, we're getting context limits for really large files. As for the model itself, that's beyond me. And that's the Google AI geniuses that unfortunately aren't represented on stage today. Hey! Okay. Sorry. Generally, the data that is in the context window, which is part of the trace or your prompt or some additional data you're putting in your prompt, is not used for retraining purposes. It's not used for training the model. But the performance agent especially has the ability to probe, which means if it doesn't receive enough information to solve your query in the kind of first batch of the context and your prompt, it will go back and request for more additional data from that particular performance trace. So it has access to different parts of the performance trace that is already recorded. It can request this depending on the use case. Yeah, and I think the question is about training, but to go sideways for that, it does use whatever you've selected and done. So if you're clicking on an element and saying, center this element, and then it's kind of natural to have a conversation with it and go, oh, also change that. You can give it much more information and context by clicking on that element and refocusing it towards a different part of the DOM or a different network requests, whatever. Because that's what it uses to actually figure out the answers. We actually highlighted in the UI. So next to the prompt, you see which element is selected or which insight is selected or which context, for example, network request is selected. So that you know, like your prompts should be more or less in the area of expertise of that particular element you're asking. If you ask it, who won the last Super Bowl game? Probably it might not answer. All right, well, thank you so much again for your talk and thanks for your answers. And if your question wasn't asked, please join Ewa and Barry in the Q&A spot to make sure that your question does get answered. Thanks so much. Thanks very much for your time.