A WooCommerce store is a different machine from a WordPress marketing site. It writes to the database on every cart action, keeps sessions for every visitor, and can’t fully cache its most important pages. That’s why a store that follows every generic speed guide can still crawl.
For e-commerce, speed is revenue arithmetic: stores with poor Core Web Vitals see cart abandonment spike by up to 40%, and every second of load time costs roughly 7% in conversions. Here are the nine causes we find over and over in store audits, and what fixes each one.
1. Cart fragments AJAX on every page
WooCommerce updates the little cart icon via an AJAX call (wc-ajax=get_refreshed_fragments) that fires on every page load, bypasses all caching by design, and hits your server even when the visitor is reading a blog post. On busy stores it’s routinely the single biggest source of server load.
Fix: Disable cart fragments on non-shop pages (a small code snippet or the ‘Disable Cart Fragments’ plugin) and let the cart count populate on cart interaction instead. Test add-to-cart behavior afterward.
2. Cart, checkout, and account pages can’t be page-cached
Page caching is the backbone of WordPress speed, and your three most conversion-critical pages are excluded from it by necessity: they’re personalized. Those pages hit PHP and the database on every single view, so their speed is a direct function of your hosting and code quality. This is why stores feel fast until someone starts buying.
Fix: You can’t cache them, so make the uncached path fast: PHP 8.2+, Redis object caching so repeated queries come from memory, and hosting with enough headroom (see #3).
3. Shared hosting under a database-heavy application
WooCommerce writes sessions, cart contents, and order data continuously. Shared hosting throttles exactly the resources this needs: database I/O and PHP workers. During a promotion, queued requests turn into 8-second checkouts, at the moment maximum money is on the line.
Fix: Managed WooCommerce hosting (WP Engine, Kinsta, Nexcess) sized for your traffic, with Redis and enough PHP workers for concurrent checkouts. This is the highest-ROI infrastructure dollar a store spends.
4. Product images at camera resolution
Product photography is the biggest asset weight on any store. A catalog uploaded straight from the photographer, 4,000-pixel JPEGs on category pages showing 24 products, transfers tens of megabytes per page view.
Fix: Automatic WebP conversion and compression on upload (Imagify or ShortPixel), correct srcset sizing so phones get phone-sized images, and lazy loading below the fold.
5. Variation-heavy products making expensive queries
A product with 40 variations (sizes × colors) makes WooCommerce assemble price, stock, and attribute data for every combination. Category pages full of variable products multiply that work. Stores with large variable catalogs on default settings spend most of their TTFB in these queries.
Fix: Redis object caching helps immediately. For big catalogs, restructure where possible (fewer variations per product) and consider ElasticPress or FacetWP for category filtering instead of raw WP_Query.
6. Session and transient bloat in the database
WooCommerce creates a session row for every visitor with a cart, and expired sessions plus orphaned transients accumulate. We’ve audited stores whose options and sessions tables were gigabytes, slowing every query on the site including the autoloaded ones that run on init.
Fix: Schedule cleanup of expired sessions and transients (WP Rocket’s database feature or WP-Optimize), and check autoloaded options size, over ~1MB autoloaded is a problem worth fixing.
7. Every plugin loading everywhere
Store plugin stacks grow: reviews, wishlists, size guides, popups, feeds, analytics. Most load their CSS and JavaScript on every page, including checkout, where every extra script is measurable abandonment risk.
Fix: Audit with Query Monitor, remove overlap, and conditionally load page-specific plugins. Keep checkout as close to script-free as the stack allows. Our 12-plugin production stack is the shape to aim for.
8. Payment and shipping plugins calling external APIs synchronously
Live shipping rates and some payment gateways call external APIs while the customer waits. A slow carrier API adds 2-4 seconds to checkout at the worst possible moment, and you’ll never see it in a PageSpeed test because it only happens mid-purchase.
Fix: Cache shipping rate responses where the plugin allows, use table rates for standard domestic tiers, and monitor checkout timing specifically (not just homepage scores).
9. No object cache behind a dynamic store
Everything above compounds without object caching. Redis keeps repeated query results in memory, which is the single biggest lever for the uncacheable cart-checkout-account path that actually processes your revenue.
Fix: Enable Redis (one click on good managed hosts) and verify WooCommerce sessions are covered. TTFB improvements of 30-50% on dynamic pages are typical.
Where to start
Don’t guess. Measure TTFB on your checkout page specifically, not your homepage. If it’s over 600ms, start with hosting and Redis (#3, #9). If the homepage is heavy but TTFB is fine, it’s images and scripts (#4, #7). We took one coffee store from 8.2s to 1.1s with exactly this sequence, and checkout conversion rose 38%.
Get your store’s speed audited by specialists.
We measure the pages that make you money, not just the homepage, and send a prioritized fix list with before/after projections. Free, within 2 business days.
