Why is WooCommerce slow? Usually because the pages that earn money, the cart and checkout, cannot be cached and wait on PHP workers and the database, and something there is starved, bloated or blocked. Measure first, then work through hosting limits, caching, database clutter, plugins and background jobs in that order.
This guide is for store owners and the developers who support them. It shows how to measure a slow store with Core Web Vitals, how to tell a host problem from a site problem, and which fixes pay off first. Start at the top and stop when the numbers turn green.
Why is WooCommerce slow? Measure before you change anything
Guessing wastes money when you ask why is WooCommerce slow and act on a hunch. A plugin you remove or a plan you upgrade may not touch the real bottleneck. Start with the three Core Web Vitals that Google publishes on web.dev, measured at the 75th percentile of page loads, separately for mobile and desktop.

Run your home page, a product page, the cart and the checkout through PageSpeed Insights, which shows real-user (field) data when enough exists, and through a lab tool such as WebPageTest. A store with a good home page and a poor checkout has a different problem than a store that is slow everywhere. Slow WooCommerce stores rarely have just one cause, so keep the list of symptoms.
Also note server response time (time to first byte). web.dev gives no pass or fail value for it, but a high number on uncached pages points at the server, not at images or scripts.
Why is WooCommerce slow: host problem or site problem?
Answering why is WooCommerce slow for your store decides where your money goes. A few quick checks separate the two.
- Slow everywhere, even on a plain static page: likely the host (overloaded server, slow storage, low CPU share).
- Fast home page, slow cart and checkout: likely PHP workers, missing object cache or a heavy plugin on those pages.
- Slow only in the admin or when editing products: memory limit, database size or a plugin making repeated queries.
- Fast at night, slow in the afternoon: worker limits or shared-server contention under load.
- Good server response but poor LCP or CLS: a site problem, usually images, fonts or scripts.
The WooCommerce developer documentation suggests Query Monitor to find slow plugins and queries, and PageSpeed Insights, GTmetrix or WebPageTest for ongoing monitoring.
Fix PHP workers first when WooCommerce checkout slow complaints start
A PHP worker handles one uncached request at a time. WooCommerce checkout is uncached by design, so every checkout step takes a worker. When all workers are busy, new requests queue, and shoppers see spinning buttons. That queue is the plain answer to why is WooCommerce slow only at peak times.
The WooCommerce documentation says the cart, checkout and my account pages must stay out of the cache because they show customer-specific data. That makes WooCommerce checkout slow the first symptom when workers run out, long before the home page suffers.
Ask your host for the worker count in writing. For reference, our WP Growth plan includes 4 PHP workers, Commerce reserves 6 for checkout and Commerce Scale reserves 10. Our guide to WooCommerce hosting requirements explains how to match workers to orders.
That is also why WooCommerce checkout slow complaints spike during sales. A second cause lives in your own site: a slow external call, such as a shipping rate lookup, holds a worker for its whole duration. Fewer workers are tied up when each request finishes sooner, so fixing the slow call can be as good as buying more workers.
Check that page caching skips only what it should
Asking why is WooCommerce slow on catalog pages often ends here. Caching is the cheapest way to speed up WooCommerce catalog pages. It helps product pages, categories and the home page. It must not touch cart, checkout or account pages. The WooCommerce caching guide also lists cookies such as woocommerce_cart_hash, woocommerce_items_in_cart and wp_woocommerce_session_ that cache rules should respect.
Two mistakes appear often. Either the cache is off for the whole site, so every product page hits PHP, or it is on for pages it should skip, which leaks one shopper’s cart to another. Test both in a private window: add an item, then check that the cart page is not served from cache and that a category page is.
If you run a CDN, confirm its rules match the server rules. A CDN set to cache everything causes odd cart behavior.
Add a WooCommerce object cache
This is where a WooCommerce object cache pays off. The WordPress optimization guide says a persistent object cache speeds up page loads by saving trips to the database. Page caching cannot help carts and sessions, but an object cache can, because it keeps repeated query results in memory.
The usual choice for a WooCommerce object cache is Redis. You need two things: the service running on the server and a plugin or drop-in that connects WordPress to it. Our plans run a Redis object cache for carts and sessions, so that part is handled for you. On a self-managed server, plan to install and monitor both pieces.
After enabling it, retest the cart and checkout, since a slow WooCommerce cart is where this change shows up first. Compare your before and after numbers. If nothing changed, the bottleneck is elsewhere on this list.
Clean up database bloat: transients, sessions and orders
A WooCommerce database grows in three places that are easy to forget.
Transients are temporary cached values. Expired ones should be removed, but plugins that misbehave leave them behind. Sessions hold cart data for visitors, and WooCommerce documents a session cookie that lasts 2 days, so a busy store creates many session rows. Orders and their metadata build up for years.
WooCommerce has enabled High-Performance Order Storage (HPOS) by default for new installations since version 8.2. It moves orders out of the general posts tables into dedicated order tables with their own indexes. If your store started before that, check WooCommerce, Settings, Advanced, Features to see which storage you use, and plan a tested migration on staging.
Also check autoloaded options. The WordPress optimization guide suggests keeping them under 800 KB, since they load on every request. A large autoload set slows every page, cached or not.
Back up before any cleanup, test it on staging and delete in small batches. Our backup and disaster recovery service exists for exactly that safety net.
Audit heavy plugins and large images
Plugins are the most common site-side answer to why WooCommerce performance drops over time, and to why is WooCommerce slow on a store that used to be fast. Every active plugin adds PHP to run, queries to execute and often scripts and styles on every page.
Use Query Monitor on staging to rank plugins by query time and by the number of queries. Look for plugins that load their scripts on every page when they are needed on one. Replace or remove the worst offenders. If nobody can explain a plugin, test the store without it.
Images affect LCP directly. The WooCommerce performance guidance recommends compressing images and using lazy loading. Serve modern formats such as WebP, size images to the space they fill, and do not lazy-load the main image above the fold, because that delays LCP.
Themes matter too. A heavy page builder layout adds CSS and JavaScript to a product page, and that cost lands on the visitor’s device, where INP is measured.
Check WP-Cron and the Action Scheduler backlog
WordPress developer documentation explains that WP-Cron checks its list of scheduled tasks on every page load. It does not run on a clock. On a quiet store, tasks run late. On a busy store, the check itself adds work to many requests.
Background work is a quiet answer to why is WooCommerce slow after launch. WooCommerce relies on a job queue called Action Scheduler for background work such as emails, subscription renewals and webhooks. The Action Scheduler documentation says it attaches to WP-Cron and tries to run every minute, processing batches of 25 actions up to 30 seconds. If WP-Cron is unreliable, the queue falls behind.
Look at WooCommerce, Status, Scheduled Actions. A large pile of Pending or Past-Due actions means jobs are not finishing. Failed actions need a look at their logs, since one broken integration can create thousands of retries.
The WordPress documentation shows how to add define( ‘DISABLE_WP_CRON’, true ); to wp-config.php and call wp-cron.php from the system scheduler instead. Do both steps or neither: disabling WP-Cron without a real scheduled job stops your background tasks entirely.
Fixes in order of payoff to speed up WooCommerce
To speed up WooCommerce, work through this order. It puts the changes with the biggest effect and lowest risk first.
| Order | Fix | Best for |
|---|---|---|
| 1 | Confirm PHP workers and PHP 8.3 or newer | Slow checkout under load |
| 2 | Page cache with cart, checkout and account excluded | Slow catalog pages |
| 3 | Persistent object cache such as Redis | Slow cart and admin |
| 4 | Remove or replace the heaviest plugins | Slow everywhere, high query counts |
| 5 | Compress images and fix LCP | Poor LCP on product pages |
| 6 | Clean transients, sessions and autoload | Slow admin, large database |
| 7 | Fix WP-Cron and clear the Action Scheduler queue | Late emails and renewals |
If the first three steps are limits your plan cannot lift, you have a host problem, and slow WooCommerce pages will persist until the plan changes. Our WooCommerce hosting plans list worker counts and Redis caching openly, and a person migrates your store for free. Our managed WooCommerce hosting guide compares options, or send your numbers through the contact page.
If the answer to why is WooCommerce slow turns out to be the site, a developer can profile the store and clean it up. See our e-commerce development work for that.
Frequently asked questions
Why is WooCommerce slow at checkout?
Checkout cannot be page cached, so each step uses a PHP worker and database queries. A shortage of workers, a missing object cache, slow shipping or tax lookups, or heavy plugins are the usual causes.
Does WooCommerce need an object cache?
It is not required, but it helps carts, sessions and the admin, where page caching cannot. WordPress documentation says a persistent object cache saves trips to the database.
How can I tell if my host is the problem?
For why is WooCommerce slow questions, a simple rule helps. If a plain static page is slow, or the site slows at predictable busy hours, the host is the likely cause. If only dynamic pages or certain plugins are slow, the site is more likely at fault. Ask the host for worker counts and resource limits, and to speed up WooCommerce only where the limit is real.
What is a good Core Web Vitals score for a store?
web.dev sets good thresholds at 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS, at the 75th percentile of page loads. Measure product, cart and checkout pages separately.
Can WP-Cron make WooCommerce slow?
Yes. WP-Cron checks scheduled tasks on page loads, and a backed-up Action Scheduler queue can delay emails and renewals. Moving to a system cron job, with DISABLE_WP_CRON set, makes timing predictable.
Sources
- web.dev, Web Vitals (LCP, INP and CLS thresholds)
- web.dev, Largest Contentful Paint
- web.dev, Interaction to Next Paint
- web.dev, Cumulative Layout Shift
- WooCommerce developer docs, configuring caching plugins
- WooCommerce developer docs, performance optimization
- WooCommerce documentation, High-Performance Order Storage
- Action Scheduler documentation
- WordPress developer resources, optimization
- WordPress developer resources, hooking WP-Cron into the system task scheduler
Related reading: WooCommerce keeps crashing, WooCommerce hosting services guide and WordPress hosting cost.