This post completes a series on the F12 Developer Tools included with Internet Explorer (since version 8) to help you improve your websites with tools to review content, diagnose issues, improve performance, and more:

The Network Tab

New in Internet Explorer 9, the Network tab offers an easy way to capture and investigate network traffic and cache requests. You can get a quick report of requests and responses, including headers, timing, and many more details.

“Wait, is this Fiddler ported to IE?”

No, but…

Fiddler is a web debugging proxy developed by Eric Lawrence (who also happens to be a PM on the Internet Explorer team.) While in some cases you’ll see similarities to Fiddler, they are very different in other regards.

Eric gave a great session on Fiddler at MIX11, and spent time (around 12:30 in) describing key differences from the F12 Tools. The session recording and slides are available for free.

Creating a Capture Session

To begin, launch the F12 Tools (Tools –> “F12 developer tools” or just press F12) and click to the Network tab. Click “Start capturing” and request a page (in this case, the IETestDrive home page):

Summary View

By default, captured traffic is shown in summary view, with the following fields:

URL

Method – HTTP method (GET, POST, etc.)

Result – HTTP response code (200, 301, 304, etc.) There are many codes, including redirects and errors. For example, look for 404 results, indicating the URL is incorrect or the content is unavailable.

Cycle through items with the Previous (CTRL + ,) and Next (CTRL + .) buttons, and press “Back to summary view” to return.

Request Timings

Timing details can seem a bit complex at first, but they’re fairly straightforward once you learn a few concepts.

Let’s start with a simple image request from the IETestDrive home page (after clearing the cache – see later), showing Timing details for GraySwooshWatermark.png:

Zooming in to the left-hand side:

The request/response cycle has seven timing components:

Wait – Time since start of page navigation to when the request started.

Start – From when the request was created to when it started to be sent.

Request – When the request was started to be sent to the first response. Also known as time to first byte.

Response – Time from first byte to completion of receiving the response.

Gap – Time between response completion to page load event.

DOMContentLoaded – Time of DOMContentLoaded event.

Load (event) – Time of page Load event.

Click in the list or on the diagram to highlight each timing component.

Tip: If you forget, the above descriptions are shown in the F12 Tools as you click each.

DOMContentLoaded vs. Page Load Event

Why are DOMContentLoaded and page Load different events? DOMContentLoaded fires when the page and scripts are loaded. This can happen before other requests (e.g. for images) are complete, at which point the page Load event would fire.

The difference between these can be significant, especially when downloading large graphics, ads, or other content, so it may be useful to tie script to the DOMContentLoaded event rather than page Load.

Run the example and on the Network tab, click “Start capturing”. Next, hover over the game’s “START” button, but don’t click it yet:

You’ll see an image request (buttonGeneric_Hover.png) was made the moment the cursor hovered over the button:

Request Initiators

Why did IE9 wait to download this? For details, double-click (or hover over for a tooltip) the Initiator field, pictured above showing the value “background-image”, and the following is displayed:

The Initiator tells us what prompted IE9 to make the request. In this case CSS indicated an alternate background for hovering over the button, but IE deferred downloading the image until the hover event was executed. (As shown in Part 2, you can select the button and view the CSS Styles tab to see the input.actionButton:hover rule.)

Now click the game’s “START” button and you’ll notice three more requests:

The requests were for the background for another element, along with the first two playing cards dealt. Click “Go to detailed view” or double-click on of the card requests, then choose the “Response body” tab:

Again, to see why the request was made, click the “Initiator” tab:

Now we see JavaScript changed the src attribute for the img element (in this case to “Hearts_Queen.png”), and that resulted in a request to download the image.

From HTML to CSS and scripting, there are many possible request initiators. Some common examples:

background-image

click

@font-face

<frame>

frame navigate

<img>

@import

innerHtml

<input type=“image”>

navigate

Refresh

<script>

XmlHttpRequest

Taking time to understand initiators will give you another tool for improving page & network performance. For more detail, see “Understanding Download-Initiator” in this Fiddler blog post.

Browser Caching

After a number of Texas Hold’em hands, you may notice requests for certain items either aren’t made or show a 304 Result. This is because they’ve already been downloaded to play other hands and are already available locally.

Restart the application (refresh IE9) and you may see some 304 results. For example:

Notice the large difference in the Received field between cached (304) and downloaded (200) images. In this example, 11.65KB for the full image vs. just 162 bytes for a 304 - Not Modified result.

To clear the cache so requests again hit the network, click the “Clear browser cache” button (CTRL + R).

The Timings field shows timing of later requests relative to the original requests (including time waiting for you to click a button as in the Texas Hold’em example). This happens until you start a new session or click the “Clear” button , which clears results and resets timings for subsequent requests.

Saving Network Captures

As we saw with JavaScript profiling, you can also save network profiling details to an external file. Press the “Export captured traffic” button to save captured results:

Network data can be saved in CSV (comma separated values) format or as XML using the HTTP Archive format, described in this IE Blog post.

Tip: As mentioned in the IE Blog post, you can import these XML files into Fiddler.

Conclusion

I sincerely hope you’ve found this series useful. If you have feedback or ideas for other scenarios to cover, please leave comments here or send me a note.