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:
- A client makes a request on your blog. This starts on the Apache level.
- Apache realizes that it’s a php script that has to be executed (index.php).
- Gives the PHP module the script as a parameter and kicks it off.
- Then, it’s WordPress’s time. It starts loading the core.
- On various steps of the process of rendering the requested page the plugins are loaded.
- 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.
- 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:
- Get the comments rendered using the wp_list_comments function.
- 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">
<?php wp_list_comments('type=comment'); ?>
<?php wp_list_comments('type=pings'); ?>
</ol>
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 foreach ($comments as $comment) : ?>
<?php $comment_type = get_comment_type(); ?>
<?php if($comment_type == 'comment') { ?>
<li>COMMENT RENDERING HERE</li>
<?php } else { ?>
<li><?php comment_author_link() ?></li>
<?php }?>
</ol>
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.
I think you’re going to get in trouble with the “it’s like a lady, elegant but slow” remark 😉
This is a great explanation though – thanks! I’ve heard of people who have over 50 plugins on their site – I can’t imagine having that many. I find, however, when working with clients there is trade-off between efficiency and plugins. If a plugin is easier then say uploading thumbnails and using custom fields the client is going to want to use the plugin.
The many layers with the global variable sounds like a theme we were discussing recently 😉
@Kim: Well that’s what plugins are for. Save you from trouble. But the balance is very elegant and keeping it is a very hard job indeed… Thanks for dropping by!
what do you think the ideal number of plugins should be? I use 15 in which almost 5 are useless.
What can we do if we want more functionality?
whoa!! scary picture! I do not want to disclose the number of plugins I use, but it is quite high. I re-evaluate each of them every week or so, but always feel that I can’t leave without them. The site performance gets the top priority, followed by functionality and aesthetics. I have managed to accommodate good traffic without exceeding my VPS resources more often than not.
@Prasanth: Comparing the number of plugins is not the indication you need. You might be using 50 plugins that make 10 queries in total and you might be using 5 that make 30 total. It all depends on the plugins you use. You would ask “how would i know?”. Well experiment deactivating and activating and see if the performance get’s a lot better. I might write a small article on how you can generally tell.
@Raju: As i said the number of plugins is not as important. The important thing is to closely monitor the performance of your site and as it turns out, you do. As for the picture, it wasn’t meant to be scary but now that i look at it again, it is kinda. Maybe it will make some people’s minds thinking 🙂
Hi stratosg, this is some refreshing information to read. I’ve been all over the blogosphere, and I see all kinds of articles about making your content efficient, but so many people forget to make their site’s code efficient. I’m not too sure how well I’m doing on mine, because I’m not an expert when it comes to code, but I do try to keep things as simple as I can without sacrificing the artistic merit that I want to keep. I look at other people’s blogs, and sometimes I’m baffled that they think they have a good thing going. And some blogs take FOREVER to load, even though a seemingly more complex blog takes a fraction of that time. Maybe this is why?
Interesting, my only problem is that I love my plugins. I’ve actually installed a cache plugin that is supposed to cache all your plugins thereby speeding things up a bit. As yet I haven’t configured them yet so I’m not sure how well it works.
Very good post.
Great post for simple understandings.
I have been using WP for a long time now and despite of being techy guy, I never thought in this perspective.
From my experience I can say that, one has to install 1 plugin at a time and evaluate its performance for a couple of days. This is helpful for someone like me who doesn’t have patience or knowledge to understand how efficient the plugin code is.
I totally understand you here. I myself are an efficiency and “find the most efficient way and algorithm to do it” freak.
You’re absolutely correct.
This is so true, we try to optimize the site and forget the real part of code efficiency! Thanks for this great explanation. 🙂
Great post…
The way you explained and took comments example was good. It shows that we need to take decision between easy coding / Performance based coding.