Enabling website compression to reduce bandwidth use

This content is 15 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

After years of steady growth, markwilson.it has seen a small drop in the number of blog subscribers in recent months.  To me this means one of two things:

  • Perhaps RSS is no longer the most useful way to consume blog content (for example, I rarely read RSS feeds these days and rely instead on what friends, peers and industry contacts “talk” about on Twitter to understand what’s worth reading.  I know that many of my readers follow me on Twitter @markwilsonit too).
  • People don’t like my posts.

If I’m brutally honest with myself, it’s most likely to be the latter – after years of blogging furiously, I have seriously scaled back – partly (mostly) due to a lack of time – and so I guess some people have assumed that I’m no longer blogging (or at least not blogging enough that’s interesting enough to keep in their feed reader).  That’s a shame – and it’s not really something that I want to see becoming a continuing trend.

Graph showing bandwidth growing and exceeding quotaStrangely though, as my blog output has dropped significantly, and my subscribers have dropped (ever so slightly), my bandwidth usage has continued to rise – to the point that my hosting provider actually dropped the site returning a “bandwidth exceeded” message to readers recently (thankfully, this was resolved within a very short time of me noticing and bringing it to their attention).  When I started to look into this, I found that the biggest jump in bandwidth usage related to my upgrade from WordPress 2.2 to 2.9 in January.  I couldn’t understand why the same database, same theme, etc. running on a new version of WordPress would result in a significant increase in bandwidth usage until I saw that WordPress no longer contains an option to compress content for clients that support it, or, in WordPress parlance: “WordPress now leaves compression as a decision for the server”.

There are loads of plugins out there to enable GZIP compression on WordPress 2.5 and later; however I found that the WordPress guys are right – the simplest way is often to let the web server handle the compression – after all, I’d like to compress content (and save bandwidth) for all of my content, regardless of whether it’s served from WordPress.

I found the answer in Ryan Williamscomment on a post at Il Filosofo – by adding a few lines to my .htaccess file (after checking that my host has the deflate module enabled in Apache), I saw a 72% reduction in the bandwidth required to serve my home page.  This is the code I added:

AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/x-javascript application/json application/x-httpd-php application/x-httpd-fastphp application/rss+xml application/atom_xml application/x-httpd-eruby
Header append Vary Accept-Encoding

In a nutshell, this tells the server to deflate various text-based document types.  Job done.  There are various tools available on the ‘net to see if a site has compression enabled (such as GIDZipTest) but my favourite is Is My Blog Working because it also tells me about some other items that I might like to look into to potentially improve the efficiency of the site.  Hopefully now I’ll see my bandwidth fall back within my quota – which should also please my hosting provider.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.