From Friction to Flow: Debugging With Chrome DevTools

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Coding and debugging should flow, not fizzle! Let's see what's new and improved in Chrome DevTools to make your web development & debugging journey smooth sailing.

This talk has been presented at JSNation 2024, check out the latest edition of this JavaScript Conference.

FAQ

The main focus of the talk is on removing frictions along the debugging journey to improve the debugging flow.

The speaker uses the personal story to illustrate how hidden tools in DevTools, much like the hidden electronic grass trimmer, can make tasks easier if discovered and utilized.

The 'Emulate a focus page' feature helps debug disappearing elements by keeping the page in a focus state, preventing elements from disappearing when DevTools is active.

You can overwrite network responses by right-clicking on a file in the Network panel, selecting 'Overwrite content,' and then editing the content as needed.

A new feature in DevTools includes a light bulb icon that, when clicked, provides explanations and potential fixes for errors.

Chrome DevTools has removed certain warnings, like those from Chrome extensions' source maps, to reduce noise and distractions in the console.

The 'ignore content script' feature in DevTools ignores scripts injected by Chrome extensions during breakpoint debugging, helping focus on the relevant code.

Users can share their local overrides by setting up a GitHub repo for the override files, committing the code, and sharing it with colleagues.

In the Network panel, a triangle exclamation mark at the top indicates changes, and a purple dot next to the resource indicates it has been overwritten.

Users can request new features or report issues via crbug.com, Stack Overflow (using the Chrome DevTools tag), social media platforms, or by tagging Chrome DevTools or specific team members.

Jecelyn Yeen
Jecelyn Yeen
32 min
13 Jun, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
The Talk discusses the importance of removing frictions in the debugging process and being aware of the tools available in Chrome DevTools. It highlights the use of the 'Emulate a Focus Page' feature for debugging disappearing elements and the improvement of debugging tools and workflow. The Talk also mentions enhancing error understanding, improving debugging efficiency and performance, and the continuous improvement of DevTools. It emphasizes the importance of staying updated with new features and providing feedback to request new features.

1. Introduction to Chrome DevTools

Short description:

Today, I'm going to talk about Chrome DevTools or cars, but I want to focus on removing frictions along the debugging journey. Let me start with a personal story. My partner and I recently moved to a new house with a garden. As lazy people, we waited until the grass grew long before deciding to clean the garden. We found a pair of scissors in the garden but chose to do the job manually. After searching our messy cellar, we found an electronic glass trimmer and finished the job in 10 minutes. DevTools can be like hidden tools in your garage, sometimes hard to find when you need them the most. It's important to remove frictions in the debugging process and be aware of the tools available. For example, inspecting and debugging disappearing elements can be a common issue. Let me show you a demo of this problem.

Today, I'm going to talk about Chrome DevTools or cars, but I want to focus on the part that I'm most excited about. So, the first thing I want to talk about is how we try to remove the frictions along the debugging journey to make your debugging flow better.

So let me start with a personal story. Perhaps you have similar stories like that. So recently, my partner and I, we moved to a new house. The good thing is they have a garden. The bad thing is they have a garden which the grass grows from time to time. And then, as a lazy person, we wait until the last minute after the grass grows for a certain length. Then we try to, okay, we have to clean the garden now.

So we walk across the garden and we found that we actually have a pair of scissors in the garden to do the job, but we need to do that manually. That still do the work. And then after that, since we newly moved to the house, we vaguely remember that in the cellar, two level dowels in the garage, the landlord actually left us an electronic glass trimmer to do the stuff. And then we are also not sure whether the glass trimmer is there. It's faster, but we are not so sure. So guess which one we choose, the manual one or the automatic one? Yeah. So we choose the manual one because we think that we can live with that. So we decided that it should be just fast, one hour into the process of manually cutting, we finally went down to the cellar and then searched around the messy cellar, and then finally we found it and then we do the job under 10 minutes, done.

So the reason why I tell this story is not to tell you how lazy I am, it's not, but to think about what are the frictions that I can remove between this process of me fighting and then cutting the grass? How we remove the friction from this process in order to prepare for the next trim? If you think of it, DevTools, probably is like your, sometimes it's like your garage, it's like your cellar, two level dowels, we have a lot of these hidden tools that you might sometimes get it, know it from your colleague, but you know when you're really like, have a problem, and you try to debug it, and then you might find that oh, there's this feature, maybe it's too far away, I roughly remember that, sometimes you might be not enough time to do a Google search to get the result and then you just leave it wherever you can, try to debug the thing, and sometimes it's because the tool is really too hidden, or it could be sometimes that you don't know what you don't know. The tool exists, you don't even think about finding it and using that.

So take for an example, inspecting and debugging disappearing elements. So I guess a lot of us have these issues before, like if you're using Daisy UI or any UI that have a pop drop down, sometimes the drop down result or the styling is not correct, you want to sort of inspect the result and do some code changes, or the other one, probably you have a search drop down, like the YouTube one, that you want to inspect on the result and do something on it, or if you are using bootstrap, this is the pop over that has the questions. So let me do the demo now to show you the problem. Oh, by the way, the first slide that I showed just now is a real screenshot that I took from here. You can actually use %c in the console log to pass in your style, to style your message nicely like this. Cool.

Okay. Get back to the disappearing element. So let's say if I click on this dismissable pop over, I want to debug this thing. I want to change the style. So what I will do is that usually I will just click on the inspect icon.

2. Debugging Disappearing Elements

Short description:

Oh, my browser froze during a live demo, but I managed to open a new tab. If you face a scenario where an element disappears when clicked, instead of changing your code or using a set timeout, you can use a feature in DevTools called Emulate the focus page. It allows you to inspect the element and can be enabled globally.

Oh, my browser freeze. Let me just refresh that, do that again. Do that. Okay. Okay. The whole browser freeze. You know, this is doing live demo on the stage. Cool. I will open a new tab on it. Okay. I'm using Chrome Canary, by the way. This is cutting edge. Yeah. That's why that's what cutting edge means. Okay. Let me just open this one. Okay. Cool.

So you want to debug this. If you try to click on this icon and try to inspect it, you see? That thing is gone. How many of you faced this scenario before? Okay. So the way that you do this, maybe you go and change your code, or maybe you go and inject a set time out, like don't know how many seconds, in order for you to do the action quickly and then come back to the flow. So the thing is, this feature in DevTools that exists for probably five or six years already, but no one discovered that. But recently, we do something good. We make it slightly visible. So now if you go to the Elements panel, Styles tab, if you go to this hour button here, if you click on it, there is this function called Emulate the focus page. If you tap on that, now you can inspect it. And this checkbox itself, it is a global setting. You can just turn it on and never turn it off. Okay.

3. Debugging with Emulate a Focus Page

Short description:

Is it useful? There's a reason behind the name 'emulate a focus page'. Some pop-ups and dismissible elements depend on the document's focus state. By using the 'emulate a focus page' feature, you can debug elements based on this focus state. Initially, we considered enabling this feature by default, but it may affect background processes that depend on the Page Visibility API. After evaluating the risk, we decided not to enable it by default, but you can turn it on to debug these issues. This feature has existed for ten years in the rendering tab, but it is not widely used.

Is it useful? If it's useful, give me a clap. Yeah? Okay. Now you might say that this name, why is it called emulate a focus page? By reading the name, I also do not know this is for debugging disappearing element. This is a good question. No one asked here, but I answer myself, because I get this question a lot. So if you want to understand why this pop-up disappear, there's a reason behind it.

So this sort of pop-up and the dismissible thing, sometimes it's because they are depending on the document that has focus state. So by the way, I'm using this little button here. This is called live expression, which you don't need to refresh DevTools and add in your value from time to time. It will just automatically run every time and keep track to update it. So this document has focus now because I'm in DevTools, means that my document, the page itself, is not focused. So that's why, if I move my cursor to the page, now the document has focus is true.

So if I click on DevTools again, it is gone. That's why the thing is dismissed because the page is no longer focused. This emulates a focus page, basically it's to fit the focus back to the page so that whatever element that you debug based on this focus state, then you can debug it. And we have a long discussion about this feature because this is so intuitive and it's like a regular problem that developer hits. Initially, we want to try making this checkbox enabled by default so that you don't need to think about it and you can just debug your issues. But the thing is, for those of you, if you have some background process that depends on this API, it's called the Page Visibility API. For example, if you open a new page, your document is no longer visible. Turn on this setting will impact this because the page will keep on remaining visible even if you move to another page. So let's say, if you have some, your page depends on some, if the page goes to the background, you have some process to run to test it, then this wouldn't work if you opened DevTools. So after evaluating the risk, we decide to, no, we are not going to turn it on by default, but you can turn it on one time and then forget about it to debug these issues.

So just now I mentioned this feature actually exists for ten years. It is in the rendering tab. Anyone use the rendering tab before? Okay, compared to the hands-up just now, it's much lesser. So this is quite a long process. So you need to click on this three-dot menu. What happened to my mouse today? Never mind, I have a ... Yeah, to the rendering tab. And then you need to scroll down all the way, somewhere maybe, oh, you see, I can't even find it.

4. Improving Debugging Tools

Short description:

Emulate a focused page has existed for many years, but it is often overlooked due to its placement in DevTools. By moving it closer and improving discoverability, we hope to alleviate the frustration of debugging disappearing elements. Another example is overriding network responses, which has also been available in DevTools for a long time. We have simplified the process by allowing you to right-click on a file in the network panel and easily overwrite the header or content.

Somewhere here. Yeah. So somewhere here, yeah, here. Emulate a focused page. Then you can turn it on to do that. That already exists for many years. The thing is, it is so far away, so by moving it closer, we hope that it solves your, what we do is that we also track the usage. So we saw that 1,500 percentage increase on the usage. So I hope that you are in this 1,500 now and have less suffering when you try to debug the disappearing element.

Okay. Sometimes it takes more than just moving stuff to remove the frictions from your development flow, debugging flow. Take another example, overriding network responses. This feature is also assessed in DevTools for many years. So let me show you what I mean. So anyone of you heard about this feature? Okay. Quite a lot of hands, but also quite less a lot of hands. Okay. So if I refresh this page, what I can do is, for the JavaScript, CSS, and document file, or whatever file, what I can do is I actually can overwrite this style.css file to inject my new style. So for example, I open it in the styles tab. So what I can do is I can go to this area here, click on overwrite, and then enable this local override to try to mock the responses, basically. So if I enable this, what I can do now is that I can start writing some script here. Let's say the background, I change it to lavender. So I can do this, when I save it, it will sustain a cross-page load. It's different from what you do in the elements panel, it doesn't sustain a cross-page load. But this is good, that you can do this, but the thing is, how many steps do you need to do? You need to first see the result in the network panel, go to the sources, find the resource, and not only that, you need to click on this dot, and then to find the override button to enable it first to begin with. So this is a lot of stuff. So what we do now is that in the network panel, what you can do is you can just right-click on a file, and then there is consistently this overwrite header, overwrite content button that you can click. You can do this for the JavaScript file as well, so you can just overwrite the content, and then we'll just save it for you. Even if you haven't done that yet. And moving it closer is not enough.

5. Improving Debugging Workflow

Short description:

We have made it consistent for you to overwrite content by requiring a locally set up folder to store the result. Even if you haven't set up the folder yet, we provide a setup menu to guide you through the process. We also added new features to support mocking APIs and response headers. By right-clicking and selecting 'overwrite content' in DevTools, you can paste in your own data to mock the API response. This has resulted in a 200% increase in feature usage. Additionally, we have introduced a helpful feature that allows you to click on the light bulb icon for more information on errors, providing assistance for both experienced and junior developers.

We also make it consistent that, let's say in order for you to do overwrite, you need to set up a folder locally so that we can store the result in that folder. So even if you haven't set up the folder yet, we consistently show the menu there. So if you haven't set up, we will just show you a setup menu to have you click a folder, select it, and set it up. And if you already overwrite the content, you can come back to here and edit the same file again and again. And we also add a little bit more features into Dit to support mocking APIs and mocking response header.

For example, in this, in here, I like Bobati, so let's search for Bobati. Uh-oh, see? The API endpoint doesn't work. So what do we do now? We probably go to this fetch result and see that, oh, the result is 404. Since this is my local development, I'm developing this website, then I was like, oh yeah, the backend engineers haven't had the result ready yet. So sort of like either we create our own API, mock the API with whatever server, fixed server that you have, or you just change the result in your code. That's another way to do that. What you can do is you can right-click, and then you click overwrite content, and then what you do is you paste in, okay, yeah, I have a data store here, so I will just copy the data, go to the request that I overwrite, paste that in to mock it, and then now I tried it again. The result is here. So I can use this mock result as long as, until the backend engineers say that, hey, the API is ready, then I remove, I delete this overwrite result and use the one that the server provides.

Is this nice? Okay. So, by moving it closer, making the experience consistent, we saw about 200% increment in the usage of this feature. I hope you go and try so that the next time I do the checking again, it will be 400%. And bonus, in order to make it more helpful, there is one more friction that we can remove from this whole process. So for example, let's say now you have finished the development, you deployed it to the production. Very good. When you go to the production page, I do the same thing again. This time, the error is different. It says the type is, like, failed to fetch. So what do I do now? I go and read my console. It says that there's no access control origin. As an experienced developer, I know what this means. But it can be a lot of reasons that are causing this. But as a junior developer, it can be really, I don't know where to start and how can I get more help on this. So the next thing you do, probably you copy this, put this in a browser engine, or put that in any AI tools to ask, hey, what is this error about? The good thing is, there's new features that you have in DevTools. Do you spot the light bulb icon here? You can actually click on this, let's try, and then say that continue.

6. Enhancing Error Understanding

Short description:

DevTools can generate explanations and code examples to help you understand errors. If the explanation is not sufficient, you can regenerate it for a different result. You can also fix issues by adding code to the server or overwriting the response header in the network panel. These features are available in the U.S. and will be coming soon to the E.U. We remove console warnings to reduce distractions and allow for easier error searching.

So it will try to help you understand this error. So it will give you some explanation on what the error might be because. And then sometimes it will give you, like, some code example as well. So if you think that, oh, this explanation is not good enough, you can try to remove it and then try to regenerate it again. So it will try to generate a different result to help you explain the same questions. So let's see. Yeah. So this time, it also helped me to, it also tell me how can I fix the issue. So if I say that, oh, probably I should add this SS origin, this one, in the server. So I know that I copy this and then I tell the server engineer, the backend engineer, to add this to the backend. But sometimes it takes time. So what I can do is I can copy this code, go to the network panel, right click on the result, say that I overwrite the header, and then I can overwrite the response header by pasting it. And then if I do that again, I can go to here. So I can do this until the backend return the result. So you can overwrite the server header.

Good! I did not ask for the clap this time. Thank you! So this is to help you understand better the code. One note, though, these features, we launched this feature already in the U.S. and outside of E.U. We are still, because this is something to do with AI and Gemini. So it's coming soon to the U.U. We'll announce it once it's ready. So if you don't see the light bulb yet, probably you need to wait a little bit until we sort it out. Cool. Next thing, too many data, too many alerts and warnings here and there. It's a noise as well. And this actually distracts you from your actual work. This is also one of the frictions that you might have. So one of the things we do is we also remove some warnings from the console so that you can search for the error that you want and to try to get into that. So if you have seen this error message before, this is a lot.

7. Improving Debugging Efficiency

Short description:

Chrome DevTools removes warnings for Chrome extensions and allows you to ignore certain files and folders for faster debugging. Console messages are improved by removing irrelevant stack trace lines.

Especially for those of you who have a lot of Chrome extensions installed, you may see this message. It's good, but not useful because you can't ask the extension to not load its source map, which pollutes your trace. However, in the latest Chrome release, we have removed all these warnings. Give it a try! We also help you debug quicker by ignoring certain things. For example, we ignore content scripts injected by Chrome extensions and some framework code. We also ignore certain files in the node modules. This setting can be turned on in the DevTools settings. By ignoring these folders and files, you can step into your own code instead of the browser code, making debugging faster. It also improves the console messages by removing irrelevant stack trace lines, allowing you to focus on the relevant ones.

8. Improving Debugging Performance

Short description:

DevTools ignores framework folders, framework code, and node modules by default. This helps you debug better by allowing you to step into your own code instead of the browser code, making debugging faster. It also improves console messages by removing irrelevant stack trace lines, reducing debugging costs.

We also ignore some of the frameworks folder, some of the framework code when you do that. And lastly, we also ignore something in the node modules.

Now your question is, like, what do you mean by ignore? So this is where DevTools turns this setting on by default in the settings, ignore this. So this is exactly what we turn it off.

So for example, if you are in a Next.js application. Now let me go to here. In the Next.js application, if you go to the sources, you can see that all these folders are grayed out by default because these are ignored by default.

So now your question is, like, how can this help me to debug better? So for example, for some of you, if you set an event listener breakpoint, you want to capture all the mouse clicks on the page and debug that, you can go to this event listener, click on the click event, and when you try to start debugging, you straightaway jump to this function here. And if you go closer, actually, you can have this show ignore listed frame to see, like, what have DevTools been ignoring.

So by default, when you click on this mouse click, because there is React code that's running behind, supposedly you should be jumping to this React code first before going to this active list. And when you debug step by step, sometimes it will suddenly jump to the framework code instead of your own code. But that's not what you want. So by ignoring the node modules folder and this framework file by default, you don't need to worry about that. You can just step by step, step into your own code instead of the browser code. So that makes things faster.

Another thing that it improves is that in the console message. So let's say now if you click on this activate a list button, it actually has an error here. So let's see. If you look at this error message, which line of the stack trace is the one that is related to your code? It's only the first line, right? Yeah. And all the other lines, basically, it's not that helpful for you. Supposedly, if you remove them all, it can be helpful for you to view all the other messages. So with that, we can actually shorten the console error and make fewer debugging costs when you do the testing.

This is the error message that we see just now. It's not just the error message. If some of you do the debugging before, there's a dropdown that you can click on that. There are actually two parts of the stack trace that you can look into, depending on what you are debugging. So on the top is the error stack trace. At the bottom is the message stack trace. So on the top basically tells you where did the error happen. So in this case, the index is on line number 10.

9. Enhancing Debugging Features

Short description:

DevTools collapses the bottom stack trace and upcoming features will further enhance the collapsing functionality. The waterfall column in the network track can now be hidden, and the extension URL can be hidden from the network log. These features have been requested for several years and are now available, prioritized based on user feedback.

And then the bottom stack trace is to tell you where was the error log, the message log. Because you catch the message in a different area of your code, so the message log could be somewhere different from where the error happened. So the good thing is that in DevTools, we already used that information to collapse the bottom stack trace for you, the message stack trace for you. Now if you click on it, if you expand it, you don't see 18 others framed that is not related to you because we collapsed it by default. You can just click and expand that to look into it.

And the next thing, which is coming soon, is we will collapse this. The final result that we want to achieve is something like this. So this is one line, and then you can click show acknowledge to expand it. Is this good? Okay. This is still a working process, and actually the contribution of this thing is thanks to the Wassell team. They actually sent a CL for us to fix this. So hopefully it will land soon. So the concept here is that, does this thing spark joy? If it's not, then we'll just hide it right away.

And lastly, speaking about hiding, we also have some little improvement here. Last time in the waterfall column, you will see it take the whole space in the network track that now you can actually hide it. And the other one is that if you have a lot of extension and you try to debug your own network result, it will be polluting. Supposedly you can use the incognito mode to do the debugging so that you don't have the extension, but now we added these features to let you to hide the extension URL from the network log itself. So this is quite helpful for you. The thing is, these two features have been someone is creating for a long time. Let me show you the thing. So this waterfall, to remove the waterfall in the stack overflow, it has been requested for six years ago and built 9000 times. And then this one, this year, one of the users, so we also have a bug that created for six years ago. Then we received this message recently. There's too long of the message but the gist is that it used 8000 developers to find the network for nothing but to be a waste of space. So this person has been consistently telling us, hey, please remove it. It's not helpful for us, for six years. So good for you. If you are in the crowd, you finally can do that. And to be honest, 8000 developers is important, but we also received a lot of other requests. For example, the high extension, it's built 24k times, it's created 11 years ago, and we only recently put in the features because you actually have the alternative way to do it, and it doesn't, because there's a lot of activities and we have a lot of features and we have limited resource, so it just doesn't rise up to the priority sometimes.

10. Continuous Improvement and Staying Updated

Short description:

Be patient and keep asking for features. Contribute fixes and improve DevTools. Recommended reading: Atomic Habits. Stay updated with new features through the 'What's New' tab.

So be patient with us. If you really want the features, keep asking. If you ask and do not get it, keep asking and creating a feature request to us. And if you want, you can contribute a fix. It's actually a web application, the whole Chrome DevTools. So if you know how to develop a web application, you actually can contribute to DevTools. This is the link for it if you are interested. So what we have done so far this year is that we try to make things obvious, attractive, and make it easy and satisfying for you to use. So I actually also highly recommend this book, so I read this atomic habits books to improve my personal habit, but actually if I think of it, it's actually applied to product, like the UX design as well, on how to help developers, how to help ourselves to do things more easily. So almost there, if you want to learn more about new features and do deep dive in DevTools, I try not to dismiss the what's new tab that pops up from time to time. Click on the link, you will see like some articles and the video to talk about like some new stuff and how can you use them to fix some of the issues.

QnA

Staying Updated and Overrides in DevTools

Short description:

Users should not dismiss the 'what's new' tab. Improvements are available in all Chromium browsers except for console insights. Overrides can be shared with colleagues by setting up a folder or using a GitHub repo. Overrides live as long as they exist locally and can be disabled. The network panel provides warnings and indicators to differentiate between real styles and overwritten data. The easiest way to override GraphQL requests with the same URL is not mentioned.

Okay, thank you. That's all.

Somebody asked how can they find out about new improvements in the DevTools. As Jesselyn said, don't dismiss the what's new tab.

Quick question from somebody but important to me as I work on a Chromium browser that's not from Google. Are these improvements available to all Chromium browsers or only Google Chrome? Okay. So like for all the things I mentioned just now, it's available in all the Chromium browsers. That's great. So that's Microsoft Edge. So one of it is the exception is the console insights, like the button that you click to help you describe, that is not available in the other Chromium browsers, only Chrome. Yeah. Thanks, Jesselyn.

Some quick fire questions. Can I share my overrides with colleagues? Okay, so this is a good question. So if you want to share the override with your colleague, it is possible because you need to set up a folder in your local PC. So what you can do is you can have a GitHub repo for that repo for the file that you created, then you can just commit the code as you do, then you can share it with your colleague. But there is no sync features in DevTools that you can sync the override to the other PC because that would be too dangerous. You sort of need to set up a Git repo or place for you to share that. Thank you.

Somebody asked, Jesselyn, how long does the override live? How long does this? Okay, so this lives as long as it can because it's in your local drive. So what you can do is you can delete that, then it will no longer do the override. Or you just need to check on the checkbox that disable the override, then we won't use your override file, even if that file exists. Thank you.

Alexander asked, how do you differentiate between real styles and data that you've overwritten? Maybe you forget in two weeks that you've got an override on? Yes, this is actually a really good question. So in the network panel, if you see on the top, sometimes it comes out with this triangle exclamation mark, it's a warning icon to tell you that, hey, some of your network result actually changed. We show that warning icon wherever you have stuff that you override or wherever you have changed your network speed, like you drop it to 3G or 4G, you do that. And then in each of the overwritten resource in the network panel, you can see a purple dot that will indicate that these are the requests that get overwritten. Thank you.

And I'm sorry this is a machine gun of questions to you. What is the easiest way to override GraphQL requests? Because all of them have the same URL."

Providing Feedback and Requesting Features

Short description:

To provide feedback and request features for Chrome DevTools, users can file requests on crbug.com and ask questions on Stack Overflow. Jesselyn Yin also monitors social media platforms for requests and features. Let's give a round of applause to Jesselyn Yin.

So I get that request, file a request in the Chrome DevTools, just file an issue feature request, because there's no easy way now. Because I know that the GraphQL request is like a big chunk. So sorry, but you can file a request and remember asking and keep asking. Thank you.

The last one, again, back to what you were saying about friction. Somebody asks, Jesselyn, in addition to crbug.com requests and community feedback, how else do you find out about these frictions in Chrome DevTools? How can we let you know? Okay. So one thing, of course, is crbug.com is our main resource. The other one is Stack Overflow. So in Stack Overflow, you can file your questions under Google, I think Google Chrome DevTools has a Chrome DevTools tag. And then, from time to time, I will look into it. And then to answer questions as well. And to understand, are these requests highly viewed? And then is this something that we can do immediately? And also social media. So if you tag Chrome DevTools in the X platform or you tag me, I will also look into this request and log the request, the feature. So these are the social media, crbug, Stack Overflow, YouTube, the video under it, I left the comment. We'll use all those. Yeah. Thank you.

Okay. I want you to give a huge round of applause to Jesselyn Yin. Thank you.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Modern Web Debugging
JSNation 2023JSNation 2023
29 min
Modern Web Debugging
Top Content
This Talk discusses modern web debugging and the latest updates in Chrome DevTools. It highlights new features that help pinpoint issues quicker, improved file visibility and source mapping, and ignoring and configuring files. The Breakpoints panel in DevTools has been redesigned for easier access and management. The Talk also covers the challenges of debugging with source maps and the efforts to standardize the source map format. Lastly, it provides tips for improving productivity with DevTools and emphasizes the importance of reporting bugs and using source maps for debugging production code.
Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
Watch video: Debugging JS
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
Debugging with Chrome DevTools
JSNation Live 2021JSNation Live 2021
11 min
Debugging with Chrome DevTools
Top Content
Here are some tips for better utilizing DevTools, including using the run command, customizing keyboard shortcuts, and emulating the focus effect. Learn how to inspect memory, use the network panel for more control over network requests, and take advantage of console utilities. Save frequently used code as snippets and use local overrides for easy editing. Optimize images by using a more optimized format like AVIF and track changes in the network panel to see the reduced data size.
Static Analysis in JavaScript: What’s Easy and What’s Hard
JSNation 2023JSNation 2023
23 min
Static Analysis in JavaScript: What’s Easy and What’s Hard
Static analysis in JavaScript involves analyzing source code without executing it, producing metrics, problems, or warnings. Data flow analysis aims to determine the values of data in a program. Rule implementation in JavaScript can be straightforward or require extensive consideration of various cases and parameters. JavaScript's dynamic nature and uncertainty make static analysis challenging, but it can greatly improve code quality.
Debugging a Non Reproducible Crash
React Advanced 2021React Advanced 2021
20 min
Debugging a Non Reproducible Crash
The Talk discusses a vicious bug that caused 20,000 crashes in a JS application. The bug was an array index out of bounds exception in the SimplePool class. The team used a debugger to analyze the bug and discovered a race condition caused by an upgrade to React Native SVG. They collaborated with React Native contributors to fix the issue and deployed a patched version. The Talk emphasizes the importance of using a crash reporting tool, monitoring release health, and learning from bugs and source code analysis.
JavaScript Source Maps, Can We Do Better?
JSNation 2023JSNation 2023
27 min
JavaScript Source Maps, Can We Do Better?
Source maps allow understanding of transpiled, bundled, or minified code. Debugging with post hoc and debug identifiers helps identify files. Issues with source maps include hash collisions and missing function names. Various techniques can be used to determine the function that caused an error. Source maps can store additional information and improvements can be made to path resolution and column positions. Code points and token positions can differ across browsers. Detecting source maps can be challenging without a standardized JSON schema.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Tracing: Frontend Issues With Backend Solutions
React Summit US 2024React Summit US 2024
112 min
Tracing: Frontend Issues With Backend Solutions
Top Content
Featured WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Frontend issues that affect your users are often triggered by backend problems. In this workshop, you’ll learn how to identify issues causing slow web pages and poor Core Web Vitals using tracing.
Then, try it for yourself by setting up Sentry in a ready-made Next.js project to discover performance issues including slow database queries in an interactive pair-programming session.
You’ll leave the workshop being able to:- Find backend issues that might be slowing down your frontend apps- Setup tracing with Sentry in a Next.js project- Debug and fix poor performance issues using tracing
This will be a live 2-hour event where you’ll have the opportunity to code along with us and ask us questions.
React Performance Debugging
React Advanced 2023React Advanced 2023
148 min
React Performance Debugging
Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
The Clinic.js Workshop
JSNation 2022JSNation 2022
71 min
The Clinic.js Workshop
Workshop
Rafael Gonzaga
Rafael Gonzaga
Learn the ways of the clinic suite of tools, which help you detect performance issues in your Node.js applications. This workshop walks you through a number of examples, and the knowledge required to do benchmarking and debug I/O and Event Loop issues.
Instrument, Monitor, Fix: A Hands-On Debugging Session
React Summit 2025React Summit 2025
88 min
Instrument, Monitor, Fix: A Hands-On Debugging Session
WorkshopFree
Lazar Nikolov
Lazar Nikolov
You just shipped a new feature. Tests passed. CI’s green. Everything’s deployed. Life’s good… until the alerts start rolling in. Users reporting “weird stuff happening”, UI glitches, vague “it seems slow” reports, and that dreaded “can’t login” message. Well, this is shaping up to be a bad day. But… maybe not.Watch this hands-on session to learn how to build it, break it, debug it, and go from “no idea what’s wrong” to fixing issues—all in one go. Since we’re serious developers (obviously), we’ll use Next.js and:Setup Sentry from the ground up - including Errors, Session Replay, and TracingLearn ways to use Replays to understand the real user experience, and how to use Tracing to debug application issuesLeverage Sentry AI and the context of your application to understand what’s actually broken, and use Autofix to generate a fix - from root cause all the way to PR.Use this workshop guide to follow along: Quickstart Guide.
Solve 100% Of Your Errors: How to Root Cause Issues Faster With Session Replay
JSNation 2023JSNation 2023
44 min
Solve 100% Of Your Errors: How to Root Cause Issues Faster With Session Replay
WorkshopFree
Ryan Albrecht
Ryan Albrecht
You know that annoying bug? The one that doesn’t show up locally? And no matter how many times you try to recreate the environment you can’t reproduce it? You’ve gone through the breadcrumbs, read through the stack trace, and are now playing detective to piece together support tickets to make sure it’s real.
Join Sentry developer Ryan Albrecht in this talk to learn how developers can use Session Replay - a tool that provides video-like reproductions of user interactions - to identify, reproduce, and resolve errors and performance issues faster (without rolling your head on your keyboard).