Prerequisite= s

If you have not yet install= ed and configured Microsoft Fiddler, please begin with the first installment in th= is series: Part 1: HTTP Debugging.

Fiddler PowerToy - Part 2: HTTP Performance=

HTTP Performance: An overview

It’s no secret-- users love fast websites. Users are notoriously impati= ent, and unless your website has no competitive substitute, users are unlikely to stick around if your site’s performance doesn’t measure up. If your site has visitors from aro= und the world, ensuring your site operates efficiently is even more critical, as international network connections generally suffer from the twin banes of snappy sites: high latency and low bandwidth.

There are many options for improving your site’s performance: compression, caching, geographic load balancing, adding hardwa= re, and so forth. Optimizing the = use of compression and caching is often the best place to start, as configuration changes are generally free and can return dramatic benefits.

In this article, we’ll use the Microsoft Fiddler= HTTP Debugger to explore HTTP performance, caching and compression.

Tweaking “First Visit” Performance

On their crucial first visit to your site, visitors mu= st download every piece of content used to generate the page, including JScrip= t, CSS, images, and HTML. If you= r page is too slow to load, visitors may leave your page before it’s even do= ne downloading!

By exposing all HTTP traffic, Fiddler readily shows wh= ich files are used to generate a given page. Shift+click multiple entries in the HTTP Sessions list to calculate the “total pa= ge weight”—the number of requests and the bytes transferred:

The best way to ensure a “Wow, this is fast̶= 1; first impression is to deliver fewer and smaller files.

Tips for fast first-visits:

Use fewer graphics
Extract styles into a single CSS file
Extract script blocks into a single JS file
Simplify your page layout
Use HTTP Compression

Once you’ve tuned your site for a fast first vis= it, you can make it even faster for return visitors by taking advantage of HTTP caching.

Introduction to HTTP Caching

Two key factors in improving the speed of your web applications are:

1. = Reducing the number of request/response roundtrips

2. = Reducing the number of bytes transferred between the server and the client.

HTTP caching is of the best ways to reduce roundtrips = and bytes transferred. Caching pr= ovides a mechanism for a client or proxy to store HTTP responses for later use, so that requests need not cross the network.&= nbsp;

Other than performance, another benefit of maximizing = use of HTTP caching comes from the fact that bandwidth isn’t free. By tuning caching for a major Micr= osoft site, we were able to reduce our outbound bandwidth costs by over $10,000 per month.

Cache-related Request Headers

To enhance performance, Microsoft Internet Explorer and other web clients maintain a local cache of resources downloaded from remote web servers.

When a resource is needed by the client, there are thr= ee possible actions:

conditional HTTP request to the origin server asking for the resource= only if it differs from the l= ocally cached version

Pragma: no-cache

The client is unwilling to accept any cached respons= es from caches along the route and the origin server must be contacted for a fresh copy of the resource.

If-Modifie= d-Since: datetime=

The server should return the requested resource only= if the resource has been modified since the datetime provided by the client.

If-None-Ma= tch: etagvalue

The server should return the requested resource if t= he ETAG of the resource is differ= ent than the value provided by the client.&n= bsp; An = ETAG is a unique identifier representing a particular version of a file.

A client indicates that it has a cached response avail= able for use by sending a “Conditional request” containing the heade= rs If-Modified-Since or If-None-Match. If the server replies to a Conditional Request with HTTP/304= Not Modified, the client is thus directed to reuse its cached response.<= span style=3D'mso-spacerun:yes'> Otherwise, the server should retur= n a new response and the client should discard its outdated cache item.

Below, observe two consecutive requests for an image f= ile. In the first session, no locally c= ached version of the file is present, so the server returns the file along with a= n ETAG value and the date-time of = the last modification of the file. In the subsequent session, a locally cached version of the file is now availab= le, so a conditional request is made, passing up the ETAG of the cached response as well as the Last-Modified time of the original request. Since the image has not changed since the cached version (either because the ETAG matches or the If-Modified-Since value matches = the Last-Modified value) the server returns a 304 to the client to direct it to use the cached response.

&nbs= p; Session #1

GET /images/banner.jpg HTTP/1.1
Hos= t: www.bayden.com

HT= TP/1.1 200 OK
Da= te: Tue, 08 Mar 2005 00:32:46 GMT

Content-Length: 6171
Co= ntent-Type: image/jpeg
ETag= : "40c7f76e8d30c31:2fe20"
Last-Modified: Thu, 12 Jun 2= 003 02:50:50 GMT

&nbs= p; Session #2

GET /images/banner.jpg HTTP/1.1
If-Modified-Since: Thu, 12 J= un 2003 02:50:50 GMT
If-None-Match: "40c7f76e8d30c31:2fe20"
Hos= t: www.bayden.com

HT= TP/1.1 304 Not Modified

Because a HT= TP/304 response contains only headers and no body, it crosses the network much more quickly than if the full resource had been re-downloaded. However, even a HTTP/304 requires a full roundtrip to the remote webserver; by carefully setting response headers, a w= eb application developer can eliminate the need to issue even conditional requests.

Cache-related Response Headers

Generally, the cacheability of a HTTP response is cont= rolled by headers sent in the response. The HTTP spe= cification describes the headers which control caching. The optional Cache-Control and Expires headers are the primary mechanisms for web server to indicate to a proxy or= a client how content may be cached.

The Ex= pires header contains an absolute date-time after which a cached copy of a respon= se should no longer be considered fres= h. If the Expires header contains something other than a date (0 or -1 are common values) t= he response should be treated as stale= immediately. A fresh cache entry may be reused without contacting the server again; a stale cache entry shou= ld not be reused without first contacting the web server to ensure that it is still up-to-date.

For example, let’s look at the previous example, except we’ll add an Expires= header to the first response:

&nbs= p; Session #1

GET /images/banner.jpg HTTP/1.1
Hos= t: www.bayden.com

HT= TP/1.1 200 OK
Da= te: Tue, 08 Mar 2005 00:32:46 GMT

Content-Length: 6171
Co= ntent-Type: image/jpeg
Expires: Tue, 12 Jun 2007 02:50:50 GMT
Last-Modified: Thu, 12 Jun 2003 02:50:50 GMT

&nbs= p; Session #2

<no HTTP request is made; cached version = is used automatically>

As you can see, we’ve improved performance by ad= ding an Expires header, since no conditional HTTP request is made during Session #2.

Similarly, the Cac= he-Control directives supersede the Expires<= /span> header.

Commonly used

Public	The response may be stored in any cache, including c= aches shared among many users.
Private	The response may only be stored in a private cache u= sed by a single user.
no-cache	The response should not be reused to satisfy future requests.
no-store	The response should not be reused to satisfy future requests, and should not be written to disk. This is primarily used as a secu= rity measure for sensitive responses.
max-age=3D= #seconds	The response may be reused to satisfy future requests within a certain number of seconds.
Must-reval= idate	The response may be reused to satisfy future request= s but the origin server should first be contacted to verify that the response is still fresh.

Notes

You can learn more about how to configure caching for IIS here: http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;247404
You can learn more about how to configure caching for ASPNET pages here: http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;323290
If you find that you often update files on your website without changing = the filenames, take care to set appropriate cache lifetimes. For instance,= if you want For legacy reasons, servers may send a Pragma: no-cache header. This is treated as Cache-Control: no-cache.
The Vary header signals to a cache that a response is valid for reuse only under certain circumstances. F= or example, use Vary: User-Agen= t to direct that the current response may only be reused for future requ= ests sending the same User-Agent<= /span> header. The directive Vary: * is equivalent to Cache-Control: no-cache.

Using the HTTP Sessions list, Fiddler users can see wh= ether pages contain HTTP Caching headers.

If a response does not contain Expires or = Cache-Control headers, the client may be forced to issue a Conditional Request to ensure = that the resource is still fresh.

Conditional requests and the WinInet cache

Internet Explorer takes advantage of the caching servi= ces provided by Microsoft Windows Internet Services (WinInet).

WinInet allows the user to configure the size and beha= vior of the cache. To access the c= ache settings:

Tools menu, choose Internet Options
General tab, in the Temporary Internet Files box, click Settings

At the top of the settings dialog, there are four choi= ces:

The vast majority of users leave the setting at the de= fault of “Automatically.”

The most important fact to keep in mind is that these = four options mostly impact the behavior when there are no caching headers on the HTTP responses; when caching headers are present, Internet Explorer will always respect them. The following t= able describes the impact of these settings on request behavior:

Setting	Cache copy is fresh=	Cache stale	No cache-directives were present=
Every visit to the page=	No request	Conditional request	Conditional request
Every time you start In= ternet Explorer	No request	Conditional request	Conditional request
Automatically	No request	Conditional request	Heuristic (see below)
Never	No request	Conditional request	No request

Cached content is considered fresh if the request is made during the freshness lifetime specified by the Cache-Control or Expires headers on the original response. Cached con= tent is considered stale if the req= uest is made after the end of the freshness lifetime specified.

The Automatically setting bears some explanation—how can WinInet know if the cached resource is fresh when no caching directives were provided on the server’s HTTP response?

The answer is that WinInet can’t know for sure a= nd a Heuristic process is followed to make a “best guess” effort. In the Automatically state, the Heuristic will issue a conditional request unless all of the following crit= eria are met:

The cached resource bears a Con= tent-Type that begins with imag= e/
The cached resource has a Last-= Modified time
The URL to the cached resource does not contain a question mark (hinting = that it’s a CGI request)
The cached resource has been conditionally requested at least once within= the most recent 25% of its overall age in the cache

If all of the criteria above are met, no request is ma= de.

As a web developer, you should always ensure that you = send appropriate caching headers to guarantee you get optimum cache behaviors.

Flagging Performance Problems

You can use Fiddler’s Custom Rules to draw atten= tion to potential performance problems. For instance, you can flag any response larger than 25KB.

To add this rule, click Rules then Custom Rules, and add the following code inside the OnBeforeResponse event handler:

// Flag files over 25KB

&= nbsp; if (oSession.responseBodyBytes.le= ngth > 25000){

&= nbsp; oSession["ui-color"] =3D "red";

&= nbsp; oSession["ui-bold"] =3D "true";

&= nbsp; oSession["ui-customcolumn"] =3D "Large file";

&= nbsp; }

Similarly, you can flag responses which do not specify caching information:

&nbs= p;

&= nbsp; // Mark files which do not have caching information

if (!oSession.oResponse.headers.Exists("Expires") &&

!oSession.oResponse.headers.Exists= ("Cache-Control")){

&= nbsp; =

oSession["ui-color"] =3D "purple";

&= nbsp; oSession["ui-bold"] =3D "true";

&= nbsp; }

Introduction to HTTP Compression

All popular web servers and browsers offer support for= HTTP Compression. HTTP Compression= can dramatically decrease the number of bytes which are transmitted between the server and the client; savings of over 50% for HTML, XML, CSS, and JS are common.

A web browser signals to the server that it is willing= to accept HTTP compressed content by listing the supported compression types in the request headers. For inst= ance, consider the following request to the new MSN Search homepage:

GET / HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Host: search.msn.com

The Accept-En= coding header indicates Internet Explorer is willing to accept responses which have been compressed using either the GZIP or DEFLATE formats.

The MSN Search server obligingly returns the compressed contents; the Content-Encoding response header indicates the GZIP format was used:

HTTP/1.1 200 OK
Content-Type: text/html; charset=3Dutf-8
Server: Microsoft-IIS/6.0 -- Microsoft-HTTPAPI/1.0
X-Powered-By: ASP.NET
Vary: Accept-Encoding
Content-Encoding: gzip=
Date: Tue, 15 Feb 2005 09:14:36 GMT
Content-Length: 1277
Connection: close
Cache-Control: private, max-age=3D3600

Using Fiddler, you can decompress the response using t= he Transformer tool on the Session Inspector tab.

Click the No Compression radio button to decompress the response inside Fiddler. Compression reduced the number of = bytes transferred by over 57%.

The savings are more dramatic for the common.css file used by t= he MSN Search homepage; the CSS file was compressed 81% (from 25,288 bytes to 4,648 bytes). Note that image files= like GIFs, JPEGs, and PNGs gen= erally are already compressed and thus usually are not delivered with HTTP compression.

You can use Fiddler to simulate HTTP compression by ch= ecking “Simulate GZIP Compression” on the Fiddler Rules menu.

Enabling compression for static files in IIS has a min= imal CPU impact on IIS web servers, because the files are compressed only the fi= rst time and then cached on the server. Enabling compression for dynamic files like ASP.NET pages may impact your servers’ CPU performance; you’ll want to evaluate this performance impact before enabling dynamic compression on production web servers.

Winning the Performance battle

Improving HTTP efficiency is only half of the challeng= e; if your web application itself is slow, it won’t matter how efficient your HT= TP traffic is. You can learn mor= e about performance optimization here: Ten Tips for Writing High-Performance Web Applications.

To be continued…

In this installment, we’ve covered HTTP performa= nce and how to flag HTTP performance issues using Fiddler.

In future installments, we’ll continue to explor= e how Microsoft Fiddler can help you build better web applications. Please feel free to suggest new to= pics for this series using the Help | Send Feedback option inside Fiddler.

Note: Fiddler version 0.9= .9 is now available. Also availa= ble is an early beta version of the Fiddler Script Editor, a syntax-aware script-editing environment.

About the Author: Eric Law= rence is a program manager on the Internet Explorer team. Before joining the Internet Explorer team, Eric worked on Micr= osoft Office Online and as an intern Program M= anager on Microsoft SharePoint.