“My WordPress site is slow, could you speed it up?” — that’s the message we get more often than any other. The request makes perfect sense; the answer rarely does, at least not the one people expect. Only very seldom is the fix a bigger hosting plan or yet another caching plugin.
Over the years a fixed running order has taken shape, and the order matters at least as much as the individual steps: measure first, spend last. Here is the list.
Why it pays off: search engines and buyers both prefer a fast site
Speed isn’t an aesthetic question, it’s a business one. If your site is slow, you pay for it in two places: in search and at the checkout.
In search, slowness is a double disadvantage. Google has treated page experience as a ranking factor for years — together with the Core Web Vitals metrics that measure loading — so between two similarly relevant results, the faster one comes out ahead. More important still, slow responses affect crawling: if the bot has to wait for its answers, it comes back less often and visits fewer pages. On a large webshop that literally means new products and price changes reach the index later — or, for a while, not at all.
With buyers the effect is immediate. Every extra second of loading costs you visitors, and it does so in the worst possible places: on the product page and in the checkout. According to Google and Deloitte’s joint study of retail sites, an improvement of just 0.1 seconds produced roughly an 8% lift in conversions — and the effect is strongest on mobile, where patience is shortest.
That’s why the list below isn’t an end in itself. We don’t optimise for the sake of a score; we do it so the visitor doesn’t click back and the crawler can work its way through the whole site.
1. Query Monitor: measure before you fix
The most common mistake is guessing. The owner switches off a few plugins, buys a bigger plan, installs a cache plugin — and in the end still doesn’t know what the problem was. That’s why we always start with Query Monitor: this developer plugin shows, for every page load, how many database queries ran, how long they took and — most importantly — which plugin or template fired them.
Slow queries are rarely spread out evenly. Typically there are one or two plugins asking the database dozens of pointless questions on every single page load. Once we know which, there are three ways forward: replace the plugin with a better one, replace it with a few lines of custom code, or — if it has to stay — keep it in check by loading it only where it’s actually needed.
Query Monitor also lists the hooks that fire, the outgoing HTTP calls and the PHP errors. Those last two are frequent culprits in their own right: an external API that keeps every page load waiting for a response sometimes costs more than all the database queries combined.
2. Autoloaded options: the invisible weight
WordPress loads every option flagged as “autoload” on each and every request from the wp_options table — on the homepage, on a product page and during an AJAX call alike. Normally that’s a few hundred kilobytes. On neglected sites, though, we have repeatedly found several megabytes of autoloaded data, which is extra weight on every single request.
The cause is almost always the same: settings left behind by plugins deleted long ago, transients that expired but were never cleaned up, and logs that somebody thought would be a good idea to store in the options table. Cleaning up isn’t risk-free — so we always start with a backup and go through it row by row — but it pays off visibly: this is the step where the least work returns the most milliseconds.
3. Indexes: when there are many products and meta fields
The WordPress database schema was built for general purposes, not for a shop with tens of thousands of products. The wp_postmeta table — home to product data, custom fields and plugin data — is weakest exactly where it is needed most: in complex filtering and sorting.
This is where index plugins come in, adding optimised indexes to the MySQL tables. It isn’t magic, just plain database maintenance — but on a large catalogue it can take an admin list page from ten seconds to under one. On a small site it isn’t worth the trouble: there an extra index is mostly extra maintenance.
4. WooCommerce HPOS: orders in tables of their own
For years WooCommerce stored orders in the WordPress post tables — in other words, in the same place as blog posts. At several thousand orders that becomes a serious brake. HPOS (High-Performance Order Storage) solves it: orders move into separate tables designed for exactly this purpose.
If an older webshop doesn’t have it enabled yet, switching is almost always worth it. Two things have to be checked first, though: whether every plugin is compatible with it, and whether there’s a recent backup. It’s worth starting the migration in synchronised mode so there’s a way back.
5. Plugins: update first, then slim down
The problem isn’t the number of plugins, it’s what they do on every load. Twenty well-written plugins do less harm than three bad ones. That said, every plugin is code, every piece of code is maintenance, and every outdated plugin is a slowdown and a security risk at the same time.
This is the point where generic work stops. Here you have to dig into what the client actually needs — because replacing a plugin usually means writing the few dozen lines they really use instead of keeping a thousand-line do-everything plugin. That’s more work than flipping a switch, but it’s what produces a lasting result.
6. Caching: useful, but not medicine
A cache doesn’t make a site faster — it hides how slow it is. On a well-optimised system page cache and object cache really are spectacular: serving time can drop to a half or a quarter. On a fundamentally slow, disorganised site they rarely help much, and worse, they paper over the faults, which makes the real cause harder to find.
On top of that, caching has its own traps in a webshop. The cart, checkout and account pages have to be excluded, otherwise visitors end up seeing each other’s baskets — not a theoretical danger, but the classic failure of a badly configured cache. That’s why this step comes after the fifth place, not first.
7. A server cron for high-traffic sites
WordPress scheduled tasks don’t run on their own by default: WP-Cron fires when a visitor happens to arrive. On a small site that’s perfectly fine. At higher traffic it means your visitors are the ones paying — with their own page load time — for the newsletter sending, the feed generation and every other background job.
The fix is simple: disable WP-Cron and set up a real server-side cron every few minutes instead. Background jobs then run at predictable times and the visitor doesn’t wait for them. The same fix protects against the opposite extreme too: on low-traffic sites WP-Cron sometimes doesn’t run at all, and a scheduled post or backup quietly fails to happen.
8. Crawl bots: who are you actually serving?
Before anyone spends money on a bigger server, it’s worth checking where the capacity is going. The server access log answers that precisely, and it often turns out that a large share of the traffic isn’t human at all. Some of it is useful search engine crawlers, some of it is bots harvesting for AI training, and some of it is scripts firing dozens of requests a second with no restraint whatsoever.
The most expensive pattern is a crawl walking through filter combinations. In a webshop the combinations of filter parameters produce a practically infinite number of distinct URLs, and none of them can be served from cache — every one means a full PHP and database run. A crawl like that can bring a site to its knees on its own, while the same site would comfortably handle its real visitors.
The fix starts with the log: we look at which user agents and IP ranges are consuming the requests, then block the pointless ones — ideally at server level, before WordPress even starts up. That detail matters more than it sounds: if the blocked bot gets a full WordPress-generated page back instead of a plain error, you have kept most of the load you were trying to shed. Useful search crawlers stay untouched, of course — the goal isn’t invisibility, it’s making sure the capacity goes to people.
9. And only at the very end: the hosting
If all of the above is done and the site is still slow, then it’s time for the provider. At that point we don’t ask for a bigger plan, we ask one specific question: which resource is running out? The number of PHP processes, CPU time, memory or disk I/O? The answer is what reveals whether an upgrade is genuinely needed or whether a limit is simply set wrong.
This is the last step in the order, and for good reason. Buying a bigger plan without measuring doesn’t solve the problem, it just pays for it: a slow query stays a slow query on a more expensive server.
The list in one place
| Step | What it reveals or fixes | When it pays off |
|---|---|---|
| 1. Query Monitor | Which plugin and which query is eating the time | ✔ Always our first move |
| 2. Autoloaded options | Redundant data loaded on every request | ✔ On old, heavily extended sites |
| 3. SQL indexes | Slow filtering and sorting on a large catalogue | ◐ With many products or meta fields |
| 4. WooCommerce HPOS | Orders in separate, fast tables | ✔ At high order counts, if not yet enabled |
| 5. Plugins | Replacing outdated and redundant code | ◐ After mapping the needs, with custom code |
| 6. Caching | Faster serving — not fixing the faults | ✖ Not on its own, before the clean-up |
| 7. Server cron | Background jobs taken off the visitor | ◐ At high traffic |
| 8. Crawl bots | Filtering out non-human traffic from the access log | ✔ When the load doesn’t match the visitor count |
| 9. Hosting | Which resource actually ran out | ✖ Only as a last resort |
In our experience you rarely need all nine. Most “my WordPress site is slow” cases are solved within the first three steps — without spending a single extra penny on hosting. What you do always need is someone who measures what’s happening first, and only then reaches for the settings.
Is your site slow and you don’t know where to start? Or have you tried everything already and nothing moved? Tell us about it and we’ll work through it for you.