All of you out there that know me, know that i am an efficiency freak. Most of the times, when someone flashes a plugin to me, i stop and say “is that really necessary?” instead of “this looks cool!”. I know, it’s mostly annoying but you got to admit, i have a point. But, first things first. I will concentrate on WordPress, since, most of my readers are bloggers using the platform and many don’t really get why i nag all the time about performance and plugins. To give you a good taste of the complexity here is a small diagram.


This actually is a rough representation of what’s going on when a client request on your blog is in progress. Let’s take it one step at a time:

  1. A client makes a request on your blog. This starts on the Apache level.
  2. Apache realizes that it’s a php script that has to be executed (index.php).
  3. Gives the PHP module the script as a parameter and kicks it off.
  4. Then, it’s WordPress’s time. It starts loading the core.
  5. On various steps of the process of rendering the requested page the plugins are loaded.
  6. Just like a special plugin, the theme of the site is loaded as well. WordPress decides if it needs to load single.php for instance (when rendering a single post) or index.php (when rendering the homepage) etc.
  7. Each time a plugin or a theme wants to make a query it uses the wpdb global variable. This actually channels the query through WordPress, which channels it to the PHP module, which channels it to the PHP MySQL module, which channels it to MySQL server, which runs the query and creates the result set, which is finally channeled back all the way to the plugin.

Do you see how painful it is to make a query? Now take that and multiply it by 50-60 which is the average query count on a WordPress blog (not the default installation but an established one). You can see now how your memory and CPU get clogged up when a few requests come along together.

Let’s leave the general idea behind for a while and see an example to grasp the concept. I have looked around on what methods people use to seperate pingbacks/trackbacks from their comments. There are two ways to render the comments:

  1. Get the comments rendered using the wp_list_comments function.
  2. Query for them and get them on a variable, for instance $comments, and then render them with a foreach.

First one is a lot easier because it uses a built in function. Second one is a bit “harder” but it gives the coder more control over the rendering process. Now, let’s see how we could separate comments from pingbacks using each way.

Using the first way, we could call wp_list_comments twice with different parameters like that:

<ol class="commentlist">

Using the second way, we need to make to foreach loops filtering pingbacks on the first and vise versa for the second:

<ol class="commentlist">
<?php $comment_type = get_comment_type(); ?>
<?php } else { ?>
<?php }?>

What’s the con? The first one makes two queries! There is a pro in it, it uses the built in function to render the comments but still, two queries!

The point here is not this special case, but the general idea behind a bad coding practice. What i am trying to illustrate is the small things we all compromise (either when coding or when installing) and we end up piling up too many of those and having an extra slow site / blog. Focusing on WordPress, don’t forget it’s like a lady, elegant but slow. We all make the trade off between speed and making our life easier. But we shouldn’t forget that when we install a plugin. We are actually adding one more burden on the loading process. We shouldn’t forget that when we code either. We should be as efficient as possible since we are going to be messing around with other people’s blogs as well.

As a conclusion i would like to say once more, what i have said many times before. Try to keep your WordPress plugin needs to a minimum and, if you have some coding know how, check out the code yourself. It might save your from a lot of trouble.