Firebug Network Monitoring Quick Reference Guide

Firebug Network Sample

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 is a Firefox extension (although their is a skeleton version for IE, Opera and Safari browsers - "Firebug Lite"). It has an interactive way to interact with your client-side js code, css and other files. It has great support for debugging client-side js code and injecting css on the fly and even editing your HTML so you can see the effects of your changes right there and then, WYSIWIG style!. It also has an 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 (purple, light gray, dark gray, et al). The bar shows you when the file started and stopped loading relative to all the other files. In this example notice how the second file (after Get 1) 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 that is being loaded. Javascript files are loaded one at time in sequence, 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, loaded in parallel.







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 this example 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 enabling caching for 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 1.8s (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. So how do you know if caching has been set? Look at the Cache-Control directive, "max-age = 0", this indicates that the response is cache-able. Also look at the "If-Modified-Since" directive, if the requested variant has not been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 (not modified) response will be returned without any message-body.


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. Also notice the presence of the "Cache-Control" directive in the Response Header, which previously did not exist in the Response Header, it was only present in the Request Header (see example above). The file in the cache will be re-loaded/refreshed once the "Expires" date/time has been reached. Yes, you thought correctly: the "Expires" date/time is calculated by adding the "max-age=28781" (about 8 hours minus the time since the first request was made) to the "Last-Modified" date/time: 22:21:41 GMT + 8 hours = 6:21:41 GMT. Note the "max-age=28781" does not add up to the full 8 hours (28800s) since it reflects the counted down value.

Firbug Header 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 ("Fetch Count"), and in this case 106 times from the disk (cache location for the browser on your machine). Please note that this snapshot of the cache tab was take at a different time than the example above.

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.

Firebug is a free Firefox extension. Ready to install?

Print | posted @ Thursday, July 2, 2009 11:32 AM

Comments on this entry:

Gravatar # re: Firebug Network Monitoring Quick Reference Guide
by steve at 7/27/2009 4:21 PM

I have Network Monitoring Software from Kaseya. I havent had any problems with it and has worked better than expected. I would definately recommend trying Kaseya.
Gravatar # Graphics not showing above: Firebug Network Monitoring Quick Reference Guide
by Niels at 2/29/2012 12:26 PM

You have a very useful guide here.
However, unfortunately my browser does not show the accompanying graphics/photo shots except for the top one. The others are black with an exclamation mark in a triangle. Anyway to enable these so one can follow your text comments better?


Gravatar # re: Firebug Network Monitoring Quick Reference Guide
by krishna at 12/26/2012 7:29 AM

You should never see this error in your Web browser. It should simply present the Web page from its cache - because it believes the page has not changed since it was last cached. If your client is not a Web browser, then it should equally be able to present the page from a cache. If unable to do so, it is not using the If_Modified_Since or related headers correctly. when you press ctl+f5 then here change status it will 200 OK

more detailes
Post A Comment