Post Theme: Blog Overhaul.

I started off yesterday by taking another look at how efficient my blog was using its resources. Now I’m not going to say that I think this is the most important part of the process, as its not in itself going to get more readers. However, things like loading times and database usage can be important to the user experience. How many times have you clicked onto a blog, only to have it take forever to load, and turn away?

A lot of the top bloggers don’t actually pay much attention to this. Take a look at the stats and you’ll see what I mean. I’d actually meant to do a post on the issue myself a few weeks back, but PimpMyPageRank.com did a really nice job on compiling all the data.

Many of those listed have sites that would take well over 10 seconds to load (on a broadband connection), and whilst internet connections are getting faster, a slow loading and bloated site could be a problem if you’re not a guru! My own stats are actually pretty good, since I try to keep load times down to a minimum. I use many of the techniques I listed here to achieve that, from content compression to static caching. If you haven’t already, I suggest checking that list out.

Page Load Size:

Let’s have a look at my blog in its current state. Be aware that I’m half-way through the design / layout alterations right now, so things may change slightly. The front page is the most “busy” page of my blog, as it now houses a video and games selection.

I use a combination of FireFox and FireBug to view exactly what is downloaded when a webpage loads, the total size of the page, and how long it takes to load on my internet connection. I suggest downloading those tools if you want to profile your own blog.

What we are looking for is the number of items being downloaded, any particularly large items, and the total size of the page. It is best to use an F5 refresh to see what loads without browser caching interfering:

  • Total Requests: 25
  • Total Page Size: 47kb
  • Total Load Time: 1.3s

Bear in mind that the load time largely depends on your own connection, which in my case is a 1536kbps. The largest item is the header banner, at 14kb. The item that took longest to load (which is why its located in the footer) was the external wordpress stats javascript. I’m happy enough with that. It also puts me at the very end of the stats list reference above!

A mistake a lot of bloggers make is to have every widget under the sun on their blog. That loads external files, often through javascript, which is slow. Choose the ones that are really of benefit, and ditch the rest. I have yet to add any external widgets, but they will be used sparingly.

To get around delays in the games or videos loading, I have instead loaded static images in their place. When clicked, the appropriate item will be loaded. This helps to reduce load size, and only loads big expensive files when the user wants them. Also, if you encounter any large images, you may want to try and reduce their size through photoshop, or some other image utility.

Database Queries:

Now that you’ve pruned your blog’s load times, you can turn your attention to the database. Whilst it doesn’t usually directly affect load times, if you have a sudden burst of traffic, it always helps to have the database hit as few times as possible.

You can always decide to skip this part, and just go straight to installing WP Cache (which avoids the database alltogether).

Wordpress isn’t the best at minimising query usage, especially when you use a lot of plugins. Make sure you keep updated with the latest versions, and from time to time, you can also look through the list of active plugins and remove any you don’t really use or need. For example, I currently have 20 plugins active, and have recently remove 6 I didn’t properly use.

I wouldn’t advise that most people try to alter the core of wordpress too much (since it makes upgrades harder), but there is one tip that I have been experimenting with on this blog, and I have yet to see anywhere else. It is often the case that wordpress churns out some duplicate queries. If we were to store the results of queries on a page load, then duplicates could be eliminated, by using the stored version.

Explanation below gets a little technical if you don’t know php, so don’t worry too much about it, unless you are curious.

This has so far saved me anywhere from 1 to 5 queries per page. It requires alterations to several functions within the file wp-includes/wp-db.php. We will use a global variable called $query_cache to identify and store queries once they have been used once. We will then check future queries, and see if it has already been stored, using a unique md5 hash.

I’ve zipped up the modified wp-db.php file here, which you can place in your wp-includes folder. Be aware that it is for wordpress 2.3, and I don’t know whether it would be compatible with older versions. Therefore, here is quick demonstration of what is happening:

function get_row($query = null, $output = OBJECT, $y = 0) {
global $query_cache;
//create md5 hash identifier
$query_md5 = md5($query);
//check if query has already been cached on page load
if(isset($query_cache[1][$query_md5]) && $query != null) {
$res = $query_cache[1][$query_md5];
} else {
//normal querying process would go here
//$res = ‘normal processes’;
//cache query result in case its needed later
$query_cache[1][$query_md5] = $res;
}
return $res;
}

I’ve used the function get_row() as an example, but the same would need to be done to get_var(), get_results(), and get_col() too. Since in theory the same query could be run through each of these functions on a load, the $query_cache variable is used in the format - $query_cache[$func_num][$md5_hash] - where $func_num can represent a unique number for the particulat function being modified, and $md5_hash is the unique query hash.

Conclusions:

My blog is now happily sitting at 15 - 25 queries per page load when no file caching is used, and under 50kb load total (although likely to go up to once the ‘take a break’ games section is finished). Whilst making your blog lean should not be the only thing you consider - it’s always a trade off with functionality - I still believe that it is a good idea to trim things down wherever possible.

In my next post on this theme, I’ll still be looking at things from a usability perspective, but this time focused on design, navigation, and internal linking structure. Until next time!