WordPress Performance
If you're serving a busy site using WordPress, you should pay attention to how quickly your copy of WordPress runs. By spending a little time “tweaking” WordPress, you can dramatically affect how fast it runs (and therefore how many visitors it can handle).
This page describes techniques for speeding up WordPress, including FastCGI and WP Super Cache. To show you what a difference these can make, here are some rough performance testing results on our servers for an “out of the box” WordPress installation:
- Standard WordPress installation: 2 page views per second
- WordPress with FastCGI enabled: 8 page views per second
- WordPress with WP Super Cache enabled: 500 or more page views per second for cached files
In other words, using these techniques allows your site to handle well over 200 times as many visitors per second.
To get the full benefit, you do need both FastCGI and WP Super Cache. That's because WP Super Cache only speeds up “cached” pages, and pages won't always be cached. If they aren't cached, they load at the slower speed of either 2 or 8 per second, and you definitely want that to be as fast as possible.
On this page:
- Enable FastCGI
- Install WP Super Cache
- Avoid slow plugins, especially “WP Spam Free”
- Avoid unnecessary plugins
- Use real files for "favicon.ico", "robots.txt", etc.
- Don’t run WordPress for missing images
- Use appropriate caching and compression
- See where it's still slow
- Use WP Tuner to find performance problems
- Can all this really help that much in the "real world"?
Enable FastCGI
Using FastCGI for PHP scripts allows the script to stay preloaded in memory, waiting for a page request. This eliminates the normal PHP startup time (which can be as much as half a second per request).
We have detailed technical instructions about enabling FastCGI for your account on our FastCGI page, but note that you don't need to do it yourself: just contact us and we'll be glad to do it for you at no charge.
Install WP Super Cache
WP Super Cache sends the same page to multiple visitors (if it hasn't changed) without running the same WordPress script code every time. This vastly speeds up loading times for pages that are viewed by multiple people.
Installing this free plugin is the biggest performance improvement you can make.
We have simple instructions explaining how to install the plugin on our WP Super Cache page (and again, we'll be glad to install it for you if you prefer).
Avoid slow plugins, especially “WP Spam Free”
The idea of WP Super Cache is that for most requests, there is no PHP code that needs to be executed on the server.
However, a small number of WordPress plugins add JavaScript that loads an extra non-cached PHP script for each page view. This defeats the purpose of WP Super Cache.
We strongly recommend avoiding plugins that operate this way. Some that we know of are:
- WP Spam Free (the reCAPTCHA WordPress Plugin is a good alternative)
- WP Ajax Edit Comments
- Tabbed Widgets
- WordPress Popular Posts
- Featured Content Gallery
In addition, you should not use any plugin that contains this line of PHP code:
$wp_rewrite->flush_rules
This causes (potentially large) MySQL database updates for every page viewed, slowing down WordPress dramatically. One such plugin is Sitemap Generator For WordPress MU.
Avoid unnecessary plugins
Every plugin you enable makes WordPress a little slower. Some resource-intensive plugins make WordPress much slower.
We almost never hear complaints about the speed of WordPress sites that don't use many plugins. Speed only becomes a problem when sites use lots of plugins. We've seen several sites that run more than ten times slower than a standard WordPress installation because of the plugins they use.
If you care about the speed of your site, don't use plugins you don't need, and test every plugin individually to see how much it slows down your site.
Use real files for "favicon.ico", "robots.txt", etc.
If a visitor requests a file that doesn't exist, WordPress displays a useful "file not found" page that includes similar pages, links, and so on. However, that page takes time to generate.
In some cases, it's normal for a file to not exist. In particular, many browsers and search engines request files named "favicon.ico" and "robots.txt", and some Apple devices like the iPhone request files named "apple-touch-icon.png" and "apple-touch-icon-precomposed.png".
When those files don't exist, your site still works properly, so the missing files don't cause visible problems. However, these requests use valuable WordPress processing power to construct the custom "file not found" page, and that effort is completely wasted: no human ever sees the page WordPress creates.
The best and simplest solution is to make sure these files aren't missing. Create a "favicon.ico" file and add "robots.txt", "apple-touch-icon.png" and "apple-touch-icon-precomposed.png" files. The robots.txt file can be completely empty if you want.
Alternately, you may want to add this line to your .htaccess file, just before the existing WordPress "RewriteCond %{REQUEST_FILENAME} !-f" line:
RewriteCond %{REQUEST_URI} !^/(apple-touch-icon.png|apple-touch-icon-precomposed.png|crossdomain.xml|favicon.ico|robots.txt)$
That line prevents the custom WordPress 404 PHP code from running when several common "non-human" requests are made for missing files.
Don’t run WordPress for missing images
As discussed in the above section, WordPress will run and generate a custom “file not found” page when a request comes in for a missing file.
If you are not using WordPress MU (or the “network of sites” feature in WordPress 3), then you can configure your Web site to have Apache immediately return a standard 404 error code when a missing image file is requested (rather than having WordPress run). To do so, add this line to your .htaccess file, before the existing WordPress "RewriteCond %{REQUEST_FILENAME} !-f" line:
RewriteCond %{REQUEST_URI} !\.(jpg|jpeg|png|gif|ico|swf|bmp)$ [nocase]
This line can be used in addition to the RewriteCond line given in the “Use real files for ‘favicon.ico’, ‘robots.txt’, etc.” section above.
Again, be sure not to use this RewriteCond if your blog uses WordPress MU or the “network of sites” feature of WordPress 3, or if your .htaccess file contains any line like either of these lines:
RewriteRule ^(.*/)?files/(.*) wp-includes/blogs.php?file=$2 [L] RewriteRule ^(.*/)?files/(.*) wp-includes/ms-files.php?file=$2 [L]
Use appropriate caching and compression
If your site uses many external image files, JavaScript files or CSS stylesheet files, set up appropriate caching and compression rules for those files.
See where it's still slow
After doing everything above, use a tool like WebPageTest, Google Page Speed or Yahoo! YSlow to see what part of your site is slow.
If you find that most of the time is spent on connections to external sites other than your own, try to eliminate as many of those connections as possible.
Use WP Tuner to find performance problems
If the test above shows that the very first connection to your site is slow, try installing the WP Tuner plugin to get detailed statistics about your WordPress installation. Among other things, it can show you which plugins are slowing down your site.
Can all this really help that much in the "real world"?
Yes. We have several customers using FastCGI and WP Super Cache who have easily “survived” having their WordPress site listed on the Digg home page, with sustained page view rates of 20-30 pages per second for several hours, even on our most basic Web hosting plan.
Advanced users can use the shell command line to test their own results with the ApacheBench program. Here's a real result from our own blog with WP Super Cache installed:
$ /usr/sbin/ab -n 40 -c 4 http://blog.tigertech.net/ Concurrency Level: 4 Time taken for tests: 0.31100 seconds Complete requests: 40 Failed requests: 0 Write errors: 0 Total transferred: 1849520 bytes HTML transferred: 1836800 bytes Requests per second: 1286.17 [#/sec] (mean) Time per request: 3.110 [ ms ] (mean) Time per request: 0.777 [ ms ] (mean, across all concurrent requests)
In this case, our servers delivered over 1200 page views per second. Real world results won't be that fast because of networking overhead, but it does show that the WordPress software is not a bottleneck at all in this situation.
