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 improve that speed (and therefore how many visitors it can handle).

WordPress performance really depends on you, because it’s based on the speed of any plugins and themes you've installed. We've seen WordPress speeds vary anywhere between 1,000 and 200,000 page views per hour, all on the same server and hosting plan with our company. The time needed to load an individual page can vary from a fraction of a second to several seconds, depending on how WordPress has been configured and what theme and plugins it uses.

This page describes techniques for speeding up WordPress, including WP Super Cache. Applying these techniques often makes WordPress run at least 100 times faster. The most important ones are listed first.

On this page:

Make sure you’re using PHP 7.0 or later, and preferably PHP 8.2

If your scripts are compatible with PHP 7 (most properly updated WordPress sites are), you can speed things up significantly by choosing that option. PHP 8.2 is twice as fast as PHP version 5 and at least 20% faster than PHP 7.0.

You can choose your PHP version using the “My Account” control panel.

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, including unchecking “Mobile device support” unless you use an old theme that isn’t “responsive”, although those are now rare.

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. Similarly, other people try a plugin called “WP Rocket” — but again, in our experience hosting thousands of WordPress sites, we recommend WP Super Cache for better performance.

Remove 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. Some sites can 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, delete every plugin that’s not needed to make your site work. And test every plugin individually to see how much it slows down your site.

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.

Use SSL

Our servers support HTTP/2 for SSL connections, allowing many simultaneous requests to be sent over a single web browser connection. HTTP/2 over SSL gives WordPress sites a speed boost comparable to complicated (and now-outdated) recommendations suggesting you “combine CSS and JavaScript files” or “put static resources on a separate hostname to increase the number of browser connections”. If you use SSL, you don’t need to worry about those things.

New WordPress sites installed using our one-click installer should use SSL automatically. If you have an existing site that doesn’t yet use SSL, we have a page explaining how to enable SSL for WordPress and other sites. If you have any trouble, we’ll be glad to enable SSL for you; just let us know.

Use compression

If your site uses many external image files, JavaScript files or CSS stylesheet files, add compression rules for those files.

If you use our WordPress one-click installer, compression rules are automatically added 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).

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

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 website 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 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|svg|bmp|ttf|woff|woff2)$ - [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|svg|bmp|ttf|woff|woff2)$ - [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”.

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

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.

Compress your images and size them appropriately

If you have large images on the site, make sure they’re properly sized and compressed so they’re not wasting bandwidth. Test your site with WebPageTest and make sure their “Compress Images” score (in the “Optimization” view) shows no problems.

Ideally, you should size and compress your images using software on your own computer before you upload them. For example, if a page has a photo that’s going to be displayed at less than 1000 pixels wide, you can use basic image editing software on your computer to make it roughly that width before uploading it, instead of using the much larger size that comes from your cellphone camera. (Modern phone cameras often take pictures 4,000 or more pixels wide; resizing one of those to be a quarter of the width and height makes the file 16 times smaller and 16 times faster to load.)

If you’ve already uploaded large images and want to compress and resize them with a plugin, avoid any plugins that compress them on each page view. Decent plugins should compress images once, save the compressed version on the server, and modify your pages to use those smaller images permanently. The smaller images should be used even if you later remove the plugin.

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.

Use appropriate caching

If your site uses many image files, JavaScript files or CSS stylesheet files, you might want to consider setting up appropriate caching.

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.

Do I need a persistent object cache?

WordPress 6.1 and later sometimes show a suggestion to “use a persistent object cache” like “Memcached” or “Redis”. However, doing so is complicated, and you almost certainly don’t need to do that — for most sites on our servers, using a persistent object cache actually slows sites down. This is especially true if you install the WP Super Cache plugin we recommend above, which makes far more of a difference to site speed than a persistent object cache can.

If you use our WordPress plugin on your site, WordPress will know that it should not recommend that. Otherwise, we suggest ignoring the unnecessary warning.

If you want to try a persistent object cache anyway, the Object Cache 4 everyone plugin works with our servers as long as you’re using at least PHP version 8.2.

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, use a CDN like Cloudflare, use other “optimization” plugins like Autoptimize or WP-Optimize, and lots of other things they’ve seen mentioned on other sites.

In our experience, these make little difference except with very busy sites, and can even cause problems or make your site slower. They probably aren’t worth your trouble unless you’ve already done everything described above, you’re still dissatisfied with the speed, and your site has millions of page views per month. If you do anything like this, be sure to test your site before and after to see if it actually helped or if it made it worse.

See where it’s still slow

If the site still feels slow after doing everything above, try installing the Health Check & Troubleshooting plugin and using its “Troubleshoot” mode:

WordPress Health Check & Troubleshooting plugin

This will show you a version of your WordPress site using a standard theme and no extra plugins (while keeping your site the same for all other visitors). If the site is fast in the troubleshooting mode, try enabling the plugins and theme you normally use, one by one, to see which are making it slow:

Health Check & Troubleshooting enable

If, on the other hand, your site still feels slow in troubleshooting mode, it’s likely that most of the time is spent on connections to external sites other than your own. You can use a tool like WebPageTest to see what other connections are slow, and eliminate as many of those connections as possible.

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

Yes. For example, we have customers who have followed the tips above and easily “survived” sustained page view rates of 20-30 pages per second, 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.

Could switching to a dedicated server improve performance further?

Some of our customers ask if “shared hosting” (the kind of hosting we offer) is inherently slower than “dedicated server hosting”, often because they’ve seen ads suggesting that dedicated hosting will improve the speed of a WordPress site.

There’s no inherent reason a dedicated server should be faster, though; it all depends on the speed of the servers, how much available CPU and RAM resources they have, and whether the hosting company limits access to those resources using a virtual machine (aka “Virtual Private Server” or “VPS”) or other restrictions.

Dedicated server hosting can be faster than shared hosting that’s resource-limited, as it is at many shared hosting companies. We don’t run our servers that way, though.

Our servers have more powerful hardware (and more available CPU and RAM resources) than a dedicated server that costs many times what we charge. We spread the extra cost of that among many customers who don’t need the full resources of a dedicated server all the time. The How do CPU units compare to a “dedicated server”? section of our page about CPU resources explains more about this.

The result is that our shared hosting should be faster than — and able to handle higher usage spikes than — a dedicated server that costs significantly more.

Copyright © 2000-2024 Tiger Technologies LLC