Use WordPress Debug Stats to Trim the Fat from Your Blog

Word­Press, out of the box with­out any cus­tomiza­tions, is a pret­ty lean blog­ging engine. Pages load swift­ly, and servers hum right along, dish­ing out page after page of deli­cious con­tent to your users.

But who wants to use Word­Press out of the box? More often than not, you’re going to add plu­g­ins, select a bet­ter theme, and so on.

And why should­n’t you? Cus­tomiza­tions set your site apart from the pack, which is what you want!

These cus­tomiza­tions come with a price, how­ev­er: more code requires more time to process that code. And for many plu­g­ins and a grow­ing num­ber of Word­Press themes, there may also be more data­base queries. These can take even longer to process!

All of this pro­cess­ing time means that your users will have to wait that much longer for your con­tent to even begin to load. 

How do you know how many queries are being exe­cut­ed when a page is accessed on your blog? If you’re using most themes, you sim­ply need to view the source of var­i­ous pages of your site. Near the bot­tom, in your foot­er area, you’ll see some­thing like this:

<!-- 25 queries. 0.916 seconds. -->

Nifty, huh? That lit­tle snip­pet can usu­al­ly be found in your the­me’s footer.php file, and it looks like this before it is processed:

<!-- <?php echo get_num_queries(); ?> queries. <?php timer_stop(1); ?> seconds. -->

The num­ber of queries tells you how many times Word­Press had to inter­act with your data­base in order to get the required data to pro­duce your page. The time tells you how long it took your page to be cre­at­ed by the PHP engine, not how long it took to download.

I won’t pre­tend to be able to tell you what “good results” are. Is 17 queries good? Is 34 bad?

The truth is, every Web­site is going to have dif­fer­ent oper­at­ing tol­er­ances because there are thou­sands of dif­fer­ent hosts using hun­dreds of thou­sands of dif­fer­ent serv­er con­fig­u­ra­tions. What might be “high load” on one serv­er might not even cause anoth­er serv­er to sweat.

So how can you use these numbers?

Pri­mar­i­ly, they are an excel­lent indi­ca­tion of how your plu­g­ins are per­form­ing. For exam­ple, with­out much effort, you could prob­a­bly track down half a dozen plu­g­ins which list relat­ed posts for the cur­rent­ly viewed post. It requires a bit of time, but with the debug data in your foot­er, you could try out all of the plu­g­ins and find the one which adds the least amount of pro­cess­ing over­head to your site.

If you’re able to add func­tion­al­i­ty while still main­tain­ing a speedy site, your read­ers will be appre­cia­tive, and they’ll be less like­ly to click away from your site due to long load times.

Remem­ber: It does­n’t mat­ter how fast a user’s Inter­net con­nec­tion is, if a site takes a long time to process, it’s still going to be slow!

Now, I men­tioned the The­sis theme ear­li­er, but if you’re using it, how would you go about adding this debug info to your footer?

Here’s a lit­tle snip­pet of code you can add to your custom/custom_functions.php file which will out­put the debug info for the admin user only. This ver­sion of the code also omits the com­ment tags so that you don’t have to view the source of your page to see how it’s per­form­ing — it’ll be right there in your foot­er for you to eas­i­ly reference:

function footer_debug() {
	if (current_user_can('level_10')) {
		echo '<p>', get_num_queries(), ' queries. '; timer_stop(1); echo ' seconds.</p>';
	}
}
add_action('thesis_hook_footer', 'footer_debug', '99');

Once you’ve added the code, upload it to your site and vis­it your site to ensure every­thing is work­ing cor­rect­ly. View the site both while logged in and while logged out to make sure the debug infor­ma­tion only appears at the cor­rect time.

I hope that you’re able to use the debug infor­ma­tion to make your site even more lean & mean!