Thomas Deml from Microsoft gave a great discussion on “My website is slow!  And I don’t know what to do about it!”  Its an aptly named topic.  I spend a great deal of my day looking at performance issues with the shotgun approach.  If key performance indicators aren’t out of whack, figuring out what to do next is a challenge.

Thomas went into detail on a number of things to examine and try.

First off, if you are not yet using Fiddler, go get it.  The tool examines network traffic to and from a client and is a key tool to helping understand web page load times.  Specifically, there is a WCAT (web capacity analysis tool) extension that can be used to simulate load on a server.  While less precise than other stress test tools, this along is better than nothing and looks to help with ensuring the basics are set.

I’m going to interject a few items from my own experience, including the fact that many of these options are available for Windows Server 2003… not just Server 2008.

IIS tweaks

• Ensure default.aspx is your top default document.  Its not a huge change, but with each document request where a document is not specified, like your home page, IIS checks this list in the order shown.  So if you are running .NET or PHP, make sure that handler is listed first.
• Turn off authentication or SSL if not used.  This is especially true with home and static pages.
• Use the browser cache!  On static content pages and folders, set content expiration to 365 days.  This sends a HTTP 304 response on content requests.  As the browser requests the file, if it receives the 304 the file is not downloaded.
• Removed x-powered-by headers.

Server 2008 specific settings

• Use IIS output caching of semi-dynamic content.  These are non-user specific settings that will span multiple sessions and help improve performance.
• Turn off request tracing except when troubleshooting performance.

Things you can (and should) do with .NET.

• Use the ASPNET compiler tool to pre-compile the web application.  Normal operating mode is the first user to request a page will cause that page to JIT, or just-in-time compile.  This means that the first user to hit the page gets the delay, which is often not acceptable.  This tool will precompile all pages within the application at once.
• Watch object size.  An object larger than 85k is treated differently in the .NET memory management model and is garbage collected differently (less frequently, if at all).  Smaller objects with shorter life spans will improve performance.
• Perform IIS tuning.  By default IIS will handle a max of 12 concurrent connections, which may be fine for entry level sites.  Maybe not so much in the real world. 
• As much as possible, don’t use Viewstate.  This is different than ControlState.  Viewstate adds a lot of bytes to the page.

Improving performance by reducing bytes transferred.

• Use output caching.  The demo showed a 5x improvement in performance by just flipping the switch.
• Use the free Microsoft content delivery system for standard JavaScript libraries for Ajax, jQuery, and the .net framework.  The code files are a standard component of the .NET framework and this will offload its download from your server.  Further, it will span servers and applications and will help cache these larger .js files.
• Crunch production ready JavaScript and .css files with AjaxMinify or Doloto.  This removes comments and simplifies variable names.  The net result is file reduction and smaller downloads, but should be used for production deployments only. 
• Ensure that image files are not being scaled by HTML.  If an <img> tag specifies a width of 128 bytes, that should be the size of the image.  Otherwise you are downloading extra bytes (slow) and forcing the browser to do the resizing for you (slow).
• On the topic of images, use .jpg files for photos and .png for graphics files.  Remember to remove .jpg file metadata, as this adds bytes that doesn’t help anyone.

And the biggies; ensure .css tags are at the top of the file and <script> tags are at the bottom.  Native behavior of IIS suspends all other downloads across all download threads when it encounters a script tag.  If if this is a big chunk of Ajax JavaScript, it will give the appearance that the server is thinking long and hard on your page request.  Given the attention span of the average Internet user is 4 seconds, that may be too much.

This was a great session and a lot of good tools and techniques to try out.  Well done Tom!