Catalogs that were fast at a few hundred products and slow at a few thousand almost always have a query that scales linearly, or worse, with product count, hiding behind a cache that only helps repeat visits. Profile with Query Monitor on an uncached category page before assuming the fix is more caching.
Performance
Diagnose why product listing pages slow down as a WooCommerce catalog grows
A scaling-specific diagnosis for a store where archive and category pages have steadily degraded with catalog size, even with caching already active.
Works with Claude / GPT460 uses★ 4.2
The prompt
performance-woocommerce-catalog-scaling-slowdown
A WooCommerce store went from 400 to 6,000 products over 18 months, and the shop and category archive pages have gotten steadily slower, now taking 4-6 seconds to load even with a caching plugin active. Product pages themselves load fine. It's specifically the listing and archive pages that have degraded. HOSTING: [VPS with reasonable resources, object caching not currently enabled] ACTIVE PLUGINS: [WooCommerce, a filter/faceted search plugin showing live attribute counts in the sidebar, a caching plugin caching full pages but not individual queries] SYMPTOM DETAIL: [the slowdown is worst on category pages with attribute filters visible, and less noticeable on the plain "shop" page] Diagnose this as a scaling problem, not a generic speed audit, since the same setup was fine at 400 products: 1. Explain why archive pages specifically degrade with catalog size while single product pages don't. Page caching serves a cached HTML page on repeat visits, but the first load, and any page with dynamic elements like live attribute-count filters, still runs the underlying queries, and those queries get more expensive as the product and postmeta tables grow. 2. Name the most likely root cause given that filters showing attribute counts are the worst-affected part of the site. This pattern usually means the filter plugin is running a separate aggregate query per attribute on every page load, and that cost scales with catalog size in a way a fixed page cache can't fix. 3. Recommend the specific fix: whether attribute counts should be pre-computed and cached separately, for example as a scheduled job or a longer-lived transient, instead of calculated on every request, and what would actually break if that count became slightly stale. 4. State why enabling object caching (Redis or Memcached) matters more at 6,000 products than it did at 400, and what specifically it would offload here. 5. Recommend one database-level check, such as confirming an index exists on the postmeta columns the filter plugin queries against, that a hosting upgrade alone wouldn't catch, since page caching and a bigger server both mask this without solving it. Replace the product count, hosting, and plugin details with your own situation.