How Many Variations Is Too Many? WooCommerce Performance at Scale

We make a plugin that removes the practical ceiling on how many variations you can create at once. So it’s worth saying plainly: being able to create six hundred variations quickly does not make six hundred variations a good idea.

Creating them fast and living with them are different problems. This is the second one — what a variation costs you, where the thresholds actually are, and how to tell whether your matrix is genuinely necessary or just multiplication that got away from you.

What a variation actually is

In the database, a variation isn’t a row in a table of options. It’s a full post record of its own — post_type = product_variation, a child of the parent product — carrying somewhere in the region of twenty to thirty meta rows: price, sale price, stock, SKU, weight, dimensions, image, shipping class, tax class, and the attribute values that define it.

Two consequences follow, and everything else in this article is downstream of them:

• Loading a variable product means loading all of its variations. The product page needs the data to know what’s purchasable, and it embeds a large chunk of it into the page as JSON so the front end can react when someone picks a size.
• The cost is per variation, not per product. A product with 400 variations is, in database terms, closer to 400 products than to one.

The 30 that isn’t a limit

You’ll see the number 30 mentioned and often misdescribed as a cap on variations. It isn’t.

WooCommerce has a threshold — woocommerce_ajax_variation_threshold, default 30 — that changes how the variation selectors behave. Below it, the dropdowns are dynamic: pick Red and the size list narrows to sizes that exist in Red. Above it, WooCommerce stops shipping all the data upfront and falls back to a less interactive selector that resolves combinations over AJAX.

It’s a display and payload behaviour, not a limit on how many variations you may have. You can filter it. Raising it makes the page heavier; lowering it makes the selector dumber. Neither is a fix for a matrix that’s too large.

Rough thresholds

Numbers vary by host, theme and how much other work your product page does, so treat these as orientation rather than promises:

Variations	What you’ll notice
Under 30	Nothing. Dynamic dropdowns, ordinary page weight.
30–50	Selector behaviour changes. Still comfortable.
50–200	Product pages measurably slower than a simple product — commonly a second or several. The embedded variation data starts to hurt mobile rendering in particular.
200+	Memory pressure. Some hosts time out saving or loading the product. Admin editing becomes unpleasant before the front end does.

The admin side usually degrades first, which is a useful early warning: if editing the product is painful for you, the page is probably not delightful for customers either.

The multiplication trap

Nobody sets out to build 625 variations. They add a fourth axis.

Axes	Values each	Variations
2	3, 4	12
3	3, 4, 3	36
4	5, 5, 5, 5	625
4	6, 5, 4, 3	360

Each axis multiplies rather than adds. A single extra option — one more colour on a four-axis product — can create dozens of records.

Worse, most of those combinations are usually fictional. If you genuinely stock all 625, fine. If you’re generating every combination so the selector looks complete while only forty of them will ever sell, you’ve paid the full performance cost for a fortieth of the value.

Fixing it: split, don’t stack

In rough order of how often they’re the right answer:

1. Remove axes that aren’t commercial

Apply the test: does this change price, stock or SKU? If not, it’s a display attribute, not an axis. Fabric composition, care instructions and country of origin are the usual suspects — see attributes vs variations. Dropping one four-value axis divides your matrix by four.

2. Split into separate products

If a customer would search for it by name, it’s probably a product. Two colourways of a jacket that photograph completely differently, have different names in your supplier’s catalogue, and are stocked separately are arguably two products with a size axis each — twelve variations apiece — rather than one product with twenty-four.

You also get two sets of reviews, two URLs, two chances to rank.

3. Move optional extras to add-ons

Gift wrapping, engraving, an extended warranty. These feel like choices and behave nothing like variants: they double the entire matrix to represent a checkbox, and they aren’t things you hold stock of. A product add-on field is the right tool.

4. Change how the selector renders

Swapping dropdowns for swatches or thumbnails changes how much the customer has to think, and on some setups reduces how much variation data has to be dealt with upfront. It’s a real improvement to the experience — but it’s a mitigation, not a cure for a matrix that shouldn’t be that size.

When many variations is genuinely right

Sometimes the matrix is real and you should keep it:

• Every combination is a distinct thing you physically hold, with its own barcode and its own place on the shelf. Sizes in a shoe range, for example.
• Prices differ per combination in a way that can’t be expressed as a rule.
• Your supplier catalogue is structured that way, and fighting it means reconciling two different models forever.

If that’s you, keep the variations and accept the cost knowingly. Then plan for it: expect slower product pages, expect admin editing to be heavy, and budget for the host to match.

If you must have hundreds

• Give every variation its own SKU. At this scale you cannot manage anything by description. A generated SKU scheme is not optional above about a hundred rows.
• Decide the stock model deliberately. Hundreds of individually-stocked variations is hundreds of numbers to keep true — see parent stock versus variation stock.
• Count them. Each stock-managed variation is its own line in a stocktake, and large matrices drift faster than simple products because there are more numbers to be wrong.
• Watch the admin, not just the shop. If saving the product takes thirty seconds, you’ll stop maintaining it, and stale data costs more than slow pages.

The honest summary

Tools that generate variations quickly — ours included — remove the friction that used to act as an accidental brake. That’s a genuine improvement when the matrix is real, and a genuine risk when it isn’t, because the thing that used to stop you building 400 variations was how tedious it was.

So do the thinking at the point where it’s cheap: before you generate. Ask of each axis whether it changes price, stock or SKU. Ask of the total whether you’d stock all of it. Then build it in a minute, knowing it’s the right size.

Variation performance FAQ

How many variations can a WooCommerce product have?

There is no hard limit in WooCommerce itself, but there is a practical one. Past roughly 50 variations product pages get measurably slower, and past a few hundred you start meeting PHP memory limits and host timeouts — usually in the admin before the storefront.

Is 30 the maximum number of variations?

No. Thirty is the default value of woocommerce_ajax_variation_threshold, which changes how the variation selectors behave rather than capping anything. Below it the dropdowns filter dynamically; above it WooCommerce stops sending all the data upfront and resolves combinations over AJAX.

Why are my variable product pages slow?

Each variation is a separate post record with twenty to thirty meta rows, and the product page loads all of them and embeds a large part of that data into the page. The cost scales with the number of variations, so a product with 400 of them behaves more like 400 products than like one.

How do I reduce the number of variations?

Remove axes that do not change price, stock or SKU; split genuinely different products apart instead of stacking them into one matrix; and move optional extras like gift wrapping into product add-ons rather than variation axes, since an optional extra doubles the entire matrix to represent a checkbox.

Do variation swatches fix the performance problem?

They improve the experience and can reduce how much has to be dealt with upfront, but they are a mitigation rather than a cure. If the matrix is the wrong size, presenting it more attractively does not change the underlying record count.

Is it ever right to have hundreds of variations?

Yes — when every combination is a distinct thing you physically stock, with its own barcode and its own place on the shelf, or when prices genuinely differ per combination. In that case keep them, but plan for slower pages, heavier admin editing and a real SKU scheme.