February 17, 2008

HTTP Performance - Have you been watching?

by Brian Donahue

I've been (finally) watching/listening to DHHBroken Link: http://en.wikipedia.org/wiki/David_Heinemeier_Hansson's RailsConf 2007 KeynoteBroken Link: http://railsconf.blip.tv/file/566943/ while going through the stacks of paper that have grown beyond acceptable height in my office.  One of the things that really caught my attention was his discussion of HTTP performance and optimization and how it is built into Rails 2.0.  Having spent a lot of time optimizing page weight and other HTTP-related issues last year for my biggest client, I really learned the pain that ignoring this stuff can cause, contrasted with the value that a little bit of thought and work in this area can provide.

I really am due for a more in depth blog post on some of this stuff - I meant to do it back then, but probably set my sights too high for a "grandaddy of them all" post, and ended up never starting.  Hopefully I can break off a few bits and write some posts soon. 

The things that DHH focused on in that part of his talk may be some of the most ignored and underrated areas of web development (especially in the ASP.NET webforms world) in regards to overall impact on application performance.  In short, they are:

1. Page weight - VIEWSTATE!  Did I scare you?  If not, check out the percentage of your page weight that ViewState constitutes, and you'll go running for mommy.
2. Dependencies - Ever broken out Firebug Broken Link: http://www.getfirebug.com/or FiddlerBroken Link: http://www.getfirebug.com/ and examined the number of secondary requests (images, javascript includes, CSS files, etc) that your pages cause?  Every one of those adds to your page weight, and the time it takes for a browser to render your page.
3. Number of concurrent requests - Another little-acknowledged piece of trivia is that the major web browsers, thinking that they are helping preserve web server resources, only allow 2 requests at a time for a page.  So, if you are keeping your code simple by breaking CSS and JS out over multiple files, realize that they have to wait in line, 2 at a time, to be downloaded by browsers.  In other words, no matter how fast your users' connections are, they can't get around this.

Possibly the biggest and easiest way to affect this is to add HTTP Compression.  All modern browsers can handle compressed HTTP responses, and it's trivial in .NET to write an HTTPHandler in .NET to do this for you.  This was the single "killer feature" I added for my client, and it basically saved the day for their users with slower connections (and longer distances from their web server).  There are some OSS handlers out there already, and I may throw mine into the mix, as it does some things differently than others I found (at least back when I looked).   DHH mentions that HTTP compression is now built into Rails.

Another thing that is built into rails, which is something that I didn't do, but would be fairly easy in .NET, and probably a *huge* benefit, is to minimize the number of requests by multiple Javascript and CSS files into a single file for each, which means a max of 2 requests - one for all javascript includes, and one for all CSS includes.  That would probably have a great impact on your page load time.

I have some more thoughts (and code) around request/page performance that I need to blog about.  Hopefully DHH's keynote will spur me on to actually get some of this stuff out there.  In the meantime, get Firebug or Fiddler, and check out how large your pages really are, and how long they take to load from the beginning of the first request, to the end of the last (secondary) request. 

You may be in for a big surprise.