WooCommerce Speed Optimization: Catalog, Cart and Checkout

A WooCommerce store is two sites sharing one address. The catalog (home, categories, product pages) looks the same to every visitor and can be cached like a blog. The cart, the checkout and the account area differ for each customer and have to be built fresh on every request. Advice written for blogs speeds up the first half and can break the second.

WooCommerce speed optimization works when each half gets the treatment that suits it. This guide goes through the store in the order a customer does.

Which pages can be cached and which cannot

Sort the store's pages into four groups before you touch a setting. Home, category and product pages can be page-cached and served through a CDN. The cart, the checkout and the account area can never be, so they depend on PHP speed, an object cache and how few scripts they load. Search and filtered results are rarely cacheable, because every query is different. The admin and its order screens are never cached and depend on how orders are stored and whether background jobs are healthy.

WooCommerce marks the cart, checkout and account pages as uncacheable by defining DONOTCACHEPAGE, and caching plugins honor it. A server-level cache or a CDN cannot see a PHP constant, so there the rules have to be explicit: exclude those URLs, and treat the cookies WooCommerce sets for a customer with a cart (woocommerce_items_in_cart, woocommerce_cart_hash, wp_woocommerce_session_) the way its guide to configuring caching describes.

Then test like a customer. Add a product, browse a few pages and open the cart in a second browser. If the second browser shows the first one's cart, stop and fix the cache before doing anything else.

Catalog and product pages

With a page cache in front, most catalog views never reach PHP. The uncached build still matters for the first visitor after each purge and for crawlers working through thousands of URLs.

• Category pages. Keep products per page moderate. Sorting by price, rating or popularity and filtering by attribute rely on WooCommerce's lookup tables. If results look wrong or slow after an import, regenerate the product lookup tables under WooCommerce > Status > Tools. The attribute lookup table has its own settings under WooCommerce > Settings > Products > Advanced.
• Variable products. A product with hundreds of variations either prints a large block of variation data into the page or fetches it by AJAX on each selection. Where combinations are mostly decorative, restructure: fewer attributes that create variations, more that are plain options.
• Product images. Catalog thumbnails are the most requested files on a store. Match the thumbnail size to the grid, serve WebP or AVIF, and never let the grid load full-size gallery images. Sizes and formats are covered in our WordPress image optimization guide.
• Extras on the product page. Related products, upsells, recently viewed items, photo reviews and "bought together" widgets each add queries and often their own scripts. Keep the ones that sell.

Cart fragments and the header cart

Cart fragments are how classic WooCommerce themes keep the cart icon in the header correct on cached pages. A script calls ?wc-ajax=get_refreshed_fragments and the server returns the mini cart for that customer. The call cannot be cached and it loads most of WordPress, so on older setups every page view triggered an uncached PHP request, cart or no cart.

Current WooCommerce versions enqueue the wc-cart-fragments script only when the classic cart widget is on the page, and the Mini-Cart block does not use fragments at all. Themes and plugins can still force the script on everywhere. Look in the Network tab on a product page for the get_refreshed_fragments request. If it is there:

• find what enqueues it (the theme's header cart, a side cart plugin) and whether it has a lighter mode
• consider moving the header cart to the Mini-Cart block
• do not dequeue the script without a replacement, or the cart count sits at zero after an add to cart and customers think the button is broken

The WooCommerce developer blog explains the change in its cart fragments best practices.

Search and filtering

The default product search is a database LIKE query over titles and descriptions. It scans more rows as the catalog grows, it ranks results poorly, and no page cache can help because every query is different. Once the catalog is large, or customers search by SKU and attribute, move search to something with a real index: a search plugin that maintains its own index tables, or an external search service.

Filters need a decision as well. Every combination of attribute, price range and sort order is a distinct URL, and each is an uncached query. Crawlers will request all of them. Limit which filters produce crawlable links and block the rest in robots.txt, so bots do not occupy the PHP workers your customers need.

Checkout needs fewer scripts and fewer remote calls

Nothing on the checkout can be page-cached, so its speed is the plain speed of your PHP, your database and whatever the page waits for.

• Shipping and tax lookups. On the classic checkout each change of address sends an update_order_review request that recalculates totals, and the block checkout does the same through the Store API. If that calls a carrier's rate service or a tax service live, the customer waits for it every time. Make sure rates are cached per cart and address and that timeouts are short.
• Payment scripts. Gateway plugins often load their JavaScript on every page of the site. It belongs on the cart, the checkout and, with express buttons, the product page.
• Marketing scripts. Chat widgets, heatmaps and popups have no job on the payment step. Remove them there.
• Checkout add-ons. Field editors, address autocomplete, order bumps and fraud checks all hook into the same requests. Time the recalculation request in the Network tab with and without each.
• Optimization plugins. Exclude cart and checkout from JavaScript delay, combination and minification. A payment form that fails to load costs more than any millisecond saved.

A persistent object cache (Redis or Memcached) helps here more than anywhere else on the store, because options and product data are read on every one of these uncached requests.

Orders, sessions and background jobs

The back office of a busy store slows down for reasons of its own.

Order storage. Stores created on older versions keep orders in the general posts tables, shared with every page and product. High-Performance Order Storage (HPOS) moves them into dedicated order tables. New stores use it by default. On an older store, look under WooCommerce > Settings > Advanced > Features. If the option is disabled, an installed extension has not declared compatibility. The switch is described in the official HPOS documentation and in our article on what HPOS changes.

Sessions. Every cart creates a row in the sessions table, and bots that add to cart can inflate it enormously. Check its size, and rate-limit or challenge automated add-to-cart traffic.

Scheduled actions. WooCommerce and its extensions queue background work such as emails, webhooks and subscription renewals through Action Scheduler. Open WooCommerce > Status > Scheduled Actions. A long list of pending or failed actions means the queue is not keeping up, usually because WP-Cron depends on visitor traffic. Run it from a real server cron job.

Where to start with WooCommerce speed optimization

Start by measuring three things with a product in the cart: server response time for a category page, for the cart, and for the recalculation request on the checkout. Fix the cache rules first, then cart fragments, then whichever of the three is slowest. Hosting matters more for stores than for content sites, because so much of the traffic that earns money is uncached.

A store owner can handle images, plugin cleanup and cache settings. Involve a developer when the checkout has been customized, when an ERP or inventory sync writes to the database on a schedule, or when the store has dozens of extensions and nobody knows which ones the checkout depends on. Our WooCommerce development team does this work on stores we build and on stores we take over, often alongside a wider performance audit.

Frequently asked questions

Should I disable WooCommerce cart fragments?

Only if something else keeps the header cart up to date. Current WooCommerce versions already limit the script to pages that show the classic cart widget. If your theme forces it everywhere, replace the header cart with the Mini-Cart block or a lighter implementation before removing the script.

Can the cart and checkout pages be cached?

No. They show one customer's items, totals and address, and a cached copy would be shown to someone else. Make them fast with a persistent object cache, enough PHP workers and fewer scripts.

Does HPOS make the storefront faster?

Not directly, because catalog pages do not read orders. HPOS helps with placing orders, the order screens in the admin and anything that searches or reports on orders. It also takes load off the posts tables the rest of the site uses.

Do I need Redis for a WooCommerce store?

A small store on good hosting runs fine without it. It starts to pay off when many customers are in the cart and checkout at once, or when the admin feels slow, because those requests cannot use the page cache. Check that a host supports a persistent object cache before you choose a plan.