Maximise WordPress by minimising bandwidth: Part 2 E-mail
Sunday, 16 August 2009 00:51

Following on from my previous post on this topic, I am pleased to report that I was able to achieve my goal of 100K to load the front page of this blog, thanks to three handy plugins.

Easy Google Syntax Highlighter

Yes, I'm going to plug my own plugin and admittedly, this only applies to blogs that are displaying source code or text files in the body of posts. The biggest saving from the changes I made for this project come from the "Auto Brush" option (by default, I left it in the off position, so you'll need to turn it on after installing). When enabled, this causes your web server to only send the syntax files for the languages that are currently being displayed to the reader, rather than sending the contents of every syntax file in case it's needed. Sure, that's a bandwidth saver, but it's also a time saver on your reader's desktop since their computer doesn't have to grind away at the 20 or so syntaxes supported by the default Syntax Highlighter package, making your blog more responsive.

WP Minify

Here's yet another Google hosted project making the web a happier, shinier place. Minify is a php application that seeks to strip out white space and comments from CSS and Javascript files and bundle them up to save bandwidth. WP Minify is a plugin that makes installing Minify on your blog a snap.

Well, it should have been, but it turns out that there's something odd going on in Minify when dealing with images in a CSS file when referenced by a relative path, which results in the image paths being broken. It took a while to understand what was happening, but I eventually found that I was able to resolve it by changing all the relative paths in my theme into absolute paths starting from the wp-content folder. After doing that, WP Minify has been working like a champ.

Since writing this post, I've encountered a problem that breaks wp-minify on, as usual, Internet Explorer. To improve performance when loading Javascript, wp-minify concatenates all the files into one, and the process includes concatenating all the filenames and paths together. IE7 and below (and possibly IE8) has a limit on the length of the concatenated filenames which clips the string so that some javascript files won't load on the page. For now I've had to turn off wp-minify so IE users can see the syntax highlighting. This shouldn't affect most sites that only have a few javascript files, or only use one or two languages with the syntax highlighter.

GZIP Output

After doing everything else, I was still sitting at around 130K for a new visitor, with the blog's front page being the biggest remaining offender, sitting at around 80K of bandwidth. Since it's mostly text, it should compress really well, so I wanted to use gzip on it.

If your blog is on a server that supports PHP as a service, then it's trivial to add gzip compression to the .htaccess file. Mine isn't on such a server, so I had to include a header on every page, which is where the GZIP Output plugin comes in.

There's no configuration necessary, just install the plugin and your site is magically compressed. Apparently, gzip was an option in WordPress up to version 2.5, but it was removed because it's more efficient to have the server automatically perform the compression. That's true, but you need to be able to edit the server settings to be able to turn it on, and not everyone can do that.

The final verdict

Overall, I am very happy with the result. In my original post, new visitors to this blog were being treated to a nearly 700K download. After making the theme changes and installing the plugins I've detailed, I've been able to reduce the bandwidth consumption to a very pleasing 75K for a full refresh of the front page. That's nearly 1/10th the bandwidth consumption with little apparent difference in how the website looks.

blog comments powered by Disqus