Firebug Network Monitoring Quick Reference Guide

Network Monitoring

Your web app on the server has plenty of tools and ways to measure performance, as well as tools like SQL-Server Profiler for SQL databases. But how do you trace, track and debug client-side code interactively? The use of alerts has been useful but does not support an interactive way for you to interact with the web-page on the fly. To make matters worse, even if you place some traces into your js code to help find the slow functions, etc, network latency may be another cause of slow response. Or maybe the order your files are loaded is an issue? Or maybe their are caching issues. Well, Firebug to the rescue. It has an interactive way to interact with your code, css and other files. It has great support for debugging code and injecting css on the fly. It also has a informative network activity tracking tab, which is what this article is all about, that will help troubleshoot network latency, caching and other network related issues.

Watch the timeline unfold
Every file that is included and loaded into your web-page is represented by one row in the table. Notice how the files are loaded not just one after the other, but also when they start loading and end loading by looking at the file's bar. The bar shows you when the file started and stopped loading relative to all the other files. In this example the notice how the second file (after Get 1) is only starts loading after its predecessor (GET 1) has ended, but how the four files loaded after the first one's bars overlap. The first file is a JavaScript file, which are loaded one at time, never in parallel. The second to fifth files are also JavaScript files, but they are loaded from the cache and can be loaded in parallel. The last five files in this example are images.

A description of the information in the panel:

1. Name of files : The first column shows the names of all the files that were loaded as part of this web-request. Note it is not a running history and only applies to this page for this single web-request. Also note the GET prefix to the name which depicts the method of the request (POST vs. GET).
   
2. HTTP Status : The second column shows the status of the HTTP request and the code. Some interesting codes you may see in the example are: Code 200 being successful HTTP request, code 304 stating that the file was not modified since the last request which is based on some caching time-limit.
   
3. Base URL : The third column shows the base URL of each file. If you are loading files from other sites (e.g: linking image from other site, putting ads in your page) then a different URL will be shown for that particular file.
4. Size : The fourth column shows the size of each file.
5. Load Time : The last column shows the time it took to load that particular file. It also shows whether or not those files are loaded from the cache. The different colors used for the bars have significance:
   1. Green : DNS Lookup
   2. Light-Green : The time to connect to the server
   3. Light-Brown : The time it waited in the queue. You'll notice this when loading js files as they can only be loaded in sequence, not in parallel
   4. Purple : The time waiting for a response from the server
      
   5. Dark Grey : Request sent to server, file loaded from server and not the cache
      
   6. Light Grey: Request sent to server, “304 Not Modified” received, file loaded from the cache.

Note that the order of the files in the list denotes the order in which the files where loaded from the server. Also take note that js files are loaded in sequence, one-after-the-other.

Break it down by type

Sometimes you are particularly concerned about a certain type of file, like HTML (GET 1 in this example) files or images. Click the buttons in the Net toolbar to filter the list by type. This is also a great way to find out the total size and download time for a particular type of file.

Cached or not cached

A picture is worth a thousand words. In the example to the left a lot can be taken from the color of the bars. Each file's network request can be different, some are loaded from the cache and others have to be loaded from the web-server over the network. Firebug color codes each request that is served from the cache in a lighter gray and darker gray for when it is loaded from the server (see the fifth file, 907ms).



Files loaded in sequence (not parallel) follow each other, you can see this by the bars not overlapping. This is not true for cached js files however, as can be seen for the js files loaded with a "304 Not Modified" HTTP status code. See how the images are loaded in parallel?! These are all indicators of bottlenecks and design issues that can be a great tool in performance tuning your app.

Lets see what the effect is of setting for caching a file. Have a look at the GetjQueryScripts file that is loaded (by the way this is a call to an MVC action method called GetJqueryScripts that loads one js file for all jQuery scripts by combining them on the server). Note in the example to the left that "GET GetjQueryScript" has a status of "200 OK". This means it has been loaded from the server (not a cached version). I also took 2.36s (seconds) to load from the server. This is the first time this JavaScript file is loaded from the server although caching has been set for this file.

Now lets see what happens on the next page request. Notice how the HTTP status has changed from "200 OK" to "304 Not Modified". Since the file has caching enabled, it told the client (your browser) to cache the file for a predetermined amount of time for subsequent requests. There are three tabs now, as apposed to the previous example where there was only a Headers and Response tab, now there is also a Cache tab, denoting that this file was cached.

Some of the information in the cache shows the time it was last modified and how long this file will be cached for, which is the Expires property that tells you that it expires in about 8 hours. It also shows how often this file was requested, and in this case 106 times from the disk (cache location for the browser on your machine).

Examine HTTP Headers

HTTP headers contain a lot of information like the mime type of the file, the type of web server, caching directives, the cookie, and lots more.


XMLHttpRequest monitoring

There is also an Ajax tab for requests performed via the XMLHttpRequest module. Since a browser has no visual way op representing what is happening during this AJAX request to the user, unlike when we submit a page and you see the progress indicators on the browser showing you the progress, FireBug's XHR tab exposes these events and you can see the start and completion of these AJAX requests and if they were successful and what was returned from the server in the Conole tab's Response tab . If the template gets too busy simply click the Clear button.