Optimising an ASP.NET website using IIS

Recently I’ve been trying to optimise and tweak performance for a couple of sites; they’re due to go live quite soon and obviously we want them to run as quickly as possible. To do this I’ve been using a combination of lori (Life-of-request info), Firebug. Fiddler and YSlow to see what requests a page makes, how long they take and to rate the page against the Yahoo! best practice guide. When I started we were using Windows 2003 running IIS6, but just this week we’ve decided to give IIS7 running on Windows Server 2008 a go, so I have had to dig into configuration for that too.

The simple rule for making a site run quickly is to reduce the page weight (the combined size of all the resources transferred). This can be done by reducing the size of the files, reducing the quantity of files and delivering the files as quickly as possible. IIS can help out here by compressing and caching so I’ll start with configuring IIS, then move on to a discussion about optimising pages to further reduce their size.

IIS configuration

All modern browsers support Gzip compression; the files are compressed on the server before being sent to the client which means fewer bytes are sent to the browser and the page size is smaller. There is a trade off here, the server side compression does increase the work load of the CPU but it is possible to set the level of compression for static and dynamic files. There’s a great post describing how to compress dynamic content in IIS6 and following the advice I was able to get page sizes down from 650kb to around 150kb.

Using Fiddler I was able to confirm that my files were being gzipped and working through the results added a few other extensions to the list to compress until YSlow gave me an A grade. However when I closed Fiddler and ran the pages again YSlow said none of my files were being gzipped… I have no explanation for this, but as I hadn’t made any change to the server I felt happy that my files were being properly compressed server side.

Another thing YSlow suggested was setting the expires headers to a date way off in the future, this would mean the browser would download the file (css, JavaScript etc) but then not request a new version for a long time, effectively caching it on the client side. Great for the production server though it can be confusing if you update the file before it is due to expire as the client will not request it until the expiration date.

IIS7

The good news here is that IIS7 makes compression much easier, you no longer need to manually edit the metabase.xml because there’s a screen that allows you to enable or disable the compression. You may need to install the Dynamic Content Compression role for IIS 7.0 using the Server Manager if it isn’t already installed.

Next I wanted to know IIS7 Compression. Good? Bad? How much? When making the edits in metabase.xml file I had followed the advice and set static compression at 9 as it has almost as good compression as level 10 but used significantly less CPU cycles. IIS7 has static compression enabled by default and the IIS team have set this at level 7 but the advice from OWScott was to set static compression at 9 and dynamic compression at 4 and he was kind enough to provide the AppCmd.exe command to do that (watch out for line breaks)

C:\Windows\System32\Inetsrv\Appcmd.exe set config -section:httpCompression 
-[name='gzip'].staticCompressionLevel:9 -[name='gzip'].dynamicCompressionLevel:4

This achieved slightly better compression that IIS6 (hopefully this will help me make the business case for moving to IIS7 )

Something else IIS7 does by default is cache static files (though only once they’ve hit a given threshold, as this was decided by the IIS team I’ve decided I won’t interfere as they know much better than me), you can add additional file types / mime types for caching and set them to expire when they’ve changed or after a certain interval.

Application Warm up Module

I’ve just discovered the Application Warm up Module and this looks very promising, I don’t have any hard facts about it yet so can only repeat what’s been said in the post.

Content Delivery Network

I don’t have much to say about this because I haven’t been able to get to use a CDN on anything. That said when my sites need jQuery I am using the Google JQuery CDN, so I get a slight bonus from YSlow for that. Essentially using a CDN means more resources can be downloaded at once as the browser can make separate calls to the various servers hosting the images/css/JavaScript.

Compression / optimisation for pages

Using the techniques above improvements can be made to most sites, there are also some ways you can reduce file size and quantity in development. CSS Sprites is an approach that combines many smaller images into one larger image (though not usually larger in terms of bytes than the sum of all the individual parts) and as such only one image needs to be downloaded saving requests. I’m not a designer, so don’t get too involved with this side of things but it does seem to help in my quest to make pages smaller and therefore faster to load.

CSS and JavaScript combining and minification is not new but will further help reduce the number of individual files downloaded and can be done pretty easily with tools like the Yahoo! UI Library: YUI Compressor for .NET or as part of a build process. Personally I tend to prefer the latter approach as I like to keep my CSS and JavaScript files human readable (I do use a CSS formatter to make sure I’m taking advantage of shortcuts though), only the act of deployment should crunch them down. I haven’t used the Microsoft Ajax Minifier but this enabled you to reduce the size of a JavaScript file by removing unnecessary content and when in hypercrunching mode can even further reduce file size by shortening the names of local variables and removing unreachable code!

Does anyone have any tips they’d like to share? I’d be very interested in other approaches we could investigate.