Around Christmas we tend to get a LOT of web traffic at work, so much so that we exceed our agreed bandwith a allocation with RackSpace and end up having to pay huge excess fees. Not wanting to be caught out for a second year in a row, I had a look at various ways of conserving bandwith and alleviating from the CPU load on the webserver. This is when I noticed something odd–there was a lot of traffic we were being charged for that was not showing up through the Apache logs. After a lot of head scratching and many coffees later, it hit me: cookies. Consider this: an average user on our site has something between 300bytes and 1k in cookie data (a lot, I know). The cookies are being sent alongside with every resource that the client browser requests, be it a HTML file, an image, a CSS stylesheet or a .js file. I did some rough maths and it transpired we waste between 10 and 20GB of traffic each month in cookies alone!

Additionally, the CPU usage was abnormally high and no amount of MySQL tweaking was cutting the load times enough to make a sizeable difference. The sheer amount of files accessed and served was taking its toll and limited CSS spriting was just not going to fix that. The clincher came from Google who announced that site speed is to be playing a role in the search engine results pages from 2010–it was time to introduce a content delivery network (CDN) and fix things.

I had a look around at what CDN providers were around but since we are a relatively small and lean startup, we could not justify the expense of signing up for a enterprise scale solution just yet and yet we needed real-time updates. We elected to just get a cheap collocation server instead with no bandwith quota and setup a sub-domain cdn.ourdomain.com which was to remain cookieless. I then reconfigured the site templates to always reference images, css and js through the CDN URL instead and setup an rsync partnership with the new box. And boy, did that make a difference!

First thing you notice now is how much more responsive the site is, how quick it loads and how much faster the browser renders the content due to the increased threading capability. The CPU load times dropped from an average of 1.40 to 0.30. Out bandwith use subsided from well in excess of 200GB a month to a little over 100GB, well within our quota. And that’s through a ‘pseudo’ CDN, or should I call it a CDB (content delivery box). I imagine the user experience will improve even further when we can roll out a proper solution in the near future, one that will use CDN zoning to provide the fastest download speed to clients through geolocation.

In the meanwhile, I was approached by the folks at MaxCDN who kindly offered to sponsor my blog and provide it with a CDN. I thought, what better chance to test the experience and find out about what’s on offer than to try it for free…

I was uncertain as to how easy it would be to implement within WordPress but it turned out to be a walk in the park through the plug-in W3 Total Cache that they provide and support. The whole setup involved all of 5 minutes of work and no changes to my template files (so long as they all reference the native WP functions for URLs). The plugin takes care of sync and you really have nothing to do than to worry about caching. I am still getting to grips with the options here and weighing in what further bits can be exported to maxcdn in addition to my static content. Other than that, it’s been a breeze and has probably sped up my blog a fair bit too. It’s also surprisingly affordable, especially when you consider what Akamai, EdgeCast or Limelight tend to charge. Even cheaper than CacheFly for the basic package without rsync functionality. MaxCDN’s site, control panel and support are also nothing but excellent.

All-in-all, I am a happy chappy and would recommend CDN use as it’s become a lot more accessible (to my surprise).