Internet. It’s a great thing, with all them tubes and all. Never have access to kittens and boobs (although never at the same time) been easier. Unfortunately, the internet is built with technology that in many cases date back to the stone age. Take HTTP, for instance. It’s an ancient protocol. In layman’s terms it makes sure that all the lolcats you crave are displayed in your browser. But the HTTP protocol was designed back in the days when the number of kittens on the internet was close to none and it doesn’t scale well with today’s demand for content. No matter how fast your internet connection is, you are hampered by the restrictions of the HTTP protocol.

A solution to this problem might be SPDY, an HTTP enhancement proposed by Google. From Wikipedia:

SPDY (pronounced speedy) is an experimental networking protocol developed primarily at Google for transporting web content. Although not currently a standard protocol, the group developing SPDY has stated publicly that it is working toward standardization (available now as an Internet Draft), and has reference implementations available in both Google Chrome and Mozilla Firefox. SPDY is similar to HTTP, with particular goals to reduce web page load latency and improve web security. SPDY achieves reduced latency through compression, multiplexing, and prioritization. The name is not an acronym, but is a shortened version of the word “speedy”.

The goal of SPDY is to reduce web page load time and that sound like a good idea to me. When I learned last week that mod_spdy, the SPDY module for Apache 2.2, was out of the beta phase, I decided to go for it and install SPDY on my site.

All SPDY connection are made over HTTPS, which is a fortunate side effect of using SPDY. The end users will get extra security at no extra hassle, because they don’t actually have to do anything - all the extra work is on the site owner, in this case me. I had to go ahead and buy an SSL certificate, but that took only 15 minutes and cost me $20. A greater challenge was to get all the web site elements to work correctly when using HTTPS: If one or more elements on a page using HTTPS is referenced with HTTP, the browser will quickly throw a fit and complain quite loudly about a potential security issue.

In my case it meant removing the thumbnails from the last.fm plugin since the thumbnails were only available from a non-secure server. An option would be to have my server download them locally and host them myself, but are the thumbnails really necessary? Probably not. I also had some troubles with embedded video, which are usually hosted on non-secure servers as well. Thankfully, YouTube offers a secure option when embedding and more and more providers will most likely follow as SPDY gains traction and support.

And it will. I was able to shave off about 1 second of load time on my site with SPDY, which is a lot considering the relatively low number of elements on each page. The features of SPDY are being integrated into HTTP 2.0, so even though SPDY might not be approved as a separate protocol by the IETF, the specification will be part of a long overdue HTTP 2.0.

As long as I was playing around with the site, I decided to upgrade my current WordPress cache plugin to W3 Total Cache. It took a little time to configure and tweak it, but I managed to get the average load time of the main page (with SPDY in Chrome) down to about about 1.5 seconds. I think it was as high as 5 seconds. Not too bad. My Munin graphs also show that both system load and ethernet IO is down a little with SPDY and W3 Total Cache in use. Good times.