In the last post, I explained what a web debugging proxy is and what it does, using Fiddler Everywhere as an example. If you missed that, the gist of it is that a web debugging proxy is a program that captures communications between your computer and an Internet server. You can use a proxy to analyze the communications, called “sessions,” as a whole, write your own requests for the computer to send, and modify the responses that the server sends back. Different proxies are good at one of those things or another, and Fiddler is unique in that it can do all three really well. But there’s one question about web debugging proxies that I didn’t mention. It comes up a fair amount in conversations about Fiddler, especially with people with computer science backgrounds, and the answer is fairly complicated.
Isn’t that what Chrome DevTools does?
It’s a very good question, to be sure. Chrome DevTools looks fairly similar to a web debugging proxy like Fiddler, showing a list of sessions and providing detailed information about their contents. Not only that, but it also gives a huge wealth of additional information about the webpage you’re currently viewing, it’s built directly into a very commonly-used browser, and it’s totally free. You don’t even need to download anything, just learn where the button is or what the keyboard shortcut is to bring it up. (It’s Ctrl-Shift-I, or Cmd-Shift-I on Macs.) All of this makes it an incredibly useful and ubiquitous tool for web developers, and you’d think that its existence would make separate proxy programs unnecessary.
However, there is an important difference between what a proxy like Fiddler does and what Chrome DevTools does. To find out what it is, and what it means for which one of them to use, we have to look a little deeper at what, exactly, the data that each of them display means.
What does Chrome DevTools do?
Google Chrome’s Developer Tools, commonly known as Chrome DevTools, is a sidebar that can be brought up on any webpage in Chrome and displays a large amount of under-the-hood information about the webpage. The tools are accessed either through submenus or through the keyboard shortcut Ctrl- or Cmd-Shift-I. The information is spread out across no less than nine different tabs:
• The Elements tab contains the DOM (the browser’s view of the webpage HTML, which can be edited in real-time). Different parts of this document, when moused over, will highlight the parts of the webpage that they encode. This allows insight into how each aspect of the webpage is represented in the code, even for people who don’t know HTML. Clicking on an element of the DOM will show all the CSS classes attached to that element and allow you to edit them. Subtabs of the Elements tab include Styles, Event Listeners, DOM Breakpoints, Properties, and Accessibility.
• The Console tab displays information about any issues the page ran into when it was loading. It also, as the name suggests, provides a JavaScript command-line interface to run commands that can view or alter the JavaScript data for the page.
• The Sources tab displays the folders and subfolders that the page you’re looking at is located in, essentially breaking down the page’s URL and showing you what each of its parts means.
• The Network tab displays all HTTP requests that were made while the page was loading in a similar structure to Fiddler’s live traffic stream. It also has a waterfall chart showing the exact timing of each part of each request down to the microsecond.
• The Performance tab is essentially the expanded version of said waterfall chart, showing multiple graphs of how long each part of the page loading process took.
• The Memory tab lets you take “snapshots” of three different kinds of memory allocations related to the page, letting you know in very specific terms how much memory is being used and where.
• The Application tab lets you inspect all the resources the page has loaded, including databases, cookies, images, fonts, and others.
• The Security tab is fairly self-explanatory, giving information about any security issues on the page.
• Finally, the Lighthouse tab lets you generate a performance report for any website you create.
Whew. That is…a lot of stuff all at once.
What does that mean for Chrome DevTools vs. Fiddler?
The important thing to note here is that the information you can get from Chrome DevTools is not the same as the information Fiddler gives you. It’s a little hard to see because there’s just so much of it, but the Chrome DevTools info is all very specific to the webpage you’re viewing. You can see the DOM for the webpage, the JavaScript for the webpage, the requests the webpage made while it was loading and their timing data, the cookies on the webpage, and so on; but there’s nothing at all about anything besides this particular page. Fiddler, on the other hand, doesn’t show nearly as much detail per webpage, but it isn’t limited to one page at a time. You can see all the Internet traffic for your machine, write requests to any website you can think of, and change around server responses in a whole load of ways. Fiddler is essentially an expanded, broader-scope version of Chrome DevTools’s Network tab.
Because Chrome DevTools essentially operates on a level below Fiddler—the webpage level rather than the computer level—the question of “which one is better” doesn’t apply, because they’re not in competition with each other. They do jobs with a slight but very important difference. Fiddler is good for seeing how a page reacts to outside pressures, like bad requests and jumbled responses, and for monitoring how it interacts with the rest of the Internet. Chrome DevTools, on the other hand, is all about looking inside a page, seeing what makes it tick, and checking if there are any screws loose. They both provide valuable information at different stages of the web development process, which means that they work best when used in tandem. In fact, there are quite a few ways in which they interact directly. For example, one of my favorite things about Fiddler's Auto Responder is that you can set up a rule that replaces a picture on a webpage with a picture of your choice. To construct this rule, you need to find the part of the page’s DOM that contains the image you want to replace, so you can put that code in the conditional part of the rule. Wouldn’t you know it, the DevTools Elements tab has the DOM right there, and shows you directly what parts of the code correspond to what parts of the page. It’s like it was meant to be.
I know it’s tempting to think that there’s one method you can use for everything, but the truth is that the more different answers you have, the more of the bigger picture you’ll see. Debugging a website is like a jigsaw puzzle; Fiddler can only give you some of the pieces. Chrome DevTools might give you some of the same ones, but it’ll give you a bunch of its own that you can’t get anywhere else. Use them both, learn how their answers fit together, and you’d be surprised at what you’ll be able to see.
Top comments (0)