Answer: when it’s a boat anchor!
WordPress with a ton of plugins can often become a bit of a slouch – even on snappy webservers… and I’ve seen it become downright boat-anchor on slower or heavily laden servers… so the search has always been on for ways to speed this sucker up…
Various caching systems have been employed – and they always seems contrary to the goal – why add more code to speed up the existing code…!?! arrgh…
so I found this – and it’s seemingly the answer…
http://www.canonicalseo.com/wordpress-performance-improvement/
The upshot is – the standard wordpress .htaccess looks like this…
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
and it’s not anywhere near as efficient as it could be…
however… this drop-in replacement….
# 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
you can shorten it to this… sans-comments…
# BEGIN WordPress
RewriteEngine on
RewriteBase /
RewriteCond $1 ^(index\.php)?$ [OR]
RewriteCond $1 \.(gif|jpg|css|js|ico)$ [NC,OR]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*)$ - [S=1]
RewriteRule . /index.php [L]
# END wordpress
By comparison – it’s a veritable Usain Bolt – p-ZiiIiing…..
Why is this so much faster than the really, not-so-different version above it??
The simple explanation is that it STOPS WORKING when it’s first condition is met for an image or other file that already exists, rather than loop back through and try again – and the existing code runs every rule repetitively, for every request…
To quote the OP:
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.
(I think I said it more concisely) 😉