Most advice on how to speed up WordPress WooCommerce stores is written as if a shop were a blog with a cart button. It is not. A blog page can be cached once and served to everyone. A WooCommerce store has pages that must never be cached (the cart, the checkout, the account area), a database that grows with every order, and a stack of extensions that all want to run code on every request.
That is why a store can pass a speed test on the homepage and still feel slow at the moment that matters: when a customer taps “Place order”.
This guide is about WooCommerce speed optimisation specifically. It lists seven fixes in the order we would apply them, with the reasoning behind each one so you can judge whether it applies to you. If you want the broader WordPress picture first (hosting, themes, images, CDN), start with our general WordPress speed optimization guide and come back here for the store-specific part.
Why a WooCommerce site is slower than a normal WordPress site
Three things make the difference, and understanding them tells you where to look first.
- Dynamic pages can’t be fully cached. Once a customer adds a product to the cart, their pages depend on a session. Cache the wrong page and customers see someone else’s cart or an empty one.
- More database work per request. Product queries, price and stock lookups, tax and shipping calculations, and order data all hit the database. Large catalogues and many variations make it worse.
- More code from more places. Payment gateways, shipping plugins, subscription tools, currency switchers, chat widgets and analytics all add PHP and JavaScript.
When we speed up a WordPress WooCommerce site, the order of attack follows from that: measure, fix the server basics, cache what can be cached, then reduce database and script work on the pages that cannot be cached.
1. Measure the pages that earn money before you speed up WordPress WooCommerce
Do not test only the homepage. Test one page of each type: homepage, category, product, cart and checkout. Use PageSpeed Insights for lab data and field data where it is available, and write down the numbers before you change anything.
Google’s Core Web Vitals give you three targets worth tracking: Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200 milliseconds, and Cumulative Layout Shift at or under 0.1. Also watch Time to First Byte, because a slow server response makes every other number worse.
Install Query Monitor on a staging copy. It shows slow database queries, which plugin caused them, and which hooks and HTTP calls take time. Most “mystery” slowness stops being a mystery in about ten minutes with this plugin.
2. Fix the server basics first
No plugin can rescue an under-powered server. Check these before anything else:
- PHP version. WooCommerce’s server requirements page lists the minimum and recommended versions, and as of writing it recommends a current PHP 8 release. Newer PHP versions are generally faster and are the only ones that still get security fixes.
- Database. The same page lists MySQL and MariaDB versions. Old database versions are slower and unsupported.
- Memory. WooCommerce recommends a WordPress memory limit of at least 256 MB.
- Hosting type. Cheap shared hosting that packs hundreds of sites onto one server often shows a slow Time to First Byte under load. If your TTFB is high even on a cached page, the host is the bottleneck, not WordPress.
Always test an upgrade on a staging copy first, because older plugins and themes may not work with a newer PHP version.
3. Use page caching, with the right WooCommerce exclusions
Page caching is the biggest single win for catalogue pages, and it is safe when it is configured for WooCommerce. The rules are simple:
- Cache the homepage, category pages, product pages, blog posts and static pages for visitors who are not logged in and have an empty cart.
- Never cache the cart, checkout and My Account pages. A good caching plugin or host excludes them automatically, but check.
- Bypass the cache for visitors who have WooCommerce cart or session cookies, such as
woocommerce_items_in_cartandwp_woocommerce_session_. Without this, a visitor with items in the cart can be served a cached page that does not show them. - Purge on stock and price changes so customers don’t see products as available when they are sold out.
After setup, test by adding a product to the cart in a private window, then browsing to another page and back. The cart must still be correct.
4. Add an object cache
Page caching cannot help the pages that must stay dynamic. An object cache (Redis or Memcached, if your host offers it) stores the results of repeated database queries in memory so WordPress does not run them again on every request. On a store this helps the cart, checkout, account pages, the admin area and any page served to a logged-in customer. Ask your host whether Redis is available, and install a compatible object-cache plugin. Check the result with Query Monitor: the number of queries per page should fall.
5. Turn on High-Performance Order Storage
By default, older WooCommerce stores keep orders inside the same tables as posts and pages. High-Performance Order Storage (HPOS) moves orders into dedicated tables with their own indexes. WooCommerce has enabled it by default for new stores since version 8.2, and existing stores can switch it on under WooCommerce, Settings, Advanced, Features. WooCommerce’s own HPOS documentation says it reduces table contention and helps stores scale.
Before you switch, check that every active plugin declares HPOS compatibility; WooCommerce disables the option if it finds one that does not. Run synchronisation, test on staging, and keep a backup. If you use a payment plugin, confirm its vendor supports HPOS.
6. Tame cart fragments and AJAX calls
Many themes show a mini-cart in the header. To keep it up to date, WooCommerce can run a background request to refresh the cart fragments, and on some themes that request fires on every page, even for visitors with an empty cart. Open your browser’s network tab on a product page and look for a request containing wc-ajax=get_refreshed_fragments. If it is slow or fires when it should not, you have three safe options.
- Use a theme or plugin that loads the mini-cart only when the cart has items.
- Remove the mini-cart from the header.
- Ask a developer to limit the script to the pages that need it.
Don’t remove it blindly, because a header cart count that never updates looks broken.
7. Reduce scripts on pages that don’t need them
Plugins tend to load their CSS and JavaScript everywhere. A review form script loading on the homepage, a slider script on the cart and three tracking tags on the checkout all cost time. The approach is:
- List every script and stylesheet with the Network tab or Query Monitor.
- Identify which plugin loads each one.
- Load it only on the pages where it is needed, using the plugin’s own setting or a small piece of code.
- Delay non-essential third-party scripts such as chat widgets and heat maps until after the page is interactive.
Be careful on the checkout: payment gateway scripts must load there. Always run a full test order after any script change.
What not to do when you speed up WordPress WooCommerce
- Do not chase a perfect score. A 100 on a synthetic test with a broken checkout is worse than an 85 with a smooth one.
- Do not stack caching plugins. Two page-cache plugins fight each other and cause strange bugs.
- Do not minify or combine everything blindly. Aggressive script combining can break the cart and the payment page.
- Do not skip staging. Test every change on a copy before you touch the live store.
- Do not forget mobile. Most customers browse on phones, so test with mobile settings and a throttled connection.
A speed checklist for WooCommerce
- Baseline measured on home, category, product, cart and checkout pages.
- PHP, database version and memory limit meet WooCommerce’s current requirements.
- Page caching on, with cart, checkout and account excluded.
- Cache bypass for WooCommerce cart and session cookies.
- Object cache enabled and verified.
- HPOS enabled and every plugin compatible.
- Cart fragments request checked.
- Product images sized, in WebP, with the main image not lazy-loaded.
- Unneeded scripts removed from pages that don’t use them.
- Database, autoloaded options and Action Scheduler reviewed.
- Checkout fields and scripts trimmed.
- Plugins audited and updated on a schedule.
If you work through this list and the store is still slow, the cause is usually a specific plugin, a heavy custom feature or the host, and a proper audit will find it faster than guessing.
Store still slow after the basics? Get a performance audit
We profile WooCommerce stores end to end: hosting and TTFB, slow queries, plugin and script cost, caching rules, Core Web Vitals and the full checkout journey, then fix what actually matters.
Frequently Asked Questions
How do I speed up a WordPress WooCommerce site?
Measure your key pages first, then fix the server basics, enable page caching with WooCommerce exclusions, add an object cache, turn on HPOS, optimise images, remove unneeded scripts and clean the database. Test every change on a staging copy before touching the live store.
What is the best WooCommerce speed optimisation plugin?
There is no single best plugin. A good caching plugin or host-level cache, an image optimiser and Query Monitor for diagnosis cover most needs. Avoid running more than one page-cache plugin at the same time.
Should I cache the WooCommerce cart and checkout?
No. Those pages depend on the customer’s session. Caching them can show wrong cart contents or break payments. Cache catalogue and content pages and keep the cart, checkout and My Account pages dynamic.
Does HPOS make WooCommerce faster?
HPOS stores orders in dedicated tables with their own indexes, which WooCommerce says improves scalability and reduces contention as order volume grows. Check that all your plugins support it before enabling it on an existing store.
