I recently installed YSlow, a Firefox add-on integrated with the popular Firebug web development tool that does performance analysis based on the rules for high performance web sites developed by Yahoo.
I tried it on DosPecesCreations.com, the e-commerce site I recently built for my wife using Ruby on Rails, and was surprised to learn that the site received a failing grade according to the YSlow Report Card.
It took me just over an hour of clicking on the explanations for failed failed categories and researching how to make some of the configuration changes in Apache to bring that grade up to a high B.
Bringing it up to an A would require me to use a Content Delivery Network like Akamai Technologies, which deploys content across multiple, geographically dispersed servers and dynamically chooses the fastest option in a given scenario based on proximity and available connections. However, since the customer base for the site is not international and we don’t have thousands of dollars a month to spend at the moment, I’ll just have to content myself with being a B student.
So what was the payoff for making these changes?
I wanted to have a somewhat objective way to measure the performance improvements, so I also downloaded HammerHead, another firebug add-on that provides average load times for pages with and without the cache being used.
Here are my baseline metrics.
Here are the results after I made the changes.
As you can see, I more than doubled the speed of the site with little effort and almost no coding changes. Here’s a quick summary of what I did:
- Reduced the size of the HTTP response
- Enabled Gzip Compression - This is done in Apache with an output filter, which I enabled by adding one line to the .htaccess in the root directory of the site.
- Minified Javascript Files – This involved removing all the comments as well as unneeded white space characters (space, newline, and tab) from javascript files. Luckily there are tools such as JSMin that will do this for you. I ran the Ruby version of JSMin as a Rake task and was able to reduce my Prototype Javascript Library files by about 25%.
- Removed Unused Javascript Reference – This sounds obvious, but by using the default option with the javascript_include_tag Rails helper tag I was referencing 6 Prototype files even though I was only using 2 of them. By removing the unused references, I was able to trim 65k from my pages.
- Reduced # of trips
- Merged javascript files – The Rake task I used above also merged the remaining prototype files into one file so the client would have to make one less round trip to retrieve the files.
- Enabled Caching – I configured Apache to use Far Future Expire tags for my static content (images, js, & css) and Cache-Control tags for my dynamic content (2 hour expiration). I followed the recommendation of disabling ETags as well even though this only appears to only interfere with caching on web farms and I’m currently on a single server.
- Maximized parallel download speed – I did this by moving all my scripts from the html header to the bottom of the page. Apparently javascript files can block parallel downloads so simply moving these from the header to the bottom of the page will increase the overall load time.
I used this resource while making all of the Apache configuration changes. If you’re using IIS, then you might want to try this post.
As someone who spends most of his time doing middle tier and database development, I was surprised to learn how much of a web application’s performance is affected by these front end concerns.
Luckily, all of these front-end recommendations were much easier to fix than almost any performance tuning efforts applied to the back end.
No related posts.
Comments(2) 
Enjoying life after VSS. Next stop, 
When you just need to