WordPress Performance

This page is showing a generic answer.
To see a more detailed answer customized for you, type your domain name here:

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 WP Super Cache. Applying these techniques will speed up an average “out of the box” WordPress installation from about four page views per second to well over 100 page views per second.

On this page:

Make sure you’re using at least PHP 5.6, and preferably PHP 7.0 or later

If you use PHP version 5.6 or later, a precompiled “cached” version of your script can be used, making your site load much faster.

If your scripts are compatible with PHP 7 (most properly updated WordPress sites are), you can speed it up much more by choosing that option — it can be almost twice as fast.

You can choose your PHP version using the “My Account” control panel. We recommend using the newest version of PHP that works with your site.

Install the WP Super Cache plugin

WP Super Cache sends the same page to multiple visitors 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 we’ll be glad to install it for you if you prefer).

If you’ve already installed WP Super Cache but the load is still high, be sure you’re using the recommended settings we show on that our page.

In addition, be sure you don’t use any plugins that make WP Super Cache unable to cache many of your pages. Certain plugins that show “mobile” visitors a different version of your site operate this way: make sure that any “mobile” plugins you use are compatible with WP Super Cache. (Note that one of the most popular, “WPtouch Pro”, is not compatible, although the free version, called just “WPtouch”, is.)

Finally, some people choose to use a different caching plugin called W3 Total Cache. We don’t recommend that (we’ve seen many problems with it), but if you do use it, be sure to configure it properly.

Avoid slow plugins

The idea of WP Super Cache and other caching plugins is that for most requests, there is no PHP script code that needs to be run on the server.

However, a small number of WordPress plugins add an extra non-cached PHP script for each page view. This defeats the purpose of adding caching to your site.

If you have a busy site, we strongly recommend avoiding plugins that operate this way. Some that we know of are:

Many other “related post” or “popular post” plugins and themes do this, too.

In addition, avoid plugins that perform extremely inefficient database queries, including:

  • Google XML Sitemaps (causes “503 errors” and timeouts with large numbers of posts if you use any of the “Excluded Items” options, but is usually okay if you don’t use any “Excluded Items” or if you have fewer than a couple of hundred posts )
  • WP-DBManager set to automatically “optimize” a large database, which can be very slow and generate “503 errors”
  • WP-PostViews

Finally, 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 sites that run more than fifty 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.

If you use the “WordPress Popular Posts” plugin, enable data sampling

WordPress Popular Posts is a widely used plugin, but according to the plugin’s documentation, it can cause problems on high-traffic sites: it “stores every single visit you get on the database. For small / medium sites this is fine, but on high-traffic sites this may cause performance issues”. In practice, we’ve found that it can completely overwhelm a site’s database.

To avoid this, the plugin offers a feature called data sampling that should be enabled on any potentially busy site. Their page about performance explains how to enable it; leave the sampling rate set to 100.

(It will also help to enable the “caching” option described on that page, although it has less impact than data sampling.)

If you use the “Disqus” plugin, disable automated comment importing

A popular plugin called Disqus can improve the way comments appear with WordPress. However, it has an optional feature to “automatically sync comments” that, when used, sends an uncacheable request to the server on every page view. On a very busy site, this request will use more resources than everything else combined, eventually causing the site to stop working.

To avoid this, you should “Disable automated comment importing” as described towards the bottom of this Disqus help page, and occasionally sync the comments manually instead.

Alternately, you can use this .htaccess trick to make only 1/60th of these requests reach WordPress, which is perfectly sufficient to sync the comments every few minutes without overwhelming the server:

RewriteEngine On
RewriteCond %{TIME_SEC} !30
RewriteCond %{QUERY_STRING} cf_action=sync_comments
RewriteRule .* - [forbidden,last]

We’ll be glad to set this up for you if you wish; just contact us.

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.

Don’t run WordPress for missing images

The WordPress script will run and generate a custom “file not found” page whenever it receives a request for a URL that doesn’t exist as a file on the server.

This is useful when the “missing URL” is one of your pages — in fact, this is how WordPress permalinks work. It’s not useful, though, if the missing URL is for an image file you’ve forgotten to upload or that you’ve removed. If the browser requests a PNG file but receives a WordPress “404 not found” HTML page instead, nobody will actually see it, and the resources the script consumed to generate the 404 page are wasted.

To avoid this problem, you can configure your Web site to immediately return a standard 404 error code when a missing image file is requested (rather than having WordPress run).

If you use our WordPress one-click installer, the rules below are automatically added by default to new sites as of February 2017, as long as you didn’t already have a .htaccess file. If you installed WordPress manually, or used our installer before then, you can add the rules yourself (or ask us to do so).

To add these rules on a site that is not using the WordPress “network of sites/WordPress MU” feature, add these three lines to your .htaccess file, before the existing “# BEGIN WordPress” section:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule \.(jpg|jpeg|png|gif|ico|swf|bmp)$ - [nocase,redirect=404,last]

Don’t put those lines above the whole WordPress section if your site uses the WordPress “network of sites/WordPress MU” feature, though. That feature relies on other parts of the .htaccess rules “fixing” the path to missing images, so the exact location of the lines matters.

For a site that uses the WordPress “network of sites” feature, you can instead add these two lines just before the existing “RewriteRule . index.php [L]” line:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule \.(jpg|jpeg|png|gif|ico|swf|bmp)$ - [nocase,redirect=404,last]

The two lines must be in exactly the right place, so be careful to only put them immediately before the “RewriteRule . index.php [L]” line if you’re using a “network of sites”.

Make sure you don’t have any “404 Not Found” URLs

Every “404 Not Found” URL uses significant resources to show a custom WordPress 404 page to the visitor. Check your error logs to be sure your site isn’t generating 404 errors.

Prevent search engines from indexing threaded comments

If your site gets a large number of comments, you may find that search engines try to index many URLs that include “?replytocom=” at the end, like this:

http://www.example.com/something/?replytocom=12345

These URLs are part of the WordPress threaded comment feature. Unfortunately, the question mark “query string” in the URL makes it impossible for caching plugins like WP Super Cache to deliver a cached version, so the full WordPress PHP script gets run each time. That’s fine if a visitor is really replying to a certain comment, but it’s not fine for search engines to reindex every single URL on your site through hundreds of different “?replytocom=something” URLs.

If you have this problem on your site, adding these four lines to the top of your .htaccess file will fix it:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "Baiduspider|bingbot|Exabot|Ezooms|Googlebot|MJ12bot|msnbot|naver.com|ScoutJet|Slurp|YandexBot"
RewriteCond %{QUERY_STRING} ^replytocom=\d+$
RewriteRule ^(.*)$ http://%{HTTP_HOST}%{REQUEST_URI}? [redirect=301,last]

These lines detect certain search engines that try to index these, and simply redirect them back to the original page URL, without running any PHP code.

Cache requests that use campaign tracking

By default, WP Super Cache will not cache requests which include a query string that includes an “equal” sign. Services that track web site “campaigns” and services like FeedBurner that make a lot of requests to your site usually include a query string that looks something like this:

http://www.example.com/something/?utm_source=feedburner&utm_medium=feed&utm_campaign=feed-main

Of course, this query string prevents WP Super Cache from caching the request, increasing CPU usage. There’s no good reason for this, because the requested page is perfectly cachable otherwise.

You can improve your site’s CPU usage by editing the .htaccess to allow WP Super Cache to cache these types of requests. Open your Web site’s .htaccess file. Look for the section of lines for WP Super Cache, and find the line which tests %{QUERY_STRING}. Insert this new line of text immediately above the existing line:

RewriteCond %{QUERY_STRING} utm_source= [OR]

The new line (ending with [OR]) must come before the existing %{QUERY_STRING} line. After inserting, the two lines should look exactly like this:

RewriteCond %{QUERY_STRING} utm_source= [OR]
RewriteCond %{QUERY_STRING} !.*=.*

There are four very similar blocks right next to each other in the .htaccess file. Be sure to add the new line to the same place in each block.

Should I do anything else?

The tips above are almost certainly all you need to know.

People often ask us if they should also “minify” files, combine CSS and JavaScript, and lots of other things they’ve seen mentioned on other sites. If you’re comfortable doing those things and you want an extra small amount of performance, feel free to try them — but in our experience, they make little difference except with the very highest volume sites, and probably aren’t worth your trouble.

See where it’s still slow

After doing everything above, use a tool like WebPageTest, Pingdom Website Speed Test, 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.

Can all this really help that much in the “real world”?

Yes. For example, we have several customers using 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:

$ ab -n 100 -c 8 http://blog.tigertech.net/

Concurrency Level:      8
Time taken for tests:   0.058 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      5488200 bytes
HTML transferred:       5461600 bytes
Requests per second:    1715.62 [#/sec] (mean)
Time per request:       4.663 [ms] (mean)
Time per request:       0.583 [ms] (mean, across all concurrent requests)

In this case, our servers delivered over 1700 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.