Ecommerce

WooCommerce slow? 12 causes and how to fix each one

Measure first, then work down the list: most slow WooCommerce stores have two or three of these twelve problems, not all of them.

By RaaoPublished 8 min read

Short answer: why is WooCommerce slow?

WooCommerce is slow when the server, the database or the front end is doing more work than it should. The most common causes are underpowered hosting, a page cache that is missing or bypassed, no persistent object cache, a bloated database and too many scripts on every page.

WooCommerce itself is not inherently slow. Well-built stores with thousands of products load in under a second. Measure first, find which of the 12 causes below apply, and fix them in order of impact.

Why does WooCommerce slow down over time?

A new store with 50 products and five plugins is fast on almost any host. Speed problems arrive gradually, as orders, plugins and data accumulate:

  • Every order, customer session and scheduled task adds rows to the database.
  • Every plugin can add queries, autoloaded settings and front-end scripts.
  • Marketing adds tracking pixels, chat widgets and review widgets.
  • Traffic peaks such as Black Friday expose limits that were always there.

It matters because speed is money. Slow product pages hurt Core Web Vitals and rankings, and slow checkouts lose orders. If the store feels slow to you, it is slower still for a customer on a mid-range phone and a mobile connection.

How to diagnose a slow WooCommerce store

Before changing anything, find out where the time goes. Split it into server time and browser time.

Symptom Likely area Tool to confirm
High TTFB on every page, even cached ones Hosting, DNS, no page cache PageSpeed Insights, WebPageTest
Fast category pages, slow cart and checkout PHP, object cache, plugins Query Monitor
Slow admin, slow order screens Database, scheduled actions Query Monitor, WooCommerce → Status
Good TTFB but slow LCP Images, fonts, render-blocking scripts PageSpeed Insights, Chrome DevTools
Slow only at peak times PHP workers, CPU, database connections Hosting metrics, server logs

Google's web.dev guidance treats a TTFB of 0.8 seconds or less as good. For Core Web Vitals, the "good" thresholds are LCP up to 2.5 s, INP up to 200 ms and CLS up to 0.1.

Install Query Monitor on staging (or briefly on production). It lists every database query per page, grouped by plugin, and flags slow and duplicate ones. Also open Tools → Site Health. Messages such as "You should use a persistent object cache" or "Autoloaded options could affect performance" are worth acting on.

The 12 causes of a slow WooCommerce store and how to fix them

1. Hosting that is too small or too shared

Cheap shared hosting puts hundreds of sites on one server. WooCommerce pages that cannot be cached (cart, checkout, account, search) need real CPU and enough PHP workers.

Fix: move to a VPS or managed WooCommerce hosting with dedicated resources, PHP 8.3 or newer, at least 256 MB of PHP memory and OPcache enabled. The PHP version and memory figures match WooCommerce's own server recommendations; OPcache is a standard PHP setting that good hosts enable by default. Errors such as 504 Gateway Time-out or Allowed memory size of 268435456 bytes exhausted are classic signs.

2. No page cache, or a cache that is always bypassed

Without a page cache, every visit runs PHP and dozens of queries. With a badly configured one, the cache is skipped because of cookies.

Fix: use server-level caching (Nginx FastCGI cache, Varnish or LiteSpeed) or a good caching plugin. Exclude only /cart/, /checkout/ and /my-account/. Check that a session cookie such as wp_woocommerce_session_ is not being set for every visitor on every page, which would make every page uncacheable.

3. No persistent object cache

WordPress repeats the same database lookups on every request unless you give it a memory store.

Fix: enable Redis (or Memcached) on the server and connect it with a plugin such as Redis Object Cache. This mostly speeds up the pages you cannot page-cache, plus the admin.

4. Bloated autoloaded options

Options marked as autoload are loaded on every single request. Uninstalled plugins often leave large ones behind.

Fix: check the total size with this query (adjust the table prefix):

SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');

Anything near or above 800 KB deserves attention, which is also where Site Health starts warning since WordPress 6.6. List the largest rows, identify the plugin, and turn autoload off for anything not needed on every page.

5. A backlog of scheduled actions

WooCommerce and many plugins use Action Scheduler for background jobs. When WP-Cron only runs on page visits, jobs pile up.

Fix: open WooCommerce → Status → Scheduled Actions and look at Past-due and Failed. Thousands of failed actions from the same hook point to a broken plugin. Disable WP-Cron in wp-config.php with define('DISABLE_WP_CRON', true); and run it from a real server cron every minute. Purge completed actions older than 30 days.

6. Orders still stored in the posts table

Older stores keep orders in wp_posts and wp_postmeta, which get huge and slow. High-Performance Order Storage (HPOS) moves orders into dedicated tables. It has been the default for new stores since WooCommerce 8.2.

Fix: go to WooCommerce → Settings → Advanced → Features, enable compatibility mode to sync both storages, check that your plugins are compatible, then switch to HPOS. Do it on staging first.

7. Plugins that load everywhere

A form plugin loading its scripts on product pages, or a reporting plugin running heavy queries on every admin screen, adds up.

Fix: use Query Monitor to rank plugins by query time. Remove what you do not use, replace heavy plugins with lighter ones, and load scripts only on the pages that need them.

8. Unoptimised images

Product photos straight from the photographer at 4–8 MB each are still common. They usually decide your LCP.

Fix: serve WebP or AVIF, resize to the displayed size, use srcset, lazy-load images below the fold and never lazy-load the main product image. A CDN for images helps visitors far from your server.

9. A heavy theme or page builder

Multipurpose themes and page builders often ship hundreds of kilobytes of CSS and JavaScript on every page, whether or not a page uses them.

Fix: measure the unused CSS and JS in Chrome DevTools → Coverage. Either strip what is unused, or move to a lean, WooCommerce-focused theme. Sometimes a custom theme is cheaper than months of tuning.

10. Cart fragments on every page

The wc-ajax=get_refreshed_fragments request updates the mini-cart, and it cannot be cached. Since WooCommerce 7.8, the script only loads when the Cart Widget is rendered, but many themes still force it into the header.

Fix: check the network tab for this request on pages where the cart has not changed. Use the Mini Cart block, or load fragments only once the shopper has items in the cart.

11. Slow filters and search on large catalogues

Layered navigation across many attributes can create very expensive queries on catalogues of thousands of products.

Fix: enable the product attributes lookup table under WooCommerce → Settings → Products → Advanced, and regenerate it from WooCommerce → Status → Tools if it gets out of sync. On very large catalogues, move search and filtering to a dedicated index such as Elasticsearch, OpenSearch, Meilisearch or Algolia.

12. Third-party scripts and live API calls

Chat widgets, heatmaps, several ad pixels and review widgets can hurt INP more than anything on your own server. On the server side, live calls to a courier, ERP or exchange-rate API during page load make every page wait for someone else's server.

Fix: audit tags in Google Tag Manager, remove duplicates and move tracking server-side where possible. Never call an external API synchronously on product or cart pages: sync stock and prices in the background and read them from your own database.

Quick diagnostic checklist

  • TTFB measured on home, category, product, cart and checkout
  • PHP 8.3+, OPcache on, memory limit 256 MB or more
  • Page cache active and cart, checkout and account excluded
  • Redis or Memcached object cache connected
  • Autoloaded options under ~800 KB
  • No pile of past-due or failed scheduled actions; real cron running
  • HPOS enabled
  • Query Monitor shows no plugin with slow or repeated queries
  • Product images in WebP or AVIF, main image not lazy-loaded
  • Cart fragments only when needed
  • Attribute lookup table enabled for filters
  • Third-party scripts audited; no live API calls during page load

What does it cost to fix a slow WooCommerce store?

Ranges below are market estimates for European freelancers and agencies, excluding VAT:

Fix Typical cost Notes
Hosting upgrade (VPS or managed) €30–300/month Biggest single gain for most small stores
Performance audit €300–1,000 one-off Should produce a ranked list of fixes, not a PageSpeed screenshot
Caching, Redis, database cleanup, HPOS €500–2,000 one-off Depends on plugin compatibility
Theme replacement or custom theme €2,000–8,000 When the theme is the bottleneck
Search index for large catalogues €1,000–5,000 plus service fees Thousands of products with many filters

At Raao, every store runs on cloud, dedicated or VPS servers we manage, tuned for speed and security; the Launch package adds CDN, caching and image optimisation. Hosting and maintenance plans start from €89/month. If the store needs a rebuild, the Starter package starts from €1,900 and Launch from €3,900; see pricing and the ecommerce service.

How we did it for Kuiba

Kuiba sells more than 10,000 configurable products from 25+ European brands, which is exactly the kind of catalogue that slows down a standard setup. Kuiba runs on a custom platform rather than WooCommerce, but the same principles apply:

  • A custom storefront built for speed and SEO, served from servers we manage.
  • Instant faceted search with synonyms and an AI fallback, instead of heavy database queries for every filter click.
  • Automated supplier imports for brands such as Bonaldo, Calligaris, Nardi and Miele, running in the background rather than during page loads.
  • Server-side GA4 and the Meta Conversions API, which keeps tracking work off the shopper's browser.

See the Kuiba case study. If you want us to look at your store's numbers, book a free 30-minute call through the contact page.

woocommerceperformancehosting

Frequently asked questions

Keep reading

Let us look at your setup together

Book a free 30-minute call and leave with a clear next step and a realistic price range.

Prefer writing? Send us a brief
  • 30 minutes, video call, no obligation
  • Talk directly with the engineers who would build it
  • Honest view on scope, timeline and budget

The calendar is provided by Microsoft Bookings, which may set its own cookies.