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]
</IfModule>
# 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 }

James January 13, 2010 at 6:27 am

This sounds great. Whenever I look up information on any aspect of htaccess, Jim Morgan has the solution!

It would probably also be worth enabling mod_deflate or mod_gzip from within the htaccess file in order to compress things like html, css and js without having to use a plugin. This can reduce the amount of data travelling back and forth by quite a lot in some cases.

Alizio January 14, 2010 at 6:55 am

The code works, I saw a small improvement of the speed. on my blog. What I ask myself is why the Wordpress engineers didn’t used this solution by default.

Canonical SEO January 18, 2010 at 9:42 am

Likely because they are not Mod_Rewrite experts. They are concerned more with WordPress app itself, and likely spent no time working on the .htaccess.

The size of the improvement likely depends on whether you already have a caching plugin installed or not. I do NOT have any caching plugins… which might explain the big gains that I saw.

Vi Wickam February 3, 2010 at 6:04 pm

Thanks for the insightful post. I have a bunch of wordpress sites, and implementing this could positively effect our server loads.

Thanksa again!

Vi

Rich Cook March 30, 2010 at 5:56 pm

I’ve been getting intermittent 500 Internal Server Errors that most sources seem to think is related to a corrupt .htacess file. It happens regardless of what page is trying to load, on the live site and in the WP admin area. I’m going to try & insert this code to see if it corrects the corrupted file & fixes my prob. My pages load slowly, too, at least lately…for about a month. It’s not a large site nor do I have large files. I don’t know what originally caused the error but hopefully this will fix it. If not, I’m tracking down Jim Morgan for help!

Craig Sunney April 2, 2010 at 1:09 pm

Hey.
My non scientific counting method, I counted 4 elephants for a page to load….now its down to two with this. It works!

(“1 elephant” = old darkroom photography printing way of counting exposure in seconds). Bookmarked & tweeted :)

RT Cunningham April 2, 2010 at 6:44 pm

If you ever decide to re-investigate caching plugins, I recommend Quick Cache without reservation. I use it on several blogs and it does what the others cannot.

I also cache opcodes with APC and use mod_deflate on the server (VPS). The only slow pages on my blogs are the pages that haven’t been viewed within the last hour. Everything else is as fast as a static page can be.

And yes, I’ve changed my mod_rewrite rules. Not quite like yours, but still better than what WP installs.

Paul Rohde April 3, 2010 at 12:12 am

Thanks! I definitely noticed some significant improvements on the initial page load, especially since my site is media heavy, take that potential 4 disk reads and multiply it by 20 individual files between the the css, javascript, and the images that makeup the theme.

Many thanks for going into the details of how and where these optimizations can be made!

Kate May 13, 2010 at 11:04 am

I’m relatively new to Wordpress (hereafter wp) and have noticed a bit of a slower loading process since changing out my header photo. Can this code be used in wp.com or just in wp.org? I’m on wp.com. Thanks.

Aadi May 29, 2010 at 8:53 am

Gr8, this works.l. There’s a noticeable difference in loading times. My server drops connections when there are too many visitors to the site. I wonder if this solution wud help cos I assume the server load will decrease.

Michael Keizer May 31, 2010 at 7:48 pm

Note that if your WordPress installation is not in your root, you will have to adjust the code a bit. Assuming that your blog is installed in the subdirectory “sub”, it will look like this:
# 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 /sub/
#
# 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 . /sub/index.php [L]
#
# END wordpress

And yes, it shaved off about 20% of the load time of most of my posts and pages. Thanks!

Hubert Bancroft June 2, 2010 at 2:54 pm

I’ve been experiencing terrible problems with my site being slow to load ever since I upgraded to wp 2.9.2. The best solution I have found so far has been W3 Total Cache but I am also trying other methods/plugins as well. I included this code in place of the wp standard inclusion but, in all honesty, it didn’t improve the loading time. HOWEVER, as has been mentioned earlier, this is probably due to there already being a cache plugin installed.

rashmi June 4, 2010 at 10:59 am

Thanks for the solution…I have a lot of wordpress running site I am eager to try this

Eber June 20, 2010 at 8:53 pm

Hello,

I have a very big car blog here in Brazil and saw a significant improvement in the loading time.

As I already had done some changes to improve the loading time, as using WP Super Cache, WP Minify, etc, now it is loading very quickly.

Thanks

Alex July 8, 2010 at 7:01 am

Great stuff. I got a little improvement. – from 75 to 78 in the Firebug’s Page Speed numbers. Thanks!

Canonical SEO August 4, 2010 at 2:09 pm

I’m 99% sure you cannot use this on WordPress.com. You would need access to the .htaccess file in the root folder of you blog, and I’m pretty sure they don’t give you that.

Jeff C October 11, 2010 at 12:21 pm

Great tip – made the suggested changes to our .htaccess and the speed improvement was very significant. Thanks!

berny February 11, 2011 at 9:10 pm

Thanks for this tip. :)

Btw. the exclusion of static files should also include all your provided file-types like pdf or swf to minimize disk reads.

greetz,
berny

Juan December 1, 2011 at 2:08 pm

Thanks! My page would take about 7-20 seconds to load in google chrome. Now it’s about 1.5 seconds!

I can’t believe it!

Leave a Comment

Previous post:

Next post: