Use WordPress Debug Stats to Trim the Fat from Your Blog

WordPress, out of the box without any customizations, is a pretty lean blogging engine. Pages load swiftly, and servers hum right along, dishing out page after page of delicious content to your users.

But who wants to use WordPress out of the box? More often than not, you’re going to add plugins, select a better theme, and so on.

And why shouldn’t you? Customizations set your site apart from the pack, which is what you want!

These customizations come with a price, however: more code requires more time to process that code. And for many plugins and a growing number of WordPress themes, there may also be more database queries. These can take even longer to process!

All of this processing time means that your users will have to wait that much longer for your content to even begin to load.

How do you know how many queries are being executed when a page is accessed on your blog? If you’re using most themes, you simply need to view the source of various pages of your site. Near the bottom, in your footer area, you’ll see something like this:

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

Nifty, huh? That little snippet can usually be found in your theme’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 number of queries tells you how many times WordPress had to interact with your database in order to get the required data to produce your page. The time tells you how long it took your page to be created by the PHP engine, not how long it took to download.

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

The truth is, every Website is going to have different operating tolerances because there are thousands of different hosts using hundreds of thousands of different server configurations. What might be “high load” on one server might not even cause another server to sweat.

So how can you use these numbers?

Primarily, they are an excellent indication of how your plugins are performing. For example, without much effort, you could probably track down half a dozen plugins which list related posts for the currently viewed post. It requires a bit of time, but with the debug data in your footer, you could try out all of the plugins and find the one which adds the least amount of processing overhead to your site.

If you’re able to add functionality while still maintaining a speedy site, your readers will be appreciative, and they’ll be less likely to click away from your site due to long load times.

Remember: It doesn’t matter how fast a user’s Internet connection is, if a site takes a long time to process, it’s still going to be slow!

Now, I mentioned the Thesis theme earlier, but if you’re using it, how would you go about adding this debug info to your footer?

Here’s a little snippet of code you can add to your custom/custom_functions.php file which will output the debug info for the admin user only. This version of the code also omits the comment tags so that you don’t have to view the source of your page to see how it’s performing — it’ll be right there in your footer for you to easily 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 visit your site to ensure everything is working correctly. View the site both while logged in and while logged out to make sure the debug information only appears at the correct time.

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

7 thoughts on “Use WordPress Debug Stats to Trim the Fat from Your Blog”

  1. Thanks for the comment, Mike. I should’ve mentioned in the post that one of the best ways I’ve come across to trim the query count while still using a variety of plugins is to use WP Widget Cache plugin.

    With the plugin, you may have widgets which hit the database with a handful of queries, but they’ll only be making those queries whenever the cache is invalidated or cleared — far less often than on every page load!

    Obviously, cache plugins which cache the entire page as opposed to just the widgets would do even more to help, but frankly, those are a pain to work with, in my opinion. I tweak a lot, and the cache has to be cleared after every tweak to get it to work properly; also, at least one plugin I’m using (Popularity Contest) wouldn’t do anything useful if it was cached.

    1. Rick, thanks for the tip on the WP Widget Cache plugin. I like to use a bunch a widgets, so I tried it on my pages and it reduced my database queries from 75 per page down to only 20 per page. Very nice.

  2. Hey Kelly,

    I just tested the “add debug information” in Openhook and it worked perfectly. However, you have to keep the WordPress back office open to see it.

    Every page in the back office has your blog’s title in the upper margin. If you go there and right click on the title, you can select “Open link in new window” or if your browser is newer, “Open link in new tab”. Either one will open the home page of your blog. Scroll down and you should see the information at the very bottom of your footer, probably in light gray font. I hope this helps.

  3. Thanks for the tip Rick.

    I just wanted to post a lil’ fix you need – and an advice for new programmers:
    Always use curly brackets on your if statements!

    In this case, if you are not logged in, you only see something like 0.345 seconds without an opening p tag. This happens because the semi-colon before timer_stop(1) closes the if, leading to undesired behaviors.

    Here is the fixed version:


    function footer_debug() {
    if (current_user_can('level_10'))
    {
    echo ''.get_num_queries().' queries. '; timer_stop(1); echo ' seconds.';
    }
    }
    add_action('thesis_hook_after_footer', 'footer_debug', '99');

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

the Rick Beckman archive
Scroll to Top