WordPress Optimization Myth: Saving Database Calls

Tonight I read an article on WPTuts+ titled 10 Quick Tips: Optimizing & Speeding Up Your WordPress Site. For the most part it’s a good article with lots of great tips, but there is one tip which is just plain incorrect:

Using a constant instead of get_option('home'); saves a database call.

I left a comment there (still in moderation) and normally I would have moved on. However, this is not the first time I’ve read articles which mistakenly promise a performance gain from this tip. If I had a dollar for everytime I’ve read an article saying to not use get_option, I’d have.. well probably only the better part of 50 dollars, but that’s still way too much!

I felt I had to write this article to debunk the myth.

The tip in question is number 3, “Declare a Constant for Most Used WordPress Database Values”, which states (bold mine):

This can be useful for the theme developer to reduce the number of database query on database. As a being WordPress theme developer we need to use some WordPress function which we need to use most frequently and more than once in a page.

For example, to get the url of the home page we generally use the get_option('home');. This function actually perform the query on database and get the value we want. As we know this will be same for all cases and we might need this value on various places.

The author goes on to propose creating a constant in the wp-config.php file, then finishes with:

After declaring this constant you need to use this constant instead of the get_option('home') or similar function. So this will reduce the number query in the page. You can define constants for template directory too.

Leaving aside the fact that you could use the home_url or site_url functions instead of get_option('home'), it’s just plain wrong to state that it uses a database call.

The home option, and many others, are autoloaded on each page load. It doesn’t matter whether you use the option or not, WordPress gets it from the database (if the autoload column is set to yes). Take a look at the following screenshot of the options table in my development instance of WordPress, noting that the autoload column is set to yes for home:

For anyone who’s interested in what happens and the code behind this, check out the wp_load_alloptions function. You’ll see it effectively does one database call to load all the options where autoload equals yes.

As a result, the home option is loaded on every page load whether you use get_option('home') or not. When you do use get_option('home'), it doesn’t access the database, it simply gets the home value from the already loaded array of options. No performance gain!

So, this technique does not save a database call. Most of the template tags that you might use relating to the path of the site etc, are autoloaded, including the template directory and blog name.

Also, note that all options added by plugins are autoloaded, unless the plugin authors have specifically said not to autoload them. I used to do things like load my plugin’s options into a global variable and access it that way instead of using get_option, which I mistakenly thought was hitting the database.

I don’t blame the author of the article. This is a myth that perpetuates because so many people have written about it before. I actually used to do this way back in 2007 and although I never wrote a post about it, I’m sure I left comments around about what a great technique it was! I was quite surprised when I learnt the truth in about 2009.

Tags: optimisation, performance, WordPress