Configurable, bundle, and grouped products are the three heaviest product types to render in Magento, because each carries option data, variant logic, and price recalculation that a simple product does not. Hyva renders all of them natively in Alpine and Tailwind, server-rendering swatches and loading option JavaScript only where it is needed. That is why a complex catalog can score well on PageSpeed on Hyva where the same catalog struggled on Luma.
If your catalog is apparel with size and color variants, build-your-own bundles, or kits of related items, these product types are your storefront, not an edge case. Getting them to render fast is the core promise of a Hyva development project. This guide covers what each type does, why it is heavy, and how to keep it fast on Hyva.
The three heavy product types, and what makes them heavy
Magento supports six product types. Three of them (simple, virtual, downloadable) are light to render. The other three carry the weight.
Configurable products present one product with selectable variants, such as a t-shirt in several sizes and colors, each backed by a simple product. The storefront has to load the option data for every variant, render swatches, and recalculate price, image, and stock as the shopper selects options. On a product with many size-by-color combinations, that variant matrix and its swatch data are a real payload.
Bundle products let a shopper build a product from selectable options, such as a computer with a choice of memory, storage, and warranty. Pricing is dynamic, recalculating as options change, and the number of possible combinations grows fast. That live price calculation and option interactivity is what makes bundles heavy.
Grouped products present several simple products together on one page, such as a set of related tools sold individually, in a table where the shopper sets a quantity per line. The weight here is rendering many products and their add-to-cart controls on a single page.
The common thread is that all three need option data and interactivity that a simple product does not. On Luma, that interactivity is delivered through jQuery, Knockout, and swatch JavaScript that loads whether the shopper uses it or not.
Why they tax PageSpeed on Luma
Luma’s frontend loads a large JavaScript stack on every page. According to Hyva, a typical Luma store loads over 230 files at around 3MB per page, while a Hyva store loads roughly 5 files at about 0.4MB. Complex product types make that gap worse, because the swatch and option widgets add more Luma JavaScript exactly on your most important pages.
The specific costs on Luma are the swatch JavaScript loading even on listing pages that may not need it, the configurable product’s full variant data serialized into the page, the bundle’s price calculator running through jQuery widgets, and the general RequireJS overhead of assembling all of it. Each adds to the JavaScript the browser must parse and execute, which hurts Interaction to Next Paint and, on image-heavy product pages, Largest Contentful Paint. For a catalog built on these types, the product page is both the highest-traffic and the heaviest page, which is the worst combination.
How Hyva keeps them fast
Hyva provides native, high-performance handling of all six Magento product types, and it does so by changing how the option interactivity is delivered rather than removing it. Hyva’s own getting-started documentation covers the theme’s stack and requirements.
- Swatches render server-side. Hyva server-renders swatches into the HTML instead of building them with a heavy client script, so they appear immediately and cost far less JavaScript.
- Option JavaScript loads only where needed. Hyva avoids loading swatch JavaScript on product list pages when it is not required, so a category page is not paying for interactivity it does not use.
- Alpine replaces the widget stack. Variant selection, price recalculation, and option changes run through lightweight Alpine components and native JavaScript rather than RequireJS, Knockout, and jQuery.
- Product sliders are server-rendered too. Hyva’s product sliders render server-side and can carry swatches and add-to-cart directly, so cross-sell and related-product widgets on a PDP do not reintroduce the weight you just removed.
The result is that a configurable or bundle product page on Hyva carries a fraction of the JavaScript of the Luma equivalent while keeping the same shopper functionality. That is the mechanism behind the PageSpeed gains, not marketing.
A practitioner comparison of the three types
Choosing and building these types well starts with understanding how they differ for the shopper and where each one’s performance risk lives.
| Configurable | Bundle | Grouped | |
|---|---|---|---|
| Shopper does | Picks variant options (size, color) | Builds from selectable option groups | Sets quantities across related items |
| Pricing | Per selected variant | Dynamic, recalculated live | Per line item |
| Backed by | One simple product per variant | Selectable options, often simple products | Several simple products shown together |
| Main perf risk | Large variant matrix and swatch data | Live price calc and combinatorial options | Rendering many items on one page |
| Hyva handling | SSR swatches, Alpine variant logic | Alpine price calc, on-demand option JS | Lean server-rendered table |
None of these is inherently the “right” choice. Use configurable for true variants of one product, bundle for build-your-own kits with dynamic pricing, and grouped for a set of distinct products a shopper buys together. Matching the type to the buying pattern matters as much as the rendering.
Rules for keeping complex product pages fast on Hyva
Hyva does the heavy lifting, but a few build decisions decide whether a complex catalog stays fast at scale.
- Control the variant explosion. A configurable product with 12 sizes and 20 colors is 240 variants of data to load. Where the combinations are not all real, model the catalog so you are not shipping a matrix of variants that do not exist.
- Keep the configurable option payload lean. Load only the variant data the page needs for the initial render, and fetch deeper data over GraphQL on interaction rather than serializing everything into the initial HTML.
- Let images, not options, win the initial paint. The main product image and price should paint first for Largest Contentful Paint; swatch and option interactivity can hydrate a moment later without blocking it.
- Test the heaviest real product, not a simple one. Your PageSpeed budget should be measured on your worst-case configurable or bundle product, because that is what a shopper actually loads, not a simple product that flatters the numbers.
- Check extension compatibility. Extensions that modify product options, custom swatches, or bundle pricing were often built for Luma. On Hyva they need a compatible frontend, the same as any interactive module. Our guide on adapting Magento extensions to Hyva covers how that works.
These are the disciplines that keep the JavaScript budget under control on the pages that carry your catalog’s complexity.
Structured data and complex products
Complex product types also complicate the structured data that earns rich results and helps AI engines cite your catalog. A configurable product should emit correct product schema with its variants and price range, and a bundle’s pricing needs to be represented accurately rather than as a single misleading number. Magento’s default microdata often falls short here, and a Hyva build is the right moment to emit clean JSON-LD instead. Because Hyva gives you full control of the template output, it is easier to emit correct, complete structured data for a configurable or bundle product on Hyva than to patch Luma’s default markup. That control is part of why a clean catalog on Hyva is more citable, not just faster.
Where this fits your build and platform
Complex product types are where a catalog’s real work lives, and rendering them well is central to any serious Magento development project. The Bemeir technology partners ecosystem connects the catalog to search, personalization, and merchandising tools that all depend on these product types rendering cleanly, and the about Bemeir page introduces the team that has shipped these builds as the first US Hyva Gold Partner.
Platform choice interacts with catalog complexity. Magento and Adobe Commerce handle deep variant and bundle logic natively, which is one reason complex catalogs stay here, but Bemeir also builds on Shopify, Shopware, and BigCommerce when a catalog’s structure fits those platforms better. For the performance side of these pages, our guide on reducing INP on a Hyva storefront covers keeping option interactivity fast. If your catalog is built on configurable, bundle, and grouped products, getting them to render fast and emit clean data is exactly the work Bemeir does on a Hyva build.
FAQ
Does Hyva support all Magento product types?
Yes. Hyva natively supports all six Magento product types: simple, configurable, bundle, grouped, virtual, and downloadable. It renders the complex ones (configurable, bundle, grouped) with server-side swatches and lightweight Alpine interactivity, so they keep full functionality while carrying far less JavaScript than the Luma equivalent.
Why are configurable and bundle products slow on Luma?
Because Luma delivers their option interactivity through a heavy JavaScript stack. Swatch scripts load even where they are not needed, the full variant matrix is serialized into the page, and bundle pricing runs through jQuery widgets on top of RequireJS overhead. That extra JavaScript hurts Interaction to Next Paint and Largest Contentful Paint on your highest-traffic product pages.
How does Hyva render swatches faster?
Hyva server-renders swatches into the HTML rather than building them with a heavy client script, so they appear immediately with minimal JavaScript. It also avoids loading swatch JavaScript on product list pages when it is not required, so category pages do not pay for interactivity they do not use. Variant logic then runs through lightweight Alpine components.
What is the difference between configurable, bundle, and grouped products?
A configurable product is one product with selectable variants like size and color, each backed by a simple product. A bundle lets a shopper build a product from selectable option groups with dynamic pricing. A grouped product shows several distinct simple products together in a table with a quantity per line. Match the type to how shoppers actually buy.
Will my product option extensions work on Hyva?
Only if they ship a Hyva-compatible frontend. Extensions that modify swatches, custom options, or bundle pricing were often built for Luma’s JavaScript stack, which Hyva does not load. They need a Hyva-ready version to render. Confirm Hyva support for each product-affecting extension before relying on it.
How do I keep a large variant catalog fast on Hyva?
Control the variant explosion by not modeling combinations that do not exist, keep the initial option payload lean and fetch deeper data over GraphQL on interaction, let the product image win the initial paint, and measure PageSpeed on your heaviest real product rather than a simple one. Hyva handles the rendering; these decisions keep it fast at scale.
Complex product types are where catalogs get slow and where Hyva earns its reputation. Configurable, bundle, and grouped products carry option data and interactivity that punish a Luma frontend, and Hyva delivers the same functionality with a fraction of the JavaScript. Build them with a controlled variant model and clean structured data, and your heaviest pages become your fastest wins. That is the work Bemeir does on a Hyva catalog.
