IDEA: Change the inefficient default .htaccess code that is added to each installaltion's root folder .htaccess file by WordPress to a MUCH more efficient piece of code.
Page load times in WordPress are likely going to become more and more important since Google is considering using page load times as a ranking factor in Caffeine. Some think it's already built into their new ranking algorithm. Page load times are already important since they affect usability of a site.
I discovered yesterday that at least half of my page load times appear to be due to the inefficient RewriteRule that WordPress adds to the root folder's .htaccess file which is as follows:
# BEGIN WordPress<br />
<IfModule mod_rewrite.c><br />
RewriteEngine On<br />
RewriteBase /<br />
RewriteCond %{REQUEST_FILENAME} !-f<br />
RewriteCond %{REQUEST_FILENAME} !-d<br />
RewriteRule . /index.php [L]<br />
</IfModule><br />
# END WordPress<br />There are several inefficiencies in this code. But it is the RewriteCond directives that check that the requested filename is NOT a file on disk AND that the requested filename is NOT a directory on disk that is most inefficient.
On most web servers in a shared hosting environment or even dedicated properly configured servers with lots of traffic, the two statements often result in two reads from disk since the info gets kicked out of the cache. This is SLOOOOOOOW. Disk reads are BAAAAAAD. It's actually worst because each page request on a WordPress site now triggers two passes through the .htaccess and the two statements end up getting evaluated twice for a potential total of four disk reads.
Yesterday I discovered a post on Webmaster World by Jim Morgan who is a Mod_Rewrite/.htaccess guru if ever there was one. I have never met or seen online another person who knows more about Mod_Rewrite than him. He suggested replacing the above with the following:
# BEGIN WordPress<br />
RewriteEngine on<br />
#<br />
# Unless you have set a different RewriteBase preceding this<br />
# point, you may delete or comment-out the following<br />
# RewriteBase directive:<br />
RewriteBase /<br />
#<br />
# if this request is for "/" or has already been rewritten to WP<br />
RewriteCond $1 ^(index\.php)?$ [OR]<br />
# or if request is for image, css, or js file<br />
RewriteCond $1 \.(gif|jpg|css|js|ico)$ [NC,OR]<br />
# or if URL resolves to existing file<br />
RewriteCond %{REQUEST_FILENAME} -f [OR]<br />
# or if URL resolves to existing directory<br />
RewriteCond %{REQUEST_FILENAME} -d<br />
# then skip the rewrite to WP<br />
RewriteRule ^(.*)$ - [S=1]<br />
# else rewrite the request to WP<br />
RewriteRule . /index.php [L]<br />
#<br />
# END wordpress<br />When I walk through them, the two are logically equivalent in their results, but Jim Morgans is MUCH more efficent. Jim is old school knows Mod_Rewrite inside and out... He writes probalby the most efficient and thorough .htaccess files of anyone I've ever seen.
Well to make a long story short, rather than always checking for file or directories matching the request filename on BOTH passes through the .htaccess, Jim's version shortcuts the process when it can and the WordPress performance gains are shocking... in a good way!
If someone requests the home page like example.com/ then there is no reason to rewrite to index.php. The index.php will be invoked automatically since it should be the default document. So no need to check to see if the requested filename is a file or directory on the first pass through the .htaccess... and no need to make a second pass through the .htaccess. This potentially saves 4 disk reads when someone requests just the home page without the default document (example.com or example.com/).
If the requested filename is /index.php then it's already been rewritten (or in rare cases possibly example.com/index.php was requested directly) so there's no need to perform the file and directory checks on the second pass through the .htaccess... so this saves potentially 2 disk reads.
If the file being requested is a frequently requested NON-WP file type like images (.jpg, .gif, .ico, or whatever you use a lot - these should cover the most often requested), CSS, or JavaScript files then these should all be pulled from disk so there is no need to look to see if the requested filename is a file or directory on disk. So Jim's code shortcircuits again avoiding 4 costly unnecessary disk reads.
He also removed <ifmodule mod_rewrite.c> directive. He says it's unnecessary and actually sometimes problematic. If he says it, it must be so! LOL
BOTTOMLINE: I placed this code on my site and it instantly cut my page load times from 4-8 seconds per page (and typically on the high end of that) down to 1-3 seconds per page and EVERYTHING on my site works as it did before. I have yet to find a problem with anything related to the change. It was a HUGE WordPress Performance improvement... and it didn't require me adding yet another plugin like WP Cache or WP Super Cache and inheriting the various problems that using those entail.
NOTE: I do NOT use any caching plugins. The only plugins my site uses is Akismet, Contact Form 7, and Really Simple CAPTCHA. I avoid plugins for several reasons.
If you want more details for considering this change, please read my post about WordPress Performance. It gives even more details than I have typed here.
I would be curious to find out if this helps other WP users (especially those in a shared hosting environment or highly trafficed blogs).
night2008 
