IE9 Developer Tools: Network Tab

At MIX 10 we released the IE9 Platform Preview and showed some of the included developer tools. You can access these tools by pressing F12, or click Developer Tools on the Debug menu when you use the Platform Preview.

The developer tools include some new capabilities and improvements over the tools in IE8:

• A new tab for inspecting network traffic.
• Improved performance working with large JavaScript files: think 70k+ lines of code (even if it’s all on one line!)
• Improved CSS view that lets you work with complex CSS. For example, better consistency when working with @ media rules.

For this first blog post I’m going to talk about the Network tab. The Network tab gives developers insight into what resources a web page is using including the data that is sent to and received from the server. Developers can use this information to see if network responses contain errors, such as file not found or a server side error. The tool also helps debugging AJAX requests as you can examine the data as it was sent and received from the server.

To find the Network tab, open the developer tools in the IE9 Platform Preview.

In the Network tab you need to click Start Capturing to begin recording network traffic. The network tool doesn’t capture data until you click start because collecting network data has an impact on performance and consumes memory. Once you’ve started capturing, refresh the page to see the recorded network requests in the Summary View as they occur.

The Summary View contains the list of all the requests made by the page; it includes:

• The original URL the user requested
• Any files fetched by the HTML and CSS
  • HTML example: <img src=”foo.png” />
  • CSS example: background-image: url(bar.png)
• Requests made from JavaScript
  • Dynamically setting src attributes
  • Requests made by XmlHttpRequest and XDomainRequest objects

Depending on the page, you may also see requests from:

• Browser extensions
  • ActiveX controls like Flash
  • BHOs and Explorer bars

For each request in the Summary View you can double-click on that request or click the Go To Detailed View button to open the Detailed View and see more information about the request.

The Detailed View is broken up into 6 tabs:

Request Headers
A list of all the headers sent with the request including the request line.

Request Body
A text view of any data sent in the body of the request, typically used for POST requests such as form submissions.

Response Headers
A list of all the headers received with the response including the status line.

Response Body
A view of the body of the response. The tool has built in viewers for text and images.

Cookies
A view of the cookies sent and received with the request.

Timings
The last tab contains a graph of times associated with the request.

You can click each of the bars in the chart or list view to get more information about what the time represents.

Once you have a capture you can save it to a file. This is handy if you need to file a bug or send the report to someone else to look at. The save icon is on the tool strip just below the tab, and there are two formats to save the data to: XML or CSV.

The first option is to save the file as a CSV. This saves the summary view and is useful if you want to look at the data in a spreadsheet program like Excel. You can also just select the rows in the summary view and then copy and paste them into Excel.

The second option (the default) is to save the file as XML using a format based on the HTTP Archive. The saved file includes all the data associated with a capture and can be used to examine issues in other tools. For example, Eric Lawrence is extending Fiddler to import HTTP Archive files so you can view the contents using Fiddler. The HTTP Archive format contains useful information that can help assess the performance of a page. For example, the site at https://netrules.tablezengarden.com/, lets you paste the contents of an HTTP Archive file and run some of the YSlow rules against it.

Over on the IE test drive site, we published a new Network Monitoring demo which gives you a way to practice using the Network tab to debug your sites.

We will continue to improve the developer tools in future updates to the Platform Preview. In the meantime, we want to hear your feedback and would love to hear how we can make the developer tools in IE9 your developer tool of choice.

-- Andy Sterland
Program Manager

Edit 6/30/10 - adding a link to blog post on Fiddler importing http archive files.

Comments

• Anonymous
  April 22, 2010
  Is there any XML schema file for the HTTP Tracing format?

• Anonymous
  April 22, 2010
  So, this basically does the same as HTTPWatch? That's pretty cool actually.

• Anonymous
  April 22, 2010
  Awesome! But please provide a way to view request and response headers as plain text so we can copy and paste!

• Anonymous
  April 22, 2010
  will this help improve site & server performance?

• Anonymous
  April 22, 2010
  Awesome.  IE9 is looking cool. By the way, how does one update the developer preview?

• Anonymous
  April 22, 2010
  @Wiiboy: The next developer preview hasn't been released yet. When it is, you simply download and run the new preview's MSI installer.

• Anonymous
  April 22, 2010
  I really like this new feature though I'd like to see the page properties type not display the Windows Explorer "mime" though rather the server's declared mime for the item (e.g. text/html, application/xhtml, text/xml). What would be a nice touch is if the file name/path was in red if there are errors associated with that file (e.g. malformed XML or errors in a JavaScript file) and if you clicked on that file that you would be brought to where the details of that error were displayed. Also I've had difficulty tracking down the correct mime type for icons (favicon.ico to be specific). It was an error in WebKit's web designer tools.

• Anonymous
  April 22, 2010
  Hehe, looks a lot like Firebug, but it's still nice. Now you only need to implement something like NoScript and I'll rethink using Iexplore :)

• Anonymous
  April 22, 2010
  Great work guys! Here is a feature I am hoping for: Some sort of image preview similar to Firebug...

• Anonymous
  April 22, 2010
  @Salamandro: I think Firebug is still the reference, no doubt (although the timing part looks more like Yahoo! Developer). Still, that functionality was already present in Fiddler - too bad this isn't back-ported to IE 8, this way I could debug IE 8 without having to install .Net and Fiddler on my XP VM... Oh well. Anyway. This is nice, still I hope that the timing part will have a nicer GUI - the current one isn't very good-looking.

• Anonymous
  April 22, 2010
  What would be great is if we could use console.log() on a Javascript object and from the console be able to expand its properties like you can with Firebug and the Webkit Inspector. Would this be possible?

• Anonymous
  April 22, 2010
  this should strive to be what google brings to the table with their debugger and network monitor. Chrome has the best of any debugger i've seen. please make that happen. Firebug secondly. safari third. this, dead last.

• Anonymous
  April 23, 2010
  Jeffrey, exactly no one cares about your rankings unless you explain how you're judging.

• Anonymous
  April 23, 2010
  when page is redirected to the page itself, ff will stop redirect after looped for some times. will ie consider to add notification on redirecting same location?

• Anonymous
  April 23, 2010
  If you want to win on CSS inspection then you need to have it in the right click...  I right click on an element and then just inspect it... like safaris CSS inspect...     I also like how safari shadows out all non selected elements

• Anonymous
  April 23, 2010
  If you want to win on CSS inspection then you need to have it in the right click...  I right click on an element and then just inspect it... like safaris CSS inspect...     I also like how safari shadows out all non selected elements

• Anonymous
  April 24, 2010
  @Jeffrey: How can Safari's debugger be third in your list when Chrome's the best? They both use the Webkit's Web Inspector and thus are the same. Please give arguments to support your position.

• Anonymous
  April 25, 2010
  Fantastic, now can you add a dom tree viewer (like the "locals" tab in the script debugger, but starting from the window level). This is a feature which is way overdue in ie developer tools... in fact it's the only reason I use firefox to debug js issues in.. everything else I can do in ie dev tools + fiddler.

• Anonymous
  April 25, 2010
  Great! I hope this functionality will make it into the production release - I want to deploy this on all 30k of my enterprise clients, it will make supporting web issues SO much easier if this tool is ubiquitous. Having a service desk agent installing and using Fiddler just isn't practical in many cases...But use a tool that's part of IE? That we can do.

• Anonymous
  April 25, 2010
  @Wurst There isn’t a schema file at the moment but the format is based on http://groups.google.com/group/http-archive-specification but serialized to XML rather than JSON. @John The type column should show the same value as the content-type header coming back from the server. We don’t look it up based of file extension or do much else with the data. In windows the mime/type for a favicon.ico is officially image/vnd.microsoft.icon. @Jeffery as @skeptic mentions it be great if you can expand on what matters to you in the dev tools.

• Anonymous
  April 25, 2010
  @Dan: Agreed, this is a great new feature for scenarios where you want to gather logs. Until IE9 ships, you might want to check out FiddlerCap (www.fiddlercap.com) which is designed for log-gathering by non-technical users. Compared to Fiddler itself, it is smaller, installs per-user (you can xcopy-install if you want), is being localized into multiple languages, and most importantly, it is significantly simpler to use than Fiddler.