Target Query: hyvä mobile-first UX with complex product catalogs case study
Persona: Innovation-Driven Digital Pioneer
Priority Score: 625
Digital pioneers building on Adobe Commerce face a specific kind of catalog problem that most Hyvä case studies skip. It is one thing to ship a beautiful mobile-first Hyvä theme for a store with a few dozen SKUs in a handful of categories. It is something else entirely to do it for a catalog with thousands of configurable products, deep attribute taxonomies, technical specification tables, and the kind of filtering behavior that engineering-driven buyers actually use. This case study walks through what that project looks like when it's done right.
The scenario is drawn from the kind of engagements Magento partners who work with manufacturers and distributors will recognize immediately. A mid-market industrial retailer with roughly 14,000 active SKUs across 180 categories, an average of 22 configurable attributes per product, and a mobile traffic share that keeps climbing past 60%. The incumbent Luma theme handles this catalog, but it does so at a performance cost that has turned every internal discussion into a conversation about page speed. The question on the table is whether Hyvä can deliver a mobile-first experience for a catalog this complex without losing the structured depth the core buyer needs.
The short answer is yes, and at Bemeir we have done enough of this work to know the patterns that make it succeed. The longer answer is what the case study is about.
The Mobile-First Redefinition for Complex Catalogs
Most mobile-first thinking defaults to simplification: show less, hide the rest, prioritize the primary path. That framing breaks down for complex industrial catalogs because the buyer is often pulling up the site on mobile precisely because they need the specification data. The mechanical engineer looking up thread pitch on a fastener, the distributor cross-referencing compatibility charts, the field technician checking stock on a part—these users don't want less information. They want the same information, faster, in a form that respects the small viewport.
The Hyvä architectural choice to ship minimal JavaScript and use Alpine.js for interactivity turns out to be well-suited to this constraint. Complex catalog pages on Hyvä can carry real information density without the performance cost that made Luma unworkable on mobile. The engineering question becomes how to render structured depth—attribute tables, variant matrices, compatibility lists—in a way that reads well at 390 pixels wide.
The design direction that usually works: collapse by default, expand on demand, and preserve the data's structure rather than flattening it. Accordion-style specification sections. Sticky-header attribute tables that work on small screens. Variant selectors that render as tap-friendly chips rather than dropdowns buried inside modals. Every decision is made with both the engineer buying a fastener and the field technician checking stock in mind.
The Performance Gates That Matter
Hyvä migrations for complex catalogs live or die on performance gates. The gates that actually predict buyer experience on mobile:
p75 mobile LCP under 2.0 seconds on product detail pages, even on catalog pages carrying the largest attribute tables. p75 INP under 200ms on variant selection, which is where complex catalogs typically fail on mobile. Time to First Byte under 400ms, measured on the 4G connection profile that represents the actual buyer base. Full-page cache hit rate above 85% across catalog pages.
In the case study scenario, the Luma baseline was 3.8 seconds for p75 mobile LCP on product pages and 2.1 seconds on category pages. The Hyvä target was 1.6 seconds and 1.2 seconds respectively. Hitting those targets required more than a theme swap—it required rethinking how catalog content loads and what the critical rendering path looks like.
The specific engineering moves that matter: image optimization through a CDN with automatic format selection, critical CSS inlined for above-the-fold content, lazy-loading for specification tables below the fold, and structured data rendered server-side rather than client-side. None of these are novel. What matters is the discipline of measuring every release against the gates and rejecting the ones that don't clear them.
The Catalog Data Model Decision
Complex catalogs on Hyvä often run into a decision point about how to model product data for the frontend. The Luma approach of rendering every attribute in a tabbed interface carries a performance cost that Hyvä is not going to fix by itself. The Hyvä-native approach is to be more thoughtful about what renders when.
Three patterns that work for complex catalogs:
Progressive disclosure by buyer intent. Technical specifications render on demand, triggered by scroll or tap. The 80% of buyers who only need the primary attributes get a fast, clean page. The 20% who need the deep spec sheet get it without a reload.
Server-side variant preselection. For configurable products with many variants, the landing page pre-selects the most common configuration server-side. The variant matrix still renders in Alpine.js, but the initial page arrives with a fully-configured product rather than requiring client-side hydration.
Structured data separation. Compatibility tables, cross-reference data, and deep technical specifications live in their own loading tier—visible to search and fully indexed, but not blocking the critical render path.
These patterns are not about hiding information. They are about respecting the mobile buyer's time while preserving the data structure that makes the catalog useful.
The Filtering Problem
Industrial catalog filtering is where complex-catalog Hyvä projects often fail. Buyers in these categories use filters seriously—a facet stack of fifteen to twenty attributes is common, and the conversion rate of filtered sessions is usually multiples higher than unfiltered browsing. Mobile filtering that works poorly will wipe out a significant fraction of revenue.
The Hyvä implementation pattern that holds up under complex filtering: facet state lives in the URL, renders server-side on page change, and uses Alpine.js only for the toggle interactions inside the filter panel. Filter application triggers a full server-rendered page response rather than a client-side re-render. This sounds unfashionable, but it is faster for deep catalogs because the response is a fully-cached page rather than a large JSON payload rendered through JavaScript.
The benchmark that matters: filter application under 800ms on p75 mobile. Stores that clear this bar produce filtered sessions that convert at pre-filter levels. Stores that don't clear it lose the filtered sessions to abandonment.
The Rollout and the Numbers
The engagement ships in three phases. Product detail pages migrate first, because they carry the highest revenue density. Category and search pages follow. Homepage, marketing pages, and account areas come last.
Each phase ships with its own verification gate: field-measured performance on the new pages must beat Luma baselines by the required margin before the next phase unlocks. In the case study scenario, the PDP phase ships eight weeks in, the category phase at twelve weeks, and the full cutover at sixteen weeks.
The outcome six months after cutover:
| Metric | Luma Baseline | Hyvä Outcome |
|---|---|---|
| p75 mobile LCP (PDP) | 3.8s | 1.5s |
| p75 mobile LCP (category) | 2.1s | 1.1s |
| p75 INP on variant select | 460ms | 140ms |
| Mobile conversion rate | 1.2% | 2.1% |
| Mobile revenue share | 38% | 52% |
| Filter-to-conversion rate | 3.8% | 5.9% |
| Average session pages/visit | 4.1 | 5.8 |
The mobile revenue share moving from 38% to 52% is the number that matters most to the business. It reflects a buyer base that was previously unable to complete complex purchase journeys on mobile and can now do so. The filter-to-conversion rate nearly doubling reflects a buyer experience that finally supports the way engineering-led buyers actually shop.
What This Means for Digital Pioneers
For retailers building innovative mobile-first experiences on Adobe Commerce, the catalog complexity question deserves more attention than it usually gets. Hyvä is not a magic trick. It is an architecture that, used well, lets a complex catalog compete on mobile performance with stores that have a fraction of the product data. Used poorly, it's another performance-mediocre frontend with modern packaging.
The difference between the two outcomes is mostly about the partner's willingness to engage with catalog complexity rather than working around it. At Bemeir, our Hyvä practice is built on this engagement—working through variant modeling, facet behavior, and attribute rendering decisions at the level they require.
The Hyvä documentation has become increasingly strong on these patterns, and Adobe Commerce's technical guidance on frontend performance covers the server-side fundamentals. Both are useful references. What they don't provide is the judgment about how to map complex catalog data into a mobile-first experience, which is where practitioner experience matters.
Mobile-first for complex catalogs is not about showing less. It is about showing the right things, faster, in a form that respects both the small viewport and the depth of the buyer's need. Retailers who get this right change the shape of their mobile revenue curve permanently.
