I've been running this site for a while now and I like to take a look at the server logs on a daily basis. Amongst the stats, there is a figure for total bandwidth consumption per day. I hadn't really thought about how much bandwidth was being used until yesterday when I decided to calculate how many page views it would take to use up my current monthly allowance of 3GB, because the release of my Easy Google Syntax Highlighter plugin has drastically increased the number of visits I've been getting since Sunday.

The logs for the 22nd show that I had 99 visits, consuming a total of 42.28MB of bandwidth, giving an average of about 420K per visitor. I knew from Google Analytics that most of my visitors are only looking at the plugin page before leaving (why the hurry?), so if that figure was correct, then the act of simply viewing a page on my site is consuming around 400K, and that's an an insane amount of bandwidth for such a simple site.

The investigation

I had to get to the bottom of this and figure out where my bandwidth was going. Firefox is the perfect diagnostic platform for doing this sort of work due to it's abundance of plugins, and one of the best is FireBug.

I enabled FireBug's Net panel, then refreshed the front page of this site. Some 13 seconds later (on ADSL 2), the total at the bottom of the window was 690K. That meant my site was effectively broadband only because it would take minutes to load that much data on dial-up, and even on slower broadband it was going to take a while, probably too long, leading to potential readers simply navigating away.

After regaining consciousness from the sudden shock of seeing that amount of bandwidth being wasted, I took a look at the network breakdown in FireBug. A big part of the problem was the theme I'm using which had two very large, very transparent textures in the background, each adding 200K to the total.

Now, don't get me wrong, the theme was nice, but the textures were barely visible and simply not worth the overhead, so I used Gimp to crop them down to 1 pixel wide and made them completely transparent, leaving my site using 290K, which was still far too much.

The next thing to do was to check out the Easy Google Syntax Highlight plugin I wrote since the javascript brush files that are included on the front page were taking up a significant amount of bandwidth. I realised that although I might need the 8 or so different languages I was including, I didn't need them on every page, so I modified the plugin to scan the body for code tags and only include the languages that are actually referenced on the page. And that cut the total for the page back to about 220K, which was still too much.

The cleverly named WP Minify plugin promised an easy method for installing Minify, which is a tool that can automatically compress files before they are transmitted from your web server, improving bandwidth and reducing page load times. Activating WP Minify brought my front page total down to about 120K which was great, but then I noticed that it also broke all the CSS referenced image files by changing the file load path from to a location that didn't exist.

The annoying thing about this particular issue is that it seems to be specific to the web server since mirroring my blog onto my local development system shows WP Minify to be working properly. As there wasn't an obvious solution to this, I took the easy option and hard-coded the path to all the image files to get it up and running, which at least stopped the flood of 404's that was polluting the server logs.

The conclusion

At the end of the day my front page is consuming a maximum of 148K, down from 690K and that's far more reasonable, though I would like to see it under 100K. I'm going to look into how to achieve this when I get some spare time, and figure out what's wrong with WP Minify while I'm at it, but for now, I'm happy leaving things as they are.

So?

And what about my original reason for looking into this? Before I made these changes, this site could handle a very approximate 6,000 broadband only visitors per month, or roughly 200 visitors per day, which isn't really a lot, considering I'm already getting close to half that many on a regular basis. After the changes it can handle 20,000 visitors on dial-up (OK, still slowly) or broadband per month, which is over 650 per day. The moral of the story is to keep your bandwidth consumption under control for two reasons:

1. If you pay for your bandwidth, it's going to cost you more than it needs to as your site grows.
2. Whether you pay for your bandwidth or not, a slow site is an annoying site and will be a turn off for your readers, and possibly even a barrier to entry.