Why Your WooCommerce Store Is Slow
A slow WooCommerce store usually has a WooCommerce cause, even when the symptoms look like a general WordPress speed problem. Product pages may load quickly from a cache while the cart, checkout and account pages crawl, or the whole store may slow down as orders and products pile up in the database. Working out which of those patterns applies is the starting point for any work on WooCommerce development for growing online stores, because the fix for each one is different.
General WordPress causes such as heavy themes, unoptimised images and slow plugins affect stores too. They are covered in why a WordPress website is slow and how to fix it. The sections below stick to the causes that only an online shop has, from cart fragments and sessions to order storage, scheduled actions and the hosting a busy store needs.
What Makes a WooCommerce Store Slow
A WooCommerce store is slow when the server has to build pages for each shopper that a normal WordPress website would serve from a cache, or when the database and background tasks behind the store grow faster than the hosting can handle. A brochure website shows every visitor the same page, so most of it can be cached. A shop holds a cart, a session and an account for each customer. Those parts have to be worked out fresh on every request.
The WooCommerce specific causes are listed below. Many slow stores have more than one of them at the same time.
- Cart fragments requests that refresh the mini cart on pages that do not need it
- Cart, checkout and account pages that cannot be cached and run slowly on every visit
- Customer sessions stored in the database and caching rules that break them
- Variable products with large numbers of variations and slow product filters
- Order data held in the old posts tables rather than High Performance Order Storage
- Large catalogues, product imports and database tables that keep growing
- A backlog of scheduled actions run by WordPress cron on visitor page loads
- Payment and shipping plugins loading scripts or calling outside services on every page
- Hosting without the PHP version, memory or object caching a store needs
Each cause leaves a different trace. A store that is slow only at checkout points to a different problem from one whose admin screens take seconds to load, so measuring before changing anything saves time.
How to Find What Is Slowing Your Store
The quickest way to find the cause is to compare a cached page with an uncached one and then look at what the server is doing on the slow pages. Google’s guidance on Core Web Vitals sets the targets stores are judged against, with Largest Contentful Paint within 2.5 seconds and Interaction to Next Paint under 200 milliseconds.
Time to First Byte shows how long the server takes to start sending a page, which is where server side WooCommerce problems show up. The web.dev article on Time to First Byte treats 0.8 seconds or less as good and anything over 1.8 seconds as poor, although it is not a Core Web Vitals metric itself.
-
1
Test a Product Page
Run a product page through a speed test while logged out. It is normally served from the page cache, so it shows the best case for the store.
-
2
Test the Cart and Checkout
Add an item to the basket and time the cart and checkout pages. These pages skip the cache, so a large gap points to server or database work.
-
3
Profile the Slow Page
Load the slow page as an administrator with a profiling plugin active. It shows the database queries, scripts and outside requests behind the delay.
-
4
Check the Background Queue
Open the Scheduled Actions screen under WooCommerce Status. A long list of pending or failed actions means background work is competing with shoppers.
The Query Monitor plugin on WordPress.org suits the third step. It reports slow, duplicate and erroneous database queries and groups them by the plugin or theme responsible, which makes a misbehaving extension easy to spot. Front end problems such as images and layout shift that show up in the same tests are covered in WordPress Core Web Vitals optimisation.
Cart Fragments and Session Handling
Cart fragments are a WooCommerce script that keeps the mini cart in the header up to date by asking the server for fresh cart contents in the background. The WooCommerce developer blog post on the cart fragments API explains that until WooCommerce 7.8 the script loaded on every page of a store, even where no mini cart was shown, which added extra requests and could severely affect server load on busy stores.
Since version 7.8 the script only loads where the cart widget is rendered, but some themes build that widget into every page template, so the script can still run everywhere. WooCommerce suggests two fixes, limiting the script to shop, cart and checkout pages with a filter or replacing the mini cart widget with the Mini Cart block, which does not use cart fragments.
Either change needs testing, because the same post warns that a mini cart widget shown on every page of a cached store may stop showing the shopper’s real cart contents. Third party scripts that list cart fragments as a dependency will also pull the script back in.
Sessions are the other half of the cart. WooCommerce sets a cookie called wp_woocommerce_session_ that lasts two days and holds a unique code pointing to each customer’s cart data in the database.
Caching that ignores sessions causes slowdowns and broken carts together. The WooCommerce guide to configuring caching plugins says a caching system with database caching may need _wc_session_ excluded from it. The same guide lists the WooCommerce cookies that can be excluded from the page cache.
Why Cart, Checkout and Account Pages Are Slow
Cart, checkout and account pages are slow because they cannot come from the page cache, so PHP and the database build them from scratch for every shopper. The WooCommerce caching guide says the Cart, My Account and Checkout pages must be excluded from caching because they show information specific to the current customer and their cart.
That makes these pages the true test of a store’s hosting. A host can make a cached product page look fast, while the checkout reveals how quickly the server runs WooCommerce, the payment plugin and any shipping or tax calculations.
| Cookie | What It Does | How Long It Lasts |
|---|---|---|
| woocommerce_cart_hash | Helps WooCommerce tell when the cart contents change | Browser session |
| woocommerce_items_in_cart | Helps WooCommerce tell when the cart contents change | Browser session |
| wp_woocommerce_session_ | Holds a unique code linking the customer to their cart data in the database | Two days |
| woocommerce_recently_viewed | Powers the Recently Viewed Products widget | Browser session |
Most caching plugins and managed hosts exclude these pages already, but the rules are worth checking after any change of host or caching plugin. A cached My Account page can trap customers in a password reset loop, according to the WooCommerce guide. A cached cart is worse, because it can show one shopper’s basket to the next visitor.
Product and Variation Queries
Product pages slow down when a variable product has so many variations that working out the valid combinations takes longer than loading the rest of the page. The WooCommerce guide to the variation threshold explains that products with 30 or fewer variations update their dropdowns live as the shopper chooses options, while larger products switch to static dropdowns to protect performance.
The threshold can be raised with the woocommerce_ajax_variation_threshold filter, but WooCommerce advises choosing the lowest value that works, because higher values can affect product page performance. Products with hundreds of variations are often better split into separate products or rebuilt with a simpler option structure.
Shop filters cause the same kind of slowdown on category pages. Each combination of attribute, price and stock filters creates a new database query that is unlikely to be in the page cache, so a large catalogue with layered navigation can strain the database even when individual product pages are quick. Profiling those filter URLs shows whether a plugin is running unindexed or duplicate queries.
High Performance Order Storage
High Performance Order Storage, usually shortened to HPOS, speeds up stores with large order histories by moving orders out of the WordPress posts tables into tables built for them. The WooCommerce documentation on High Performance Order Storage explains that orders were traditionally stored as posts and post meta, which caused performance issues. HPOS moves them into four dedicated tables with their own indexes, so the database does fewer read and write operations and has fewer busy tables.
HPOS has been switched on by default for new installations since WooCommerce 8.2, released in October 2023. Older stores may still be running on the posts tables, which is worth checking first on any store with a long order history.
The WooCommerce guide to switching on HPOS starts with compatibility mode in the Features tab of the advanced WooCommerce settings, which copies orders between the two storage systems in the background through scheduled actions. Once both are in sync the store can switch to HPOS. WooCommerce advises keeping compatibility mode on for some time afterwards, because reverting to the posts tables can then be done instantly.
Plugins that read order data directly from the posts tables rather than through WooCommerce’s own functions may not work with HPOS. Test every extension on a staging copy of the store before the switch, paying particular attention to reporting, fulfilment and accounting integrations.
Large Catalogues and Database Growth
Large catalogues slow a store down when the database grows faster than the queries and indexes behind it were designed for. Products, variations and their details are still stored as WordPress posts and post meta, so a store with a very large number of variations puts heavy pressure on the same tables the rest of WordPress uses.
Imports and stock syncs make the problem worse when they run during trading hours. Bulk updates from a supplier feed or ERP system write to large numbers of rows at once. Many of those writes also clear cached product data that the next shoppers have to rebuild, so scheduling imports overnight keeps that work away from peak trading.
Old data adds to the load over time. Expired sessions, transients, completed scheduled actions and plugin logs collect in tables that are rarely cleaned. The WooCommerce System Status report lists the size of each database table, which shows where the growth is. Routine clean up is covered in WordPress database optimisation.
Scheduled Actions and WordPress Cron
Scheduled actions slow a store when the background queue falls behind and starts running its backlog while real shoppers are browsing. WordPress handles timed tasks through its cron system. The WordPress Plugin Handbook on cron explains that it checks for due tasks on every page load rather than running constantly.
WooCommerce uses the Action Scheduler library on top of that for jobs such as webhooks, emails and subscription renewals. It processes actions in batches of 25 until it has used 90% of the available memory or run for 30 seconds, then starts a new request to carry on, so a large backlog can tie up PHP workers that shoppers need.
The WooCommerce System Status documentation describes the Scheduled Actions tab as a log of background processes, with the status of each task and error details for any that failed. A long list of failed or pending actions from one hook usually points to a broken extension or an integration that can no longer reach its service. Fixing that source clears the backlog for good, whereas deleting the actions only hides it until the queue fills again.
Move WordPress cron off visitor page loads on a busy store. The handbook guide to hooking cron into the system task scheduler shows how to run wp-cron.php from a server cron job and turn off the page load trigger with DISABLE_WP_CRON.
Action Scheduler is started by WordPress cron by default, so it keeps working once cron runs from the server and processes the queue at a steady rate rather than in bursts tied to traffic. Stores with heavy background work, such as subscriptions or stock syncs, gain the most from the change.
Payment and Shipping Plugins
Payment and shipping plugins slow a store when they load their scripts on every page or call outside services while the shopper waits. The WooCommerce performance best practices for extensions ask developers to load scripts and styles only on pages where they are needed and to test stores with each extension switched on and off.
Each payment gateway brings its own JavaScript from the provider’s servers. Offering several methods at checkout means the page waits on several outside services. A gateway that loads its script on product and category pages also slows those pages down for no benefit, which is one reason to choose gateways with care, as set out in WooCommerce payment gateways for UK businesses.
Shipping plugins that fetch live carrier rates add a request to the carrier each time the cart total is worked out. A slow carrier response then shows up as a slow cart and checkout. Caching the rates or using table rates for common destinations removes most of that wait.
Priority Pixels builds as much functionality as possible into its WooCommerce stores as custom code alongside a clean codebase, because excessive plugins create conflicts and performance issues. Fewer extensions also means fewer scripts competing for time on the checkout page.
Hosting Resources for WooCommerce
WooCommerce needs more server resources than a brochure website because so much of a store runs as uncached PHP and database work. The WooCommerce server recommendations currently ask for PHP 8.3 or greater, MySQL 8.0 or MariaDB 10.6 or greater and a WordPress memory limit of at least 256 MB.
Shared hosting struggles when several shoppers check out at once, because each uncached request needs its own PHP worker and a share of the database. A persistent object cache helps with that load. The WordPress documentation on caching describes object caching with engines such as Redis or Memcached as moving data from expensive, slow retrieval to cheap, fast retrieval that persists between requests.
A store that has outgrown shared hosting needs its own PHP workers and memory, which is the subject of moving to VPS WordPress hosting. Priority Pixels sizes each server to the website after auditing the existing setup as part of its managed WordPress hosting, with a content delivery network and server caching keeping pages fast under load.
Which Fixes to Make First
Start with the fixes that cost least and touch the most requests, then work towards the changes that need development time. Checking the cart fragments behaviour, the caching exclusions and the PHP version takes minutes and can take a lot of load off a busy store.
The order below groups the work by effort. It moves from settings anyone with administrator access can check to changes that need a developer.
Cart Fragments and Caching
Confirm where the cart fragments script runs and check that cart, checkout and account pages skip the cache. These checks take minutes in the theme and caching settings.
PHP and Memory
Compare the PHP version and memory limit with the WooCommerce server recommendations. The System Status report shows the current values on one screen.
Background Queue and HPOS
Clear failed scheduled actions at their source and move WordPress cron to the server. Stores with long order histories should then plan the move to HPOS.
Variations, Filters and Plugins
Restructuring large variable products, rewriting filter queries and replacing heavy plugins change how the store is built. They belong in planned development work rather than a quick fix.
Speed also needs watching after it has been fixed. Plugin updates, new payment methods and growing order tables bring the same problems back over time, which is why a regular check of the slowest pages belongs in any WooCommerce maintenance plan.
A store that stays slow after these checks usually has its cause in theme or plugin code. Profiling the slowest requests and rewriting the code behind them is the remaining route, which is development work rather than configuration.
FAQs
How do you speed up a WooCommerce store?
Start by timing the cart and checkout pages as well as a cached product page, because the gap between them shows whether the problem sits on the server. The usual fixes are limiting cart fragments, checking cache exclusions, clearing the scheduled actions backlog, switching to HPOS and making sure the hosting meets the WooCommerce server recommendations.
Should the WooCommerce checkout page be cached?
The checkout, cart and My Account pages should never be served from a page cache, because they show information that belongs to one customer. Speed them up with faster hosting, an object cache and fewer scripts on the checkout instead.
Does turning off cart fragments break the mini cart?
Turning cart fragments off everywhere can stop a classic mini cart widget from updating when shoppers add products. Limiting the script to shop pages or replacing the widget with the Mini Cart block avoids that, but either change should be tested before it goes live.
Can WooCommerce handle a large number of products?
WooCommerce can run large catalogues when the hosting, database and code are set up for them. Stores with big catalogues need an object cache, efficient filter queries and imports scheduled outside trading hours, along with HPOS once order volumes grow.
How do you clear the cache in WooCommerce?
WooCommerce does not have a page cache of its own, so page caches are cleared in the caching plugin or the hosting control panel. WooCommerce data held in transients can be cleared from the Tools tab of the WooCommerce Status screen.
Co-Founder at Priority Pixels
Paul leads on development and technical SEO at Priority Pixels, bringing over 20 years of experience in web and IT. He specialises in building fast, scalable WordPress websites and shaping SEO strategies that deliver long-term results. He’s also a driving force behind the agency’s push into accessibility and AI-driven optimisation.
Nathan Yendle | 02/10/2026
