Aug
10
2009
The project I have been working on lately is very javascript heavy. Throughout the dev cycle we kept wanting to optimize, but we never got around to it. We released, everything worked, and it was fast - people were happy! Unfortunately those on a slow connection might not have seen things the same way. It turns out the page people would spend most of their time on was a fat 800K (in some cases closes to a 1MB!) I guess we shouldn't have put off optimization after all.
Whitespace in a file is nothing more than whitespace. (Revolutionary, I know!) I am no different than any other dev. I like my code on separate lines, I like my code indented, but why should a computer care? The same can be said for comments.
The first thing I did was minify our javascript and css. Essentially, this means all comments and all extra whitespace was stripped out. If done properly, nothing will change in the execution. However, make sure you thoroughly test because there were a few errors that were found after the fact. This one step alone brought our page size down to ~500KB.
The next step was to optimize our images. We were able to get about 20K out of this. Granted, this was site wide and the page in question only benefited from about a single KB, but I'll that that. I have actually worked on project where optimizing our images saved us about 100KB per response. I say per response because the images being sent back to the client were not cached.
Speaking of caching, the next thing I did was make sure all static content was cached on the client. In a perfect world content such as javascript, css, and images will be cached indefinitely. You can then version your files to make sure that the client will get the changes when you release. Luckily for me this was already being done, so I didn't have to tackle it.
My next move was to turn on compression in IIS. static compression was already happening, but I went and enabled dynamic compression. As expected, this significantly reduced the size of the response. Remember, nothing is free. When it comes to compression, a decrease in bandwidth means an increase in CPU. Personally, I consider that an easy trade off. CPUs are cheap. If you are going to be turning on compression, I highly recommend reading this post by Scott Forsyth.
With those out of the way, I turned to YSlow. Even though some of the recommendations are only applicable if you are a Yahoo or Google sized company, you can still glean some useful tips from it. All in all, The page size was reduced from 800KB to 200KB. A whopping %75!
Remember, performance should not be an afterthought. It is much easier to do things right the first time instead of going back and making the changes later. Your users will thank you for it.