JavaScript Debugging Tips Part I – Google Chrome and the Network Tab
This blog post is the first in a series of debugging tips and tricks to help you on your way.
It’s a jungle out there. And like it or not, it’s a jungle inside your application as well. Working through the bugs isn’t as simple as slowly sifting through lines of code; it takes dedicated tools and candid curiosity. In the jungle, the momma gorilla has little more to rely upon than her courage and her cunning. But as a web developer, you have a variety of tools at your disposal. Today, we are going to take a look at the Network tab inside Google Chrome’s Developer Tools.
Accessing the Chrome Developer Tools is easily done using shortcut keys (Control + Shift + I) or by navigating to the top right of the browser, clicking on the three grey horizontal lines, then choosing “Tools”, then “Developer tools”.
Unlike the momma gorilla, Chrome Developer Tools cares about you and your applications. It likes you. It thinks you’re a really good developer. But you need to do some work. It’s kind of like Esri Support. We like you. We want to help you, and we’ll be there when you take the first step.
While the developer tools are open, you can clear the browser cache by simply clicking and holding the refresh button. This action presents you with three different options: Normal Reload, Hard Reload, and Empty Cache and Hard Reload. These options help you ensure that changes to your code are reflected in the browser. Otherwise, the application may load the older code from the browser’s cache. When I’m feeling blue, a couple of Hard Reloads always does the trick. If it’s near the end of the day, you may want to empty the cache first. 
Now that you’ve cleared the cache and reloaded your application, we can continue. Like the developer tools in other major browsers, such as Firebug, and standalone tools like Fiddler, the Network tab in Chrome logs individual requests spawned from the tab currently open in the browser. Typically, a variety of resources are loaded when a page is refreshed and additional requests are executed while the user is interacting with the page.
The Network tab is my personal favorite. I always open this tab before running any test application. Here we can focus on inspecting web traffic to discover how the application interacts with online services. If there is a print service in the application, you can grab the webmap as JSON in the network tab, and compare it’s parameters against the REST API to see if the JSON is valid. You could also see all the resources the application is consuming, and where those resources are located.
If something has gone visibly wrong in the application, the first things to look for are requests that have failed entirely. The most common errors are a 403, indicating that you don’t have permission to access the resource, and 404, which means the resource can’t be found. In my own experience, 404 errors are most often caused by a typo I introduced when I wrote out the location of a service, because I write code like a momma gorilla.
This screenshot shows the Network tab open with a 404 error (Not Found) in the network traffic regarding a missing .css file on the server named localhost (I put the .css in the wrong folder)
In this installment, we learned how to access and use the Network tab inside Chrome Developer tools to reveal the individual requests launched by an application, and their success or failure. This information can greatly facilitate the debugging of an application when minimal other error information is available by indicating to the developer what is occuring behind the scenes, and on what areas in the code to place focus. This concludes part one of a multi-part series on JavaScript Debugging Tips. Join us next time when we delve even deeper into the Network tab with a real-world example. Happy debugging!
