Network Traffic Capturing with IE9 Developer Tools

6 באוקטובר 2010

תגיות: , , , ,
2 תגובות

 

imageInternet Explorer 8 has introduced developers tools for inspecting and debugging web pages. It allows, for example, selecting a DOM element and investigating it, debugging JavaScript by stopping on errors or breakpoints and some other useful stuff. However, one thing was missing there: network traffic capturing and analysis.

Traffic capturing is vital for analysis of your web site. Such tools usually show all the resources that are downloaded during a request, along with their response status, download time, size and much much more. Those tools can be used, to investigate performance issues, verify server settings and just to understand how much bandwidth your site uses. In addition, those tools are indispensable for debugging AJAX requests, as you’re able to see all the data that was send and received from the server.

Without any doubt, the most popular and robust network traffic capturing tool is Fiddler. It operates as a proxy between the network and your browser, so all the browsers’ traffic, first captured and logged by Fiddler, which turns it into a nice graphical representation. If you’re not familiar with Fiddler, I strongly suggest you to try it.

Another tool, worth mentioning is Firebug, which is the most essential development plug-in for Firefox case need to debug or test on that browser. Basically, Firebug is like the IE developer tools, but for Firefox.

imageThe developer tools for the new Internet Explorer 9 include some new capabilities, of which the most interesting is the “Network Tab”, which is used for capturing and inspecting network traffic. Although it is far from being as versatile as Fiddler, it is the most welcomed addition to the IE developer tools, and will suite at least 80% of your needs when examining your site in IE.

To use the new feature, you need to open the IE9 Developer Tools. The simplest way to do it is by pressing F12 while you are in the Internet Explorer 9. Or you can also choose the “Developer Tools” from the “Tools” menu.

Now go to the “Network” tab in the developer tools window:image

To inspect a web site, click the “Start Capturing” button and point your browser to a required URL. For example, this is what I got when opening the bing.com site:image

So what do we learn from this? First of all, that my browser has totally send around 10Kb and received around 21Kb (some of the resources are already in the browser’s cache – we’ll talk about it later). The response included 13 resources too much for such a site IMO.

Now, for each of the resources (actually requests), we can see the request’s URL, the request method (GET, POST etc.), the result, which is the HTTP status, response content type, amount of data received, the total time it taken to receive the response, who has initiated the request and the nice timings chart. Double-clicking a row, or selecting a row and clicking the “Go To Detailed View” button will display more interesting details regarding the request and the following response, including cookies, initiator and detailed timings chart:
image 

As you probably know, every HTTP message consists of a collection of headers and a body.

The Request Headers shows all the headers that were sent in a request, like the request method (GET, POST, etc.), browser’s user-agent, cookies and more. The Request Body, in turn, will show what was sent in a body, for example: form fields, SOAP message or JSON string.

The Response Headers displays headers that the web server has sent to the browser, for example, response status, body content-type, cookies to set and others. As you’ve probably guessed, the Response Body tab shows the actual response content. It can be HTML, XML, an image or whatever the server is sending.

The next two tabs will display a list of Cookies that were sent and received, and the information about the Initiator of the request, which can be a user, another page or something else.

The most interesting tab is Timings:
image
Each request has number of stages, from initiating a request till receiving a response. All are enlisted in this window. The Timings windows is the most useful when debugging performance issues.

In the above example, we can learn that the request didn’t wait in a sending queue (the Wait row). Every browser has a limited number of connections it is allowed to open towards one domain concurrently. Therefore, when there are numerous simultaneous requests, some will wait in a queue.

Start row shows the time from when the request was initially created to when it is sent. 

Request means time to first byte. This is a compound time of sending the request and server processing until receiving the first byte of the response. Unfortunately it is not possible to know how much took request processing on a server, but this value gives a good clue about it, because usually requests are very small in size and therefore sent very quickly (unless you’re uploading a file or sending a large SOAP/XML message).

Response shows the time taken to receive the response data from the server. It depends on your bandwidth and the network latency. Basically, this is the last stage of HTTP request, and the end of it. However, the tool shows more useful information.

The Gap is the time gap between the completion of the request and the time the whole page has finished loading.

The green vertical line shows the point of time when the OnDomContentLoaded event occurred. This event indicates the readiness of the DOM – from this time is is possible to use JavaScript to manipulate it.

The red vertical line indicates the point of time when the page’s Load event occurred, which means the whole page, including it’s resources is ready to be shown in browser.

A little less detailed time-line is also shown in the Summary View, to which you can switch by pressing the “Back to Summary View” button. There are some interesting things you can learn about the Bing’s page traffic.
For example, some of the requests appear after the green and red lines, which probably means those are deferred AJAX calls. 
Some requests return 304 status (Not modified), which means there is an up-to-date resource’s copy in the browser cache. This seems to be good, since the browser didn’t have to download the resource, however, this is very bad, because the browser still had to perform the request, which is an expensive network call, just to know that it has a required resource. The better strategy would be to add Expired Header to those resources’ responses, so the browser will use the cached resource instead of sending an unnecessary request.

Summarizing, the network traffic capturing tool is the most welcomed addition to IE developers tools. It might not be as robust or extensive as Fiddler, but it is certainly a very useful tool which will provide you with a decent service in most of cases.

Have fun,
Vlad

Bookmark and Share

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. (*) שדות חובה מסומנים

2 תגובות

  1. gadib6 באוקטובר 2010 ב 16:14

    looks like the Net tab on firebug

    להגיב