Today, I spent a good deal of time configuring vBulletin for a new site I'll be publishing in the not-too-distant future. I came accross a lightbox modification for attached thumbnails and that led me to some really big javascript files. Investigating further, I found that vBulletin itself has 295K in javascript files - separated out into 25 or so javascript files! I'm sure they are separated so that they only get called when necessary, but that is a lot of javascript!
People are leery to compress javascript because even through IE6, compressed javascript exhibits bugs. However, SP1 resolved this issue. Another problem would be the fact that for gzipped files, IE seems to ignore the ETAG header and that means it won't cache those files. Boo!
Just because bugs exist doesn't mean that I have to give up though. Combining a few performance ideas I've had in the past works out to a pretty good solution.
I haven't fully tested this, so it's all hypothetical at this point, but here's what I did -
Step 1 - combine all the javascript files into a single file. This means that there isn't a ton of back and forth slowing down page load times. Further - one thing that I should do is put things into two files - one that absolutely needsd to be loaded prior to page load, and one that can be delayed until after content is visible.
Step 2 - install and configure lighttpd as a web server. Lighttpd works great for static files, has a smaller footprint than apache, and has a great compression system.
Step 3 - compress the javascript files using a javascript compression utility. These utilities slim down the javascript by renaming variables, getting rid of whitespace, etc.
Step 4 - serve up the compressed combined javascript file from my lighttpd server, after having configured it to serve up javascript with gzip compression.
What all of this work amounted to is that the 295K of javascript can be served up in 35K - which amounts to about 7 seconds on a 56K modem - versus 59 seconds in the original version, not to mention the lag because of the 25 round trips the client had to make. Without using the javascript compression utility, the file size jumps to 60K - a significant difference.
Like I said, I still haven't tested this, but I had the same problem with IE caching images served up by CSS. The solution to that problem was to actually send expiration headers. I'm going to try it out tomorrow once I change the vB templates to actually point to the other web server - and I can make judgements regarding which javascript needs to be loaded before the page can be displayed.
With auto-update, and all the security issues with pre-SP1 IE, I would imagine that most people are up to date with a version of the app that supports gzip compressed javascript. If they are not, I can install a simple vb Mod that would point people using buggy browsers to the slow and uncompressed version of the javascript routines.
We'll see how it goes. There are a lot more reasons to use lighttpd in the right situations. I'm not completely sold, but so far the performance is astounding.
Talk About Compressing and Combining Javascript for Performance
