Why a WooCommerce shop slows down as the catalogue grows

A WooCommerce shop that was quick with 300 products often becomes slow at 5,000. Category pages take several seconds, the admin freezes while saving a product, and imports run into the night. The usual reaction is to buy bigger hosting. Sometimes that helps for a month. More often the cause is how WooCommerce stores its data, and hosting only hides it until the catalogue grows again.

The short answer#

WooCommerce keeps most product details, such as price, SKU and stock status, as rows in a general WordPress table called wp_postmeta, one row per value, and plugins add more. A shop with thousands of products and variations ends up with hundreds of thousands of rows or more there. Filters, sorts and searches on values that WooCommerce's lookup tables do not cover make the database join that table several times, and indexes cannot fully fix that shape of query. Orders used to live in the same structure. WooCommerce now offers High-Performance Order Storage (HPOS), which moves orders into dedicated tables, but product data stays where it was. So a large WooCommerce shop is usually slow for three combined reasons: product queries against wp_postmeta, pages that cannot be cached, and background jobs competing with visitors for the same server. Measure which one dominates before changing anything.

First, decide what "slow" means#

Four different problems get reported as a slow shop, and they have different causes.

• Category and search pages load slowly for visitors.
• Product pages are fine, but the cart and checkout lag.
• The admin area is slow, especially the orders list and product editing.
• Imports, stock updates or feeds take hours or time out.

Write down which of these you see, and at what times of day. A shop that is slow only between 02:00 and 04:00 has a scheduled job problem, not a hosting problem.

Where the time actually goes#

Product data in a key-value table

WooCommerce stores product details such as price, SKU and stock status as rows in wp_postmeta, and themes and plugins add many rows of their own for custom fields. WooCommerce keeps separate lookup tables for price, stock and SKU to speed up the most common sorting and filtering. Filters on custom fields added by plugins, and some attribute filters, still turn into queries that join wp_postmeta or the taxonomy tables several times for every product in the category. With a few hundred products this is invisible. With tens of thousands of variations it can become the slowest part of the page. Filter plugins that build their own counts ("Red (24)") repeat that work for every filter value on the page.

Orders still stored the old way

Older shops, and shops upgraded over many years, often still store orders in the posts tables. WooCommerce's own 2023 benchmarks for HPOS report roughly five times faster order creation and far faster filtering in the admin order list once orders move to the dedicated tables, with a smaller gain at checkout (about 1.5 times). New installations have had HPOS enabled by default since WooCommerce 8.2. You can check the current setting under WooCommerce, Settings, Advanced, Features. Switching needs a compatibility check of every plugin that reads orders, and a test on a copy of the shop first.

Pages that cannot be cached

A page cache serves a ready-made copy of a page instead of building it again. It removes most of the load for category and product pages. It does not work for the cart, the checkout or for logged-in customers, and some themes and plugins mark every page as uncacheable by setting cookies or adding per-visitor fragments. If the cache hit rate is low, the server is building every page from scratch.

Background work during the day

WordPress runs scheduled tasks through wp-cron, which is triggered by visitor requests. Stock synchronisation, feed generation for comparison sites and email queues then run in the middle of real traffic. On a busy shop that is a reliable way to slow down checkout at the worst moment.

The server itself

Hosting matters, but in a specific way. The number of PHP workers limits how many uncached requests are handled at once. A persistent object cache such as Redis stops WordPress from asking the database the same questions on every request. Neither helps much if each request runs one query that takes two seconds.

Find the cause in about an hour#

1. Measure server response time separately from the browser. If the first byte of the HTML arrives late, the problem is on the server. If the HTML is fast and the page still feels slow, it is images, scripts or the theme.
2. Install Query Monitor on a staging copy and open a slow category page and the admin order list. It shows the slowest database queries and which plugin made them.
3. Turn on the database slow query log for a day. It shows which queries are slow under real traffic, not only the ones you tested.
4. Check the page cache hit rate in your hosting panel or cache plugin.
5. List scheduled tasks and when they run. Look for anything heavy during opening hours.

At the end you should be able to say which of the causes above costs the most time. Fix that one first.

Fixes, in the order they usually pay off#

1. Move heavy scheduled jobs out of visitor traffic: disable wp-cron on page load and run it from the server's scheduler, and schedule imports for quiet hours.
2. Get the page cache working for every page that can be cached, and remove whatever marks those pages as uncacheable.
3. Add a persistent object cache.
4. Enable HPOS after testing plugin compatibility on a copy of the shop.
5. Replace filter and search plugins that query product meta on every request with ones that use an index, or with a dedicated search service.
6. Remove plugins that are no longer used. Every active plugin loads on every request.
7. Only then compare hosting plans, using the measurements from step one to size them.

Work on a staging copy and keep a backup you have actually restored once. Changes to order storage and caching can break checkout in ways that do not show up until someone pays.

When the platform is the problem#

If the catalogue is large, changes daily from an ERP or warehouse system, and the shop still depends on many plugins after the steps above, the cost of keeping WooCommerce fast can exceed the cost of moving. That is a business decision with its own risks: customer accounts, URLs and search rankings all have to survive the move. The companion article on moving from WooCommerce to Shopify covers what does not transfer automatically. If stock numbers in the shop disagree with the warehouse, read why webshop stock drifts before blaming performance.

Nevo builds and maintains online shops. The e-commerce development page describes how a project begins.

Sources#

• developer.woocommerce.com: high performance order storage
• developer.woocommerce.com: performance benchmarking for woocommerce hpos