How to Fix a Slow WooCommerce Cart Page

By the MyWebsiteScore team · Updated Nov 3, 2026

A slow WooCommerce cart page is a conversion killer. Shoppers who've already decided to buy hit a spinner and leave. The cart is also one of the hardest pages to speed up because it's dynamic — it can't be cached like a blog post. This guide walks through the most common causes of a sluggish WooCommerce cart and checkout, and the fixes that actually move the needle.

Why the cart page is slow in the first place

WooCommerce cart and checkout pages are typically excluded from full-page caching because they contain session-specific data (cart contents, customer info, nonces). That means every visit runs PHP, queries the database, and loads a stack of scripts. The result: slow server response, render-blocking assets, and a poor Largest Contentful Paint (LCP) score — often well above the 2.5-second "good" threshold.

Before you touch anything, measure. Run your cart page through a free audit to get a baseline: run a free audit and note the LCP, INP, and CLS scores plus the server response time. Fixing blind is how people waste weekends.

Fix 1: Stop loading cart scripts on every page

WooCommerce enqueues cart-related JavaScript and CSS site-wide by default. On a content-heavy site, that's dead weight on every page. Use a plugin or a small snippet to dequeue WooCommerce cart scripts on pages that don't need them (homepage, blog, static pages).

• Check your theme's functions.php or a site-specific plugin.
• Target woocommerce.js, cart-fragments.js, and wc-cart-fragments specifically.
• Test the cart and mini-cart after each change — AJAX cart updates depend on these scripts.

Fix 2: Disable cart fragments where they aren't needed

wc-cart-fragments.js keeps the mini-cart in sync via AJAX on every page load. It's useful on shop and product pages, but unnecessary on static content. Disabling it on non-WooCommerce pages cuts a request and a script parse on every visit.

If your theme uses a mini-cart in the header, keep fragments on product and shop pages but disable them elsewhere. This is one of the highest-leverage changes for sites with a large blog.

Fix 3: Cut plugin bloat on cart and checkout

Every plugin that hooks into the cart adds queries and scripts. Common culprits:

• Upsell/cross-sell plugins that query the product database on every cart load.
• Loyalty and rewards plugins that call external APIs synchronously.
• Multiple shipping or tax calculators running on page load.
• Page builders loading their full CSS/JS on the cart template.

Audit your active plugins on the cart page using Query Monitor (a free WordPress plugin) to see which queries and hooks fire. Disable anything non-essential on cart and checkout, and test the purchase flow end to end.

Fix 4: Reduce render-blocking CSS and JS

The cart page often inherits the full theme stylesheet plus WooCommerce styles. That's a lot of CSS for a form. Options:

• Generate critical CSS for the cart template and defer the rest.
• Use a performance plugin to defer non-critical JavaScript (but exclude WooCommerce checkout scripts — deferring them can break payment).
• Remove unused WooCommerce styles on the cart page if your theme already styles it.

Be conservative: the checkout is the one place where aggressive optimization breaks payments. Change one thing, test a real order, then move on.

Fix 5: Speed up server response time

The cart page can't be cached, so server response time (TTFB) matters more here than anywhere else. If TTFB is over 600ms, look at:

• Hosting: shared hosting often struggles with WooCommerce. A host with object caching (Redis or Memcached) and PHP 8+ makes a measurable difference.
• Database: clean up expired transients and orphaned cart sessions. WooCommerce stores abandoned carts in the database; large tables slow every query.
• Object caching: enable a persistent object cache so repeated cart queries hit memory, not disk.

Fix 6: Tame the cart's images and fonts

Product thumbnails in the cart are often served at full resolution. Serve them at the exact size rendered (typically 64–100px), use WebP or AVIF, and add explicit width and height attributes to prevent layout shift (CLS). Also check that web fonts aren't loading a full family just for the cart — subset or use system fonts on checkout forms.

Fix 7: Keep third-party scripts off the cart

Analytics, chat widgets, heatmaps, and marketing pixels all fire on the cart page. Each one adds main-thread work that hurts Interaction to Next Paint (INP) — the metric that replaced First Input Delay. INP should be 200ms or less. On the cart, every click (quantity change, coupon, checkout button) must feel instant.

• Load chat and heatmap scripts after user interaction, or exclude them from cart and checkout entirely.
• Defer analytics until after the checkout button is interactive.
• Remove any pixel you can't justify on the purchase path.

A quick pre-fix checklist

Before you start changing code, confirm the following:

• You've measured the cart page in isolation, not just the homepage.
• You have a staging site and a test payment gateway.
• You've noted which plugins are active on cart and checkout.
• You know your current TTFB, LCP, INP, and CLS numbers.

After each fix, re-test a real order. A faster cart that can't complete a purchase is worse than a slow one.

When to stop optimizing and start re-platforming

If you've done the above and the cart still lags, the bottleneck may be your host or a legacy theme. At that point, compare the cost of a managed WooCommerce host or a lighter theme against the revenue you're losing at checkout. For more diagnostic walkthroughs, see the guides library.

Start with measurement, fix the biggest script offender first, and verify with a real purchase. That sequence solves most slow WooCommerce carts.

More guides · Compare audit tools · Run a free website audit