Internet Explorer 9 Developer Tools Deep Dive – Part 5: Network Performance and Debugging

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:

• Part 1 – Introduction
• Part 2 – Working with HTML and CSS
• Part 3 – Debugging JavaScript
• Part 4 – Profiling JavaScript
• Part 5 – Network Performance and Debugging

If this is your first look at the F12 Tools, I recommend you skim through the introductory post first.

Network Performance and Debugging in IE9

So far, our discussion of the F12 Tools focused on the client-side experience, but it’s very important to know how your applications utilize network resources.

Reducing download sizes, finding missing/redirected content, improving cache utilization, and much more can improve performance (actual and perceived) and lower your bandwidth bills.

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.

You can also hear more in Eric’s very recent appearance on episode 116 of the “Herding Code” podcast.

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.
• Type – Content type received
• Received – Size of data received
• Taken – Duration of request
• Initiator – Cause of the request (see Request Initiators below)
• Timings – Graph of request/response timings (see Request Timings below)

Click any field header to sort, and right-click for options such as showing data as bytes and times in milliseconds:

Double-click or select an item and press “Go to detailed view” for full details.

Detailed View

There are seven detail categories for each request:

• Request headers
• Request body – The content (body) of the request, if any.
• Response headers
• Response body – The content (body) of the response.  Shown as text (if script, css, etc.) or visually if possible (image types)
• Cookies – Any cookies sent or received for the request
• Initiator – What prompted the request.  See Request Initiators below.
• Timings – Detailed breakdown of timing.  See Request Timings next.

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.

For a good demonstration of this in action, run the DOMContentLoaded example from the IETestDrive site:

Run it twice to see the impact that browser caching has on the delta between the events.

Analyzing Ongoing Traffic

So far, we’ve focused on profiling network use related to an initial page load, but the F12 Tools can also track ongoing requests, such as requests for additional content and Ajax-based calls. 

To see this in action, we’ll run the Texas Hold’em example from IETestDrive.

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 see this at a higher level, here is an initial request to the CSS3 Media Queries example:

The second request is very different:

Not only is the page ready more quickly, but most requests were served by the browser cache (evidenced by the 304 Results, smaller Received sizes, and fewer blue segments under Timings.)

• Tip: Use the F12 Tools to ensure your web server is setting cache headers that properly set expiration policies.
• Tip: To improve cache hits, ensure file names match in spelling and case wherever referenced. The Network Monitoring example shows the effect of inconsistent case requests.

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.

Thanks, and enjoy using the F12 Tools!

-Chris