WordPress Performance: Speed Up a Slow WordPress!

by Canonical SEO on January 12, 2010

WordPress Performance Improvements

I have become increasingly concerned with the performance of WordPress on my site recently since Google announced that they have been considering adding page load time as a ranking factor in their algorithm.  WordPress performance is also an issue because I am getting more visitors to my site, so its an issue from a usability perspective as well.
I started out looking at caching plugins like WP Cache and WP Super Cache.  But each time I read something good about one of them, I seemed to find almost as many posts about issues people are having with them.  I try to keep my plugins to an absolute minimum to minimize problems with upgrading WordPress and Thesis, my premium WordPress theme.  For these reasons I have been hesitant to try any of these caching plugins.

The following is an easy way for many WordPress sites to achieve noticeable gains in site performance instantly without installing a WordPress caching plugin.

Improving WordPress performance with changes to .htaccess

Yesterday while trolling WebmasterWorld.com I stumbled onto a thread that caught my attention.  It was related to WordPress. Though the original post started out about a problem someone was having with the default WordPress .htaccess and had nothing to do with WordPress performance, it eventually evolved into such a discussion.

 As the thread evolved, Jim Morgan (jdmorgan) eventually responded to the post with a simple, but elegant solution to help realize WordPress performance improvements with almost no effort.  For those that don’t know, Jim Morgan is a Mod_Rewrite and .htaccess god as far as I’m concerned.  I learn so much each time I read one of his posts there about rewriting on Apache.

The solution proposed by jdmorgan involves optimizing the Mod_Rewrite code that WordPress places in your web’s root folder .htaccess file by default.  When you install WordPress, the following directives get added to the .htaccess file located in your web site’s root folder:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

The suggested optimization from jdmorgan was to replace the above code with the following:

# BEGIN WordPress
RewriteEngine on
# Unless you have set a different RewriteBase preceding this
# point, you may delete or comment-out the following
# RewriteBase directive:
RewriteBase /
# if this request is for "/" or has already been rewritten to WP
RewriteCond $1 ^(index\.php)?$ [OR]
# or if request is for image, css, or js file
RewriteCond $1 \.(gif|jpg|css|js|ico)$ [NC,OR]
# or if URL resolves to existing file
RewriteCond %{REQUEST_FILENAME} -f [OR]
# or if URL resolves to existing directory
RewriteCond %{REQUEST_FILENAME} -d
# then skip the rewrite to WP
RewriteRule ^(.*)$ - [S=1]
# else rewrite the request to WP
RewriteRule . /index.php [L]
# END wordpress

How does this improve WordPress performance?

At first glance you might wonder how this could possibly make a difference in how WordPress performs.  There is more code there than exists in the previous default solution.  But it does improve WordPress performance in several ways.

It should be noted that in the context of .htaccess (not httpd.conf), anytime at least one RewriteRule in a .htaccess file is invoked because all conditions associated with it are met, .htaccess rule processing is restarted (i.e. it triggers another pass through the .htaccess file) regardless of whether the ‘L’ flag is used or not.  The ‘L’ flag on a RewriteRule that is successfully invoked simply causes Mod_Rewrite to restart the .htaccess rule processing immediately rather than processing additional rules in the file before restarting.  The only time Mod_Rewrite does not restart .htaccess rule processing is if it makes it all the way through the .htaccess file and no RewriteRule in the file gets invoked.

The default WordPress .htaccess code is inefficient, particularly the RewriteCond statements that check to see if the requested filename is NOT an actual file that exists on the file system and that the requested filename is also NOT an actual directory that exists on the file system.  Depending on how the web server is configured and the amount of traffic it gets, this information might not be cached by the OS and often leads to physical disk reads to make the determination, especially in shared hosting environments.  And using the default .htaccess code installed by WordPress, both the file check and directory check get executed 2 times each (4 disk reads in all) for each WordPress page requested due to the restarting that I mentioned in the previous paragraph.  This can be VERY inefficient.

The new code suggested by jdmorgan avoids the unnecessary 2nd check for an existence of a file or directory with the requested URL any time a ‘/’ is requested or the original requested URL has already been rewritten to WordPress’ /index.php.   This cuts in half the biggest overhead of the original default WordPress .htaccess code – the file and directory checks.  This will have a noticeable affect to WordPress performance on most sites.

Jim Morgans suggested .htaccess code also avoids ANY checking for file or directory existence (i.e. it avoids all 4 checks) when and image, JavaScript, or CSS file is requested since it shortcircuits the RewriteRule if an image, JavaScript, or CSS file is requested.  This is another brilliant optimization IMO since all requests for these file types only make one pass through the .htaccess file since no RewriteRules will get successfully invoked for them because of the flag [S=1] used. 

Jim’s solution even eliminates the unnecessary <ifmodule> check.

Check your WordPress performance before and after

Replace the default WordPress code with Jim’s suggested optimization in your root .htaccess file and see if you notice any performance improvements. My guess is that if your pages are not already rendering in 1-3 seconds, you will notice a significant WordPress performance improvement.  My pages which were loading in 4-8 seconds appear to be loading in 1-3 seconds now.  IMO this is a huge difference.

Thanks to jdmorgan at Webmaster World for posting a great solution to help ALL webmasters improve their site’s WordPress performance with practically no effort.  He deserves all the credit.  I’m just passing on his solution.

{ 19 comments… read them below or add one }

Leave a Comment

Previous post:

Next post: