Performance Quick Start Guide: Solving WordPress Performance Problems

Since 2016 I have been solving WordPress performance problems. The performance issues that actually slow a site down are nearly always server-side, and there are a handful of repeatable patterns you can use to find exactly where the slow bottlenecks on your site are coming from.

Below, I pass that knowledge on to help you get the speed you deserve from the hosting you are paying for.

Faster sites make more money, get more social shares, have higher pages per visit, more returning visitors and get crawled more by Googlebot, along with higher search rankings. But most of all, faster sites are better for your users. You love your users, right?

The most common WordPress performance issues

Nearly every slow site I look at has one or more of these. Each one links to the section that fixes it.

• A high page generation time – the server takes too long to build the page in the first place
• No object cache – the same data is fetched from the database over and over
• Plugins running too many queries – hundreds of queries per page, usually showing up as high PHP time
• Slow queries that scan the whole table – queries written without database indexes in mind
• Plugins fetching thousands of rows – to display ten items, burning CPU and RAM
• Slow imports – often the registered image sizes rather than the importer itself
• Slow sitemaps – which also eats your Googlebot crawl budget
• A slow wp-admin – usually a bloated wp_options table or one badly coded plugin

Page generation time: the number that actually matters

What counts as a high page generation time?

Measured uncached on WordPress: under 500ms is good, over 1 second is bad, and over 3 seconds is dreadful. It is not only about how long a single visitor waits. Every page being generated ties up a PHP worker for that entire time, so at over 3 seconds you support far fewer simultaneous visitors and you will struggle to survive a traffic rush. I built Scalability Pro specifically to drag that number back down into the good range.

This section is the short version. For the full treatment – what the number contains, every common cause, and how to find which plugin is responsible on your own site – see WordPress page generation time: how to measure it and bring it down.

Scanning your site with GTmetrix can help identify areas where you could optimise speed, particularly on the Mobile tab where it simulates devices with less CPU power. These tools are useful for spotting when too much is going on in a page for phones to handle.

These tools will tell you to minify your CSS, compress or resize images, remove render-blocking JavaScript and combine files so they download faster. Many of those recommendations date from before HTTP/2 and HTTP/3, which download many files in parallel over a single connection, so they matter far less than they used to. Running a scan still does no harm and often surfaces something useful. To take advantage of HTTP/3, upgrade your hosting or put a CDN that supports it in front of your site.

A slow page generation time is not just a performance issue, it is also a scalability issue. If your server takes 4 whole seconds to generate a page, it is not sitting there chilling. It is doing several things as fast as it can. The resource bottlenecks tend to be CPU and disk, so if you see low CPU but long page loads then you probably have slow disks, or plugins or theme code reading too much data from disk.

To see the page generation speed on every page of your site, and to start identifying the sources of your performance problems, install the free Query Monitor plugin by John Blackbourn.

Page caching should ideally be handled at server level

You probably have a page cache already. You might even have two, which is pointless and wasteful of disk: with multiple page-caching plugins enabled, every page is written to disk multiple times yet only one of those cache files is ever served. Page caching is often the first thing people add to a WordPress site when things get slow.

Page caches are great for reducing server load and surviving traffic spikes, but they do not improve your page generation speed.

If your host does not offer page caching of some kind, change hosts or follow our stack-building guide to get the highest performance at the lowest cost.

If you insist on using a WordPress plugin for page caching then WP Rocket, W3 Total Cache and a myriad of others will do the job. Page caching is trivial to code, so there is not much they can get wrong. Your page-caching plugin should be able to selectively wipe cache entries when posts or products are updated, rather than wiping the entire cache, and it should interface with Apache, Nginx or LiteSpeed so the web server bypasses PHP when a cached file is available.

Object caching is essential

Plugins tend to grab data from the database, manipulate it in some way and store it in an object for use throughout their code while generating the page. An object cache lets these objects be stored in memory across many pages, which means the more your site is browsed, the faster it gets.

Object caches really need to live in memory to give the most benefit, and Redis and Memcached are the two most popular that work with WordPress. WordPress plugins keep getting better at using the object cache properly, so get Redis installed on your hosting (most hosts offer it) and add the free Redis Object Cache plugin by Till Kruse, or use W3 Total Cache.

See our stack-building guide to make sure your hosting provides an in-memory Redis cache.

Many people use WP Rocket and assume it includes an object cache, but it does not. If you use WP Rocket, add the Redis Object Cache plugin too. They complement each other well.

Hosting choices

What matters most from your hosting company is the stack they provide, and the ability to clone your site into dev and staging areas so you can try things out safely. After that it comes down to managed versus self-managed, remote backups and the level of support. Here are the key essentials to look for:

• NVMe or SSD disks, never HDD
• 1Gbps networking, not 100Mbps
• PHP 8.2 or newer. PHP 8 is dramatically faster than PHP 7, and night-and-day versus the PHP 5.6 that some ancient hosts still run
• MariaDB, Percona or MySQL 8, not MySQL 5.x
• Redis in in-memory mode for your object cache, or Memcached
• Nginx or LiteSpeed both scale better than Apache, though this matters less than the items above
• A page-caching system of some kind
• An HTTP-level accelerator, whether Varnish, Nginx FastCGI cache, LiteSpeed, or Cloudflare in front of your site
• A CDN such as Cloudflare, using its features to compress and minify CSS and set long browser-cache expiry on static files

If you follow the WordPress Speed Up and Advanced WordPress groups on Facebook, people tend to prefer GridPane, RunCloud, Cloudways, Kinsta and WP Engine.

I personally love Digital Ocean and Hetzner. With them I can spin up new server clones in a minute and get full control over the server. My million-product demo store loads in sub-second uncached speeds on a $20-per-month Digital Ocean droplet.

If you want the highest performance at the lowest monthly cost and have the skills to DIY, check out my comprehensive WordPress stack-building guide. I use Digital Ocean, but you can use AWS, Google Cloud or wherever you like and get amazing performance for very little money.

If you want that ultra performance with a front-end control panel, there is no-one better than GridPane. Their stack is an evolution of my stack with a great control panel on top that makes building, configuring, cloning and migrating a matter of point and click. GridPane plus Hetzner gives ultra performance at incredibly cheap prices.

Upgrading your current hosting

Obviously it is easier to stay with your current host, so here is a priority list:

1. Upgrade PHP. PHP 8.x is far faster than PHP 7, and dramatically faster than PHP 5.6.
2. Add an object cache, either Redis or Memcached.
3. Upgrade to MySQL 8 or MariaDB.
4. Add a CDN.

If after all that your speed is acceptable, then it is fine to stay where you are.

Cloning your server

To properly analyse your site you need to be able to deactivate and reactivate plugins and theme features without affecting your users. Visitors can be on your site overnight, so you really need a clone.

Ask your host if they can create a staging server (also called a clone) for you. Most can clone your site to a different subdomain so you can experiment with WordPress settings, including activating and deactivating plugins while you optimise performance. The first step in optimising your site is to find out where the problems lie, and the fastest way to do that is to toggle features on and off without affecting your users.

If your host does not provide cloning, a few plugins can clone smaller sites, but for a larger site follow my migration guide for step-by-step instructions on creating a WordPress clone.

Measuring your page generation time with Query Monitor

The free Query Monitor plugin by John Blackbourn shows your page generation time, how many MySQL queries ran to generate the page and how long they took. Subtract the MySQL time from the total page generation time and you have your PHP time.

This tells you whether your slowness comes from the database or from the way some plugins are coded, which typically shows up as a high PHP time.

Optimising your own site

Start with Query Monitor. Look for high query counts, slow queries and queries that return a lot of rows. On your dev or staging clone, experiment by deactivating the plugins that show high numbers. Test your pages with Redis disabled first, then test again with Redis enabled.

Once you have found the bad plugins, either find alternatives or disable their assets where they are not needed using the free Asset Cleanup plugin from the WordPress repository.

Many plugins run slow code on every page, so unloading them until they are needed can really reduce load on your server and speed everything up. You can also contact the plugin developers, screenshot your performance issues and give them proof that their plugin is slowing your site down.

Finding plugins with too many SQL queries

Click Queries by Component to see which plugins are performing the most queries.

As your WordPress site grows, the number of queries per page tends to increase. Use Queries by Component to see which plugins are causing your high query count. High query counts do not usually have a high total database time, but they do typically incur a high PHP time because of all the objects being built.

If you use WooCommerce shortcodes or filters you will probably see a very high query count on your slow pages. If those high counts are coming from your shop filters or on-sale pages, use my Super Speedy Filters plugin, which filters with SQL instead of loading products into PHP.

If you use a page builder like WPBakery, Elementor or one of the others, it may have inserted WooCommerce shortcodes for you, or they may be built into your theme options.

Object caching can reduce the number of queries in many cases, so try that first if you have a high query count from particular plugins. Otherwise, test how much page-speed boost you get from deactivating the plugin. If you have many variations driving a high query count, an object cache helps a lot because those objects can be reused across product detail and archive pages. On top of that, I frequently see shops using variations where they could use simpler product rules or product add-ons.

Finding plugins with slow SQL queries

Click Queries to view all queries, then click the Time column to sort by time. Many plugins run slow SQL because they were not written to use database indexes. A query that uses an index runs thousands of times faster than one that scans the whole table.

I created Scalability Pro specifically to find and eliminate table scans in WordPress and WooCommerce. It adds good indexes to your tables and rewrites some queries so they actually use those indexes.

When you find a slow query, Query Monitor tells you which plugin caused it. If you find a slow query that object caching or Scalability Pro do not optimise, let me know and I will figure out a fix.

Finding plugins with high row counts

Click Queries to view all queries, then click the Rows column to sort by row count. Plugins that fetch hundreds or thousands of rows to show ten items on a page typically cause high CPU and high RAM usage. Sometimes an object cache reduces the CPU, but RAM usage often stays high. These are frequently the plugins that fetch the entire database and process it in PHP to produce something on your page.

Speeding up CSS, JS and page rendering

If you are keen to get high Pingdom or GTmetrix scores you will need to optimise your CSS and JS. We do not focus too heavily on that ourselves, because what matters is user-perceived speed, but in many cases the rules those tools give you do improve perceived speed.

There are plenty of asset-optimisation plugins that will get you better scores, but the best approach is a CDN that provides image, CSS and JS optimisation. Many CDNs also offer page caching, keeping even more load off your WordPress server.

Speeding up slow imports

If your imports are slow, the biggest win is the importer itself. My Super Speedy Imports plugin is SQL-first and imports or updates products 10x to 1,200x faster than the usual XML importers. Alongside it, Scalability Pro speeds up any importer, especially as your store grows, and you should also read my article on the WordPress image sizes problem.

Over time, the plugins you install register new image sizes and do not remove them when deactivated. It is not uncommon for a site to have 30 registered image sizes. That means every imported image is resized into 30 variants and stored in your uploads folder, which is a lot of extra CPU for resizing and a lot of disk for storage.

Fix the image sizes for your site using the guide above, and use Scalability Pro for large imports. It speeds imports up by deferring term counts until the import completes and by speeding up the wp_postmeta lookups that import tools use to decide whether to insert or update an item.

For the ultimate in import speed, take images off your server altogether with our External Images plugin, which serves images straight from a CDN, S3 or your affiliate feed with nothing downloaded to your server. Delayed Image Import takes the other approach: the import finishes quickly and the images download afterwards in the background.

Before any of that, check you have a real system cron job driving WordPress. Without one, WordPress runs its scheduled work when a visitor happens to hit the site, which is bad twice over: your visitors pay for the work in page speed, and your imports do not run at all during quiet periods.

Speeding up slow sitemaps

I ran a case study on various XML sitemap plugins and the results will surprise you. The fastest sitemap plugin was actually years old and no longer maintained, so I took it over, renamed it Super Speedy Sitemaps, fixed the security issues and now maintain it. The case study includes techniques that optimise sitemap generation by up to 250-fold.

If your sitemaps take over a minute to generate, that affects everyone else using your site at the same time, so it is worth optimising. Worse, search engine bots like Googlebot have a limited crawl budget per site, so a slow sitemap means fewer of your pages get indexed and shown in search results.

Speeding up wp-admin

It is annoying when wp-admin gets slow. This is where you and your staff live. An object cache can speed up wp-admin, but sometimes it does the opposite if a plugin is badly coded, or if you have too many or too-large options in your wp_options table.

Scalability Pro provides plenty of options to optimise wp-admin, and my Super Speedy Search plugin helps too by speeding up admin searching as well as front-end searching.

If you are bulk editing items in wp-admin, it is hard to use Query Monitor to isolate the issue because bulk edits happen one at a time over AJAX. To speed up bulk edits, perform a single edit to see the per-item performance profile and optimise that.

Speeding up your wp_options table

Some options are loaded on every page, and in rarer cases the entire wp_options table is fetched. Plugins leave these options behind and they are often huge. Options marked as autoload are loaded on every page, and for admins all options are regularly loaded, so cleaning up your options table can give a decent speed boost on every page.

For the full walkthrough, read my knowledge base article on managing the wp_options table and autoload.

Choosing a fast theme

Many themes sold on marketplaces like ThemeForest arrive bundled with third-party plugins. More features sell more themes, and most sites never grow large enough to feel the cost, so the incentive runs against you. Rehub is one notable exception we have found there.

Prefer themes from established companies with a team of developers behind them rather than a single author, and treat lightweight block-based themes as a serious option in their own right. Theme makers worth a look include Themify, Elegant Themes and GeneratePress.

A heavy theme is not automatically a lost cause. A Bulgarian news site running tagDiv’s Newspaper theme took its archive pages from 9.5 seconds to 1.5 seconds uncached, and the owner recorded a walkthrough of what changed. The write-up, with the video, is in speed hacks for the Newspaper theme by tagDiv.

WooCommerce shortcodes and the attribute and price widgets

If you use WooCommerce shortcodes (products on sale, best sellers, most popular products) or the WooCommerce attribute or price widgets, you will see a very high query count in Query Monitor on the pages that carry them. An object cache helps, but the first load of each page is still slow.

You may not realise you are using them. A page builder can insert the shortcodes for you, and some themes build them into their own options screens, so the first sign is often the query count rather than anything you chose. Removing them, or replacing them with faster equivalents, is usually the single biggest win on a category or shop page.

The plugins that fix these problems

Every plugin mentioned in this guide is built to remove one of the bottlenecks above, from slow queries and imports to filters, search and sitemaps.

Related products

Scalability ProSpeed up your whole site – big catalogues, big databases, no re-architectureSuper Speedy ImportsEasy to use. Built for speed.Super Speedy FiltersFast product filters and pretty, indexable permalinks on every archiveSuper Speedy SearchSpeeds up front-end and wp-admin searchSuper Speedy SitemapsAll other sitemaps were so slow, we built our ownExternal ImagesKeep your images off your server – on a CDN, S3, anywhere

More performance guides

This guide is the overview. These go deeper on each part of it.

Imports and product data

• Fixing Slow WooCommerce Imports – the companion hub, for when it is your import that is slow rather than your site

Hosting and stack guides

• Installing the fastest WordPress stack
• Stack configuration, customisation and optimisation
• Setting up a WordPress cluster for huge sites
• Maintaining and managing a WordPress cluster
• Migrating huge WordPress sites reliably

Finding your bottleneck

• Using Query Monitor to find slow queries and hooks
• WordPress plugin performance analysis
• Optimising front-end WordPress performance
• Analysing slow MySQL 8 performance with pt-query-digest
• Profiling WordPress PHP code with Xdebug and Xprofiler

Configuration and security

• Configuring Redis for WordPress and WooCommerce
• Configuring Cloudflare for WordPress and WooCommerce
• Complete guide to WordPress security
• A-list third-party plugins for WordPress site speed

Real-world results

• Speed hacks for the Newspaper theme by tagDiv – a Bulgarian news site took its archives from 9.5 seconds to 1.5 seconds uncached, with a video walkthrough from the site owner

Further reading

Frequently asked questions

Getting more help

Since 2016 I have been coding plugins that optimise WordPress in one way or another. I have written lots of guides for different scenarios, and I have personally optimised dozens of previously unoptimisable websites.

We run an active Discord server, and it has been a game changer for support and for driving development forward. I want to make performance and scalability easy and available for everyone, so read the articles, browse the knowledge base, and if you cannot find what you need, or you just want some personalised help, you can find me, Dave Hilditch, on our Discord server almost every day.

If you like what I am doing, please share my articles widely. I am great at performance optimisation but I suck at marketing, so I need all the help I can get. I look forward to chatting with you on Discord, or leave a comment below.