Debugging with Chrome DevTools


Jecelyn will share some tips and tricks to help you debug your web app effectively with Chrome DevTools.


Hi all, I'm Jocelyn Yin. I work at Google. I'm the developer advocate for Chrome DevTools. As a web developer, I use Chrome DevTools every day to debug my web applications. Let me share with you some tips that might help you better utilize DevTools for debugging. First tip is about getting to the panel or feature you need quicker with run command. For example, if I want to debug my video, I can go to run command, type media and click enter to open the media panel, or if I want to capture a page screenshot, I can run command with the command shift P keyboard shortcut and type capture. Here you can see a list of screenshot options. Scroll through the list. You will be surprised that there are many commands that you can run. Run command helps save my brain memory because sometimes I just don't remember which panel to open to emulate the CSS stuff theme, for example. Next there are a bunch of keyboard shortcuts in DevTools, but we as humans have limited memory. Instead of memorizing the shortcuts DevTools predefined, you can now customize your own shortcuts. Go to settings, shortcuts. I can customize the run command shortcut. I can either replace the current command shift P shortcut or add another shortcut, say option C to the same command. If you are using Visual Studio Code as code editor, you can map the shortcuts to that as well. Next, there are times I want to debug my search dropdown. However, when I right click inspect on the search box, the dropdown is gone. This is annoying. I mean, I just want to debug the dropdown. Please help. Okay, cool down. Let's pull out the run command and type focus. Select the emulate a focus page option. Problem solved. The reason being is the dropdown is triggered when the user focuses on the input. So use DevTools to emulate the focus effect and you are good to go. Next a new feature. For folks who deal with memory a lot, you can now use the memory inspector to inspect the JavaScript array buffer and Wasm memory. For example, I have an array buffer here. Let's set a breakpoint and refresh the page. Notice the new icon next to the buffer value. Click on it to review the memory inspector. Then you can navigate around and resume the script executions to inspect the memory changes real time. Learn more about the memory inspector with this documentation. Next let's look at the network panel. There are times we want to find out the initiators or dependencies of a particular network request. Hold the shift key and hover the mouse over to the request in the request table. DevTools colors initiators green and dependencies in red. Next you can change the user agent in the network conditions tab. For example, you would like to make sure your page works for search engine optimization because some servers or CDN configurations might block crawlers by default. You can debug such behavior by clicking on the network conditions icon, choose Google Bot from the dropdown, and refresh the page to see if any errors occur. You can also set a custom user agent if none is found on the list. Next some tips on the network filter. You can filter the list by the size. Here I use the larger than keyword to find out requests that are larger than 15 KB. What if I want to find all the requests smaller than 15 KB? I can use the negative sign to negate this filter result. For example, you can exclude all requests with status 200 with the filter negative status code 200. Next let's move on to the console. If you find yourself typing the same JavaScript expression again and again during debugging, consider using the live expressions. This way you type an expression once and then pin it on the top of your console. The value of the expressions updates in near real time. Say I would like to keep track of the dotted images in this page. Click on the create live expressions icon and type document.querySelectorOrImg.length. Right click and duplicate the image element now. See, the number is updated automatically. Nice right? There are also a few handy console utilities that can save your typing time. Just now, we used document.querySelectorOr to get the dotted images of the page. We can use the $$ command to do the same. Also, if I want to print the image element that I have currently selected, I can use $0 to do so instead of typing console.log. I can combine the $ command with copy to copy the element to the clipboard. There are actually more console utilities, refer to the documentations for commands like monitor events, query objects, and profile. Next, if you have code that you frequently use, you can save them as snippets. Go to the sources panel, open the snippets pane. Create a new snippet, say the copy command we wrote previously. Save it. Now, go to the elements panel, select an element, we can run a snippet to copy it. Use command P to pull out the command menu. Then type an exclamation mark followed by the snippet name. The exclamation mark here means execute it now. There you go. Go ahead and save all your frequent use commands as snippets. Next, an undermentioned feature. Use the local overrides to keep changes across page loads. For example, my friend Jack is asking for suggestions to revamp his website about diving photos. We can edit that locally without any deployments. Go to the sources panel, select the overrides pane, then select a folder for overrides. Click allow to grant DevTools access to the folder. Now, we can edit the page. Let's add his name to the title. Try to refresh the page now. Oops, please remember that the changes do not proceed if you edit in the elements panel. The editing should happen in the sources panel. Let's do that again. Save the changes and refresh the page. Nice, the changes are persisted now. Jack likes maroon color. Let's change the title to maroon color as well. Nice. Let's look at the images now. I think Jack can use a more optimized image format like AVIF to improve the page performance. Go to the network panel, filter by image to see how much data we download for the image currently. It's about 450 KB. Let's improve the code by using the picture element. Use command D to select all the image tag occurrence and add in the AVIF image format. Edit the image names and close the picture tag as well. Done. Save all the changes and refresh the page. Let's go to the network panel to see how much data is loaded now. Nice, we cut nearly half the data here. By the way, Brian and Uma have great content on how to use local overrides to compare and optimize page speed. Give it a read. Cool, I can propose the changes to Jack now. But I forgot what I have changed so far. It would be great if DevTools tracked all my changes and show me the differences. And yes, there's actually a changes tab for that. Let's open that. Here you can see all the changes we have made so far. You can click to undo the changes as well. Do you know DevTools is a web application itself? It is built with HTML, CSS and JavaScript. In fact, you can use DevTools to debug DevTools. Make sure your DevTool is undocked. Then tap command option C to open another DevTools. Now you can inspect DevTools with DevTools just like any web application. Our team just migrated DevTools code base from JavaScript to TypeScript and refactored the code base to use the new JavaScript modules. We blog about how we do all this. If you would like to learn more about how we build DevTools, go to our blog at slash devtools-blog. Final one, if you want to give us feedback or file any DevTools issue, you can click on more options, help, report a DevTools issue or reach out to us on Chrome DevTools Twitter. Thanks for watching. I hope this tip helped you enjoy DevTools more. Follow me on Twitter if you have any questions. Thanks for watching.
11 min
11 Jun, 2021

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

Workshops on related topic