WooCommerce speed problems are usually blamed on hosting, and moving to a bigger server is often the first thing a store owner tries. In the WooCommerce stores we audit, the host is rarely the main cause. The same handful of issues come up again and again: too many plugins doing work on every request, a database full of old data, background jobs piling up, caching configured in a way that skips the pages that matter, and images and scripts that make the browser wait.
Here are the twelve fixes we check before recommending a hosting change, roughly in the order we check them. Most need no new infrastructure.
First, measure the right thing
“The site is slow” can mean the server takes a long time to answer (time to first byte), or the page takes a long time to appear and respond in the browser. They have different causes. Measure both on your key templates (home, a category, a product, the cart) before changing anything:
- Server time: use a staging copy with a query profiler such as the Query Monitor plugin to see which plugins and database queries each page runs.
- Browser time: use Core Web Vitals field data where you have enough traffic, and a lab test for each template.
Write the numbers down. Every fix below should move one of them, and if it does not, undo it.
The 12 fixes
1. Audit plugins by what they cost, not how many there are
Plugin count matters less than what each plugin does per request. One plugin that runs several slow queries on every page view can cost more than twenty that do nothing until an admin opens their settings. Profile a product page and a category page, sort by time, and question the top offenders. Remove plugins that duplicate each other (we often find two SEO plugins, or several that each add their own analytics).
2. Clean up autoloaded options
WordPress loads every option marked “autoload” on every request. Plugins that store large settings, caches or logs as autoloaded options slow down every page, including admin pages. Check the total size of autoloaded options, find the largest entries, and stop autoloading what is not needed on every request. Plugins you have already deleted often leave their options behind.
3. Move WP-Cron to a real scheduler
By default, WordPress runs scheduled tasks when someone visits the site, which means a visitor’s request can end up waiting while cron work runs. On a store with regular traffic, hook WP-Cron into the server’s task scheduler instead, so scheduled jobs run on their own timetable and never on a shopper’s request.
4. Check Action Scheduler for a backlog
WooCommerce and many extensions queue background work through Action Scheduler: emails, webhooks, subscription renewals, data syncs. If jobs fail or pile up, the queue table grows and each run gets slower. Look at WooCommerce → Status → Scheduled Actions for large numbers of past-due or failed actions, fix the cause, and make sure completed actions are being cleaned up.
5. Switch to High-Performance Order Storage
Older WooCommerce stores keep orders in the WordPress posts and post meta tables, which were never designed for order data. High-Performance Order Storage (HPOS) moves orders into dedicated tables. On stores with large order histories, it makes order queries lighter and reduces the load on the tables your product pages also use. Check that your extensions are compatible first; WooCommerce shows compatibility in its settings.
6. Prune the database
Expired transients, old sessions, post revisions, spam comments and orphaned meta rows accumulate for years. None of them help sales. Clean them on a schedule, and look at the postmeta table in particular: product and order meta from long-deleted plugins is common.
7. Add a persistent object cache
WordPress can cache database results in memory between requests if a persistent object cache such as Redis or Memcached is available. For WooCommerce, where many pages cannot be fully cached (see the next fix), this is one of the most effective changes. Many managed hosts offer it without a plan change.
8. Configure page caching around the cart
Full-page caching is the biggest speed win for pages that are the same for every visitor: home, categories, products, content. It must not apply to the cart, checkout and account pages, or to visitors with items in their cart. WooCommerce documents how to configure caching plugins for this. We regularly find stores where caching is switched off entirely because it once broke the cart, when the real fix was a correct exclusion list.
9. Stop cart fragments from running where they are not needed
The cart fragments script refreshes the mini-cart with an uncached request to the server. On themes that load it on every page, it can undo the benefit of page caching. Recent WooCommerce versions handle this more conservatively, but themes and plugins still re-enable it. Check whether your theme needs it, and limit it to pages where the mini-cart is actually shown.
10. Serve modern, correctly sized images
Product and category pages are image-heavy. Serve WebP or AVIF, generate sizes that match your layouts, include width and height attributes so the page does not jump, and lazy-load images below the fold, but never the main product image or the hero, which is usually your Largest Contentful Paint. Our article on where ecommerce LCP actually goes wrong goes deeper on this.
11. Reduce what loads in the browser
Many plugins load their JavaScript and CSS on every page, even when their feature appears only on one. Sliders, form plugins, review widgets and chat tools are the usual suspects. Load assets only on the pages that use them, defer non-critical scripts, and remove features nobody uses. This matters most on mobile, where the processor is slower.
12. Make product search efficient
WordPress’s default search runs broad database queries that get slower as the catalog grows, and faceted filtering plugins can multiply that. On larger catalogs, use a dedicated search index and make sure filter combinations are cached or indexed rather than computed from scratch each time.
The checklist
| # | Check | Affects | Effort |
|---|---|---|---|
| 1 | Profile plugins on product and category pages | Server time | Low |
| 2 | Autoloaded options size and largest entries | Server time, admin | Low |
| 3 | WP-Cron on a system scheduler | Server time | Low |
| 4 | Action Scheduler backlog and failures | Server time, reliability | Low–medium |
| 5 | HPOS enabled and extensions compatible | Server time, admin | Medium |
| 6 | Transients, sessions, revisions, orphaned meta | Server time | Low |
| 7 | Persistent object cache | Server time | Low–medium |
| 8 | Page cache with correct cart/checkout exclusions | Server time | Medium |
| 9 | Cart fragments limited to where needed | Server and browser | Low |
| 10 | Image formats, sizes, dimensions, lazy-loading | Browser (LCP, CLS) | Medium |
| 11 | Per-page asset loading, deferred scripts | Browser (LCP, INP) | Medium |
| 12 | Search and filters on an index | Server time | Medium–high |
How to run this audit in a day
You do not need a long project to find the biggest problems. This is the order we work in on a first audit day:
- Morning: copy the site to staging, install a query profiler, and record server time and query counts for the home, category, product and cart pages. Record field data for the same templates.
- Late morning: check autoloaded options, cron, Action Scheduler and the size of the largest database tables (fixes 2–6). These are quick to measure and often explain most of the server time on their own.
- Afternoon: review caching and object caching (fixes 7–9), then run lab tests on each template in the browser to find the heaviest images and scripts (fixes 10–11).
- End of day: rank what you found by likely impact and effort, and fix the cheap, high-impact items first, measuring after each change.
Keep the changes small and reversible, and apply them to staging before production. A single change that breaks checkout costs more than every speed gain on this list.
Keeping it fast
Performance drifts back without a routine. On stores we maintain, we re-check autoloaded options and Action Scheduler monthly, review new plugins before they go live, and re-run the template measurements after every significant update. Each new plugin should justify what it costs on the pages it affects.
When hosting really is the problem
After these fixes, hosting becomes the bottleneck when the server itself is underpowered or shared with noisy neighbours, when PHP is outdated, when there is no persistent object cache available at all, or when the database runs on the same small machine as everything else. At that point a move is worth it, and you will know exactly what you need from the new host because you have measured the site.
If you are considering leaving WooCommerce rather than tuning it, compare the options fairly first; our platform comparison covers when staying makes sense. Otherwise, our WooCommerce development team runs this audit on existing stores, and speed optimization covers the browser side end to end.