How to Speed Up WooCommerce: Causes and Fixes (2026)

Cart fragments are the WooCommerce feature that keeps the mini-cart in the header in sync as the customer adds items. Every WooCommerce page load fires an uncached POST request to `/?wc-ajax=get_refreshed_fragments`, which boots WordPress, loads WooCommerce, hydrates the session, and returns a small JSON blob with the updated cart HTML.

Because it is a POST request, it bypasses every page cache and CDN edge cache. On a slow host, a single fragments call can take 400-1200 ms and it happens on every visit to every page, homepage, blog posts, contact, and every cart or checkout page alike. It is the number one reason "my WordPress blog is fast but WooCommerce is slow."

How to diagnose. Open a product or homepage in an incognito Chrome window with DevTools > Network > Fetch/XHR open and filter for `admin-ajax` or `wc-ajax`. If you see a `get_refreshed_fragments` request on every page load with a response time above 300 ms, this is your biggest single win. Cross-check in Query Monitor by loading `?wc-ajax=get_refreshed_fragments` directly: the query count and PHP time it reports is what runs on every visit.

Fix summary. The right fix depends on how prominent the mini-cart is in your header and how important "add to cart" flows are on non-shop pages. Options range from restricting fragments to cart-relevant pages, to caching the fragment response, to replacing the mini-cart with a lightweight cookie-based counter. This is the highest-ROI single change on most WooCommerce sites, and it is one of the first things covered in our WooCommerce speed optimization service.

WooCommerce core is relatively lean. The problem is that no real store runs only core. A typical WooCommerce site stacks a payment gateway (Stripe, PayPal, Square), a shipping calculator (ShipStation, Table Rate, live carrier rates), tax handling (Avalara or TaxJar), a subscriptions or memberships plugin, an abandoned cart recovery plugin, a marketing suite (Mailchimp, Klaviyo, HubSpot connector), a reviews plugin, and product add-ons. Each one loads on every request WooCommerce touches, and many register their own admin-ajax endpoints that fire on the front-end. The result shows up in the field: the median WooCommerce mobile page now ships 830 KB of JavaScript (CrUX via HTTP Archive, May 2026), most of it from stacked extensions rather than core.

How to diagnose. Install Query Monitor and load a product page while logged in as admin. Look at the Queries by Component panel: the top three or four plugins by query count and query time are your candidates. Then check Scripts and Styles for plugins loading assets on pages they do not need (a subscription plugin has no business loading on the About page).

Fix summary. The rule is site-wide vs page-scoped. Payment, shipping, and tax plugins should only load on cart, checkout, and account pages. Marketing and add-on plugins should be scoped to the templates that actually use them. This is done with conditional dequeueing (Perfmatters, Asset CleanUp, or a small mu-plugin). For the underlying WordPress plugin discipline that applies here, see why is WordPress so slow.

A cheap shared host can serve a WordPress blog well because 95% of requests are cached HTML. WooCommerce breaks that assumption: cart, checkout, my-account, and cart-fragment requests must all bypass the page cache and hit PHP and MySQL on every request. Object caching (Redis or Memcached) is often unavailable on entry-level shared plans, so every uncached request re-runs the same expensive queries. The scale of this problem is visible in the field data: only 40.1% of WooCommerce origins pass Core Web Vitals on mobile and only 13.8% have a good mobile TTFB (CrUX via HTTP Archive, May 2026), and hosting is the single largest reason for that gap.

How to diagnose. Open Chrome DevTools > Network on `/cart/` or `/checkout/` and look at the TTFB (Waterfall > Timing > Waiting for server response). Consistently above 800 ms on an idle cart with a couple of items is a hosting problem, not a plugin problem. Confirm by loading the same page from a second location or a headless test - if TTFB is uniformly bad, the origin is the bottleneck.

Fix summary. Move to a host with Redis or Memcached object caching enabled, PHP 8.2+, and NVMe storage, and confirm the plan actually gives you dedicated CPU/RAM rather than shared. For guidance on which hosts handle WooCommerce well, see the fastest WordPress hosting comparison. Full-page caching is still worth having for catalog pages; the best WordPress cache plugin guide covers which ones handle WooCommerce exceptions correctly.

WooCommerce writes a lot. Every order creates rows across `wp_wc_orders`, `wp_wc_order_stats`, order items, and order meta. Every guest session creates a `_wc_session_` transient in `wp_options`. Every scheduled task (email queues, subscription renewals, integration syncs) runs through `wp_actionscheduler_actions` and `wp_actionscheduler_logs`. On a store more than a year old, these tables routinely hold hundreds of thousands to millions of rows, and every uncached WooCommerce request queries them.

The worst offender is often autoloaded options: expired sessions and transients that were never cleaned up sit in `wp_options` with `autoload = yes`, so they are pulled into memory on every single request across the entire site, cached or not.

How to diagnose. In Query Monitor, sort queries by time and look for slow queries against `wp_options`, `wp_actionscheduler_`, and `wp_wc_`. Then run this in phpMyAdmin: `SELECT SUM(LENGTH(option_value))/1024/1024 AS autoload_mb FROM wp_options WHERE autoload = 'yes';`. Above 1 MB is a problem; above 3 MB is severe.

Fix summary. Clean up expired transients and sessions, purge completed and failed Action Scheduler logs older than 30 days, and stop treating rarely-read options as autoload. The full playbook is in our guide on how to clean up your WordPress database.

The product page is the single most important URL in a WooCommerce store, and it is the one most often built with a page builder. Multipurpose themes like Avada, Flatsome, Divi and Elementor-based builds routinely add 300-800 KB of extra CSS and JavaScript to product pages, on top of everything WooCommerce and its extensions already load. That extra weight lands on the URL where LCP and INP matter most for conversion.

How to diagnose. Run PageSpeed Insights on a representative product page in incognito. In the Chrome DevTools Coverage tab (Ctrl+Shift+P > Show Coverage), reload the product page and sort by unused bytes: builder CSS files and animation libraries at the top are your target.

Fix summary. Rebuild the product template with native block editor patterns or a lightweight theme's product template, keeping the builder for marketing pages only. On budget-constrained projects, aggressive conditional loading of the builder's assets is a partial fix. If you are still on a multipurpose theme, see the field-data ranking in our WordPress theme comparison work for a shortlist of leaner options.

Product photography that came straight from a DSLR or a supplier catalog is usually 2-5 MB per image and 3000+ pixels wide. WooCommerce will resize it for display, but the original still sits on disk and is served whenever the gallery lightbox opens. Multiply that by five images per product across a category page and LCP goes from 1.5 s to 4-6 s on mobile. Field data backs this up: the median WooCommerce mobile page ships 1,113 KB of images (CrUX via HTTP Archive, May 2026), the heaviest image payload of any major WordPress-based platform in the report.

How to diagnose. In DevTools > Network > Img, load a product page and sort by size. Anything above 200 KB for a product image is unnecessary in 2026. Also check whether images are served as WebP or AVIF (the Type column shows the format).

Fix summary. Convert to WebP or AVIF, generate proper responsive image sizes, and enforce a max upload dimension so future uploads do not repeat the problem. The full pipeline is in our WordPress image optimization plugin guide.

Before changing anything, run this three-tool check to know which cause is actually yours.

Query Monitor (backend cost). Install the plugin, load a product page while logged in as admin. Read: total query count, total query time, top plugins by query time, and any queries flagged red. If a single plugin owns more than 30% of query time, it is your primary target.

Chrome DevTools Network tab (front-end cost). Open an incognito window, open DevTools > Network, filter for `admin-ajax` or `wc-ajax`, and reload the homepage (not the cart). If you see `get_refreshed_fragments` above 300 ms on every page, cart fragments are your primary target regardless of what Query Monitor shows.

PageSpeed Insights on a product page. Run PSI in incognito on a representative product URL (not the homepage) and read the field data. Failing LCP usually points to hosting or images; failing INP usually points to plugin JavaScript.

These three signals together will tell you which of the six causes above is doing the most damage on your specific store.

A slow WooCommerce checkout costs more than any other slow page, because it's where buyers decide to finish or leave. Checkout can't be served from the page cache: every load runs PHP, reads the customer's session and cart, calculates shipping and taxes, and loads payment gateway scripts. Anything that hooks into those steps adds time.

Why Is WooCommerce Checkout So Slow?

When a WooCommerce checkout is very slow, the usual causes are live shipping-rate API calls on every update, payment gateway and fraud scripts from several providers loading at once, checkout field and upsell plugins hooking into each recalculation, sessions stored in a bloated wp_options table, and hosting with too few PHP workers to handle uncached requests.

How to Fix a Slow WooCommerce Checkout Page

1. Profile one checkout load with Query Monitor and note the slowest queries and HTTP API calls.
2. Load payment scripts only where they're needed, and remove gateways you no longer offer.
3. Cache shipping rates where your shipping plugin supports it, and cut carrier calls you don't use.
4. Remove or replace checkout add-ons that recalculate the cart on every field change.
5. Add a persistent object cache (Redis or Memcached) so sessions and options aren't re-read from MySQL on every request.
6. Enable High-Performance Order Storage (HPOS) so orders live in dedicated tables instead of post meta.
7. Check PHP workers and PHP version with your host. Checkout traffic is uncached by definition, so it's the first place a small plan runs out of capacity.

A slow WooCommerce admin is a backend problem, separate from front-end speed, and you speed it up by cutting the work each admin page does. Admin pages are never page-cached, so every click in a WooCommerce slow backend runs the full PHP and database cycle, plus whatever each plugin adds to the dashboard.

The common causes are an Action Scheduler table with tens of thousands of completed or failed actions, large autoloaded options, analytics and reporting jobs running in the background, plugin dashboards and notices that query on every page, and the WordPress Heartbeat API firing frequently while editors work.

The fixes, in order: clear old completed and failed scheduled actions, trim autoloaded options, add a persistent object cache, enable HPOS, slow the Heartbeat interval in the admin, and deactivate plugins whose dashboards you never use. Our guide on how to clean up your WordPress database covers the cleanup steps in detail.

Use this WooCommerce speed optimization checklist to speed up a WooCommerce store in the order that usually pays off most:

1. Host on WooCommerce-capable infrastructure with enough PHP workers, PHP 8.x and a persistent object cache.
2. Fix cart fragments so the cart request only runs when the cart has items or on cart and checkout pages.
3. Use a page cache that understands WooCommerce, with cart, checkout and my-account excluded.
4. Audit plugins by query cost, not count, and remove anything that loads on pages it doesn't need.
5. Clean the database on a schedule: sessions, transients, Action Scheduler logs and revisions.
6. Optimize product images (WebP or AVIF, correct sizes) and lazy load below-the-fold galleries.
7. Keep product pages light: avoid heavy page-builder layouts on the template that matters most.
8. Watch large variation counts: past a threshold, WooCommerce fetches variation data by AJAX as shoppers choose options, so products with hundreds of variations need testing on real devices.
9. Measure field data (Core Web Vitals from real users) after each change, not just lab scores.

Do You Need a WooCommerce Speed Up Plugin?

A good caching plugin is the closest thing to a WooCommerce speed plugin, and most stores need one unless their host provides server-level page caching. Pick one that handles WooCommerce exclusions correctly; our comparison of the best WordPress cache plugin covers which do. No plugin fixes hosting limits, plugin bloat or checkout API calls, which is why the checklist above matters more than any single install.