Where it gets stuck.
hopify supports up to 2,000 variants per product and three option axes. For a tile brand with 40 SKUs across 5 sizes, 3 finishes, and 2 colors, that is 40 × 5 × 3 × 2 = 1,200 variants — before adding special orders, custom sizes, or trade-only finishes. The product page loads all variant data upfront. At 1,200 variants, that payload is 180–220KB of JSON before a single product image loads.
Why it happens.
Shopify's variant model was designed for apparel — a product has a color and a size. Material commerce adds axes: finish, thickness, edge profile, box quantity, pattern match. Each axis multiplies the variant count. Brands that migrate from a monolithic ERP often import their full SKU matrix as Shopify variants, because that is the direct analog. The result is a variant architecture that is correct in spreadsheet logic and catastrophic in storefront performance.
The size of it.
A product page with 800+ variants takes 2.8–4.2 seconds longer to reach Time to Interactive on a median mobile connection than a comparable page with 50 variants. That latency compounds: every variant option change triggers a re-render that recalculates availability across all remaining variants. We have seen this problem single-handedly prevent brands from achieving Lighthouse scores above 55. The correct architecture — product grouping by base SKU, option-driven variant resolution on selection rather than on load — recovers 40–60 Lighthouse performance points.
Filed from inside a working engagement. Edited only for client privacy — the numbers and the mechanisms are exact.