Hyvä for high-SKU catalogs: How we handle 100,000+ products

High-SKU Magento catalogues, 50,000 to 500,000+ products, break default Luma PLP performance. Mobile Lighthouse craters; PLPs become unusable on slower devices; search relevance degrades; crawl budget fragments.

Hyvä handles high-SKU catalogues cleanly, but only with the right architectural choices. This post is the playbook: search, navigation, rendering, and the performance patterns that make 100k+ SKU stores work.

What "high-SKU" actually means

For practical purposes:

• Small catalogue: under 5,000 SKUs. Default Magento handles this without special consideration.
• Medium catalogue: 5,000–50,000 SKUs. Default Magento works but you'll want a real search backend (Elasticsearch / OpenSearch).
• High-SKU catalogue: 50,000–250,000 SKUs. Requires deliberate architecture decisions to perform well.
• Very high-SKU catalogue: 250,000+. Requires significant architectural investment + ongoing maintenance.

The vertical that hits this most often: auto parts (multi-make / multi-model / multi-year compounds quickly), industrial supply (broad categories with many variants), B2B wholesale (extensive catalogues across multiple brands).

What breaks at high SKU on Luma

In rough order of severity:

1. PLP rendering

Default Magento Luma PLP rendering is slow above 50 products per category. At 200+ products per category, mobile becomes unusable. Browser parse time + Knockout view model initialisation + image loading all compound.

2. Search relevance

Magento's default MySQL-based search degrades quickly above ~10,000 SKUs. Results become irrelevant; query latency increases. Most high-SKU stores already use Elasticsearch / OpenSearch / Algolia, but Luma's frontend integration with these is fragile.

3. Faceted navigation

Layered navigation with many facets (brand, attribute, price range, custom attributes) becomes computationally expensive at scale. Luma's default implementation often returns counts that take 2–5 seconds, making filter selection laggy.

4. Crawl budget

Googlebot has a finite crawl budget per site. A 100k-SKU site with a slow PLP and slow PDP renders fewer crawled URLs per crawl window than the same site rendered quickly.

5. Mobile cart / mini-cart

For B2B stores with cart sizes in the dozens of items, mini-cart rendering becomes slow on Luma. Knockout view models initialise per cart item.

6. Customer-account order history

Customers with hundreds of past orders see slow account-section rendering. PLP-style listing of orders has the same Luma scalability issue as product PLPs.

What Hyvä changes at high SKU

In rough order of impact:

1. PLP rendering, lighter HTML + faster initial paint

Hyvä's server-rendered HTML approach + lighter Tailwind class strings produces significantly lighter PLP HTML at scale. A 200-product PLP that weighed 850KB of HTML on Luma weighs 280KB on Hyvä. Initial render is 3x faster on mobile.

2. Faceted navigation, Alpine-driven facets

Hyvä replaces Luma's Knockout-based facet UI with Alpine.js. Facet filtering interactions are immediate (no Knockout view model overhead). Count updates from the backend happen the same way; rendering them is dramatically faster.

3. Search integration, cleaner pattern

Hyvä integrates with Elasticsearch / OpenSearch / Algolia / Klevu via templated patterns. Search-results rendering is server-side; autocomplete is Alpine-based. Both are noticeably faster than Luma equivalents.

4. Image loading, proper responsive + lazy

Hyvä templates use modern image patterns: loading="lazy" on below-fold images, srcset for responsive sizes, fetchpriority="high" on the LCP image. At PLP scale this dramatically reduces initial-payload weight.

5. Component reuse, less re-render overhead

Hyvä's pattern of small, focused Alpine components means changes to one product card don't trigger re-render of the whole PLP, unlike Knockout where view model updates cascade.

The high-SKU Hyvä architecture

For a 100k+ SKU Hyvä build, the architecture choices we make:

1. Search backend, not Magento's default

Required: Elasticsearch (Magento's default for 2.4.x) or OpenSearch (2.4.6+) at minimum. For very high-SKU or specific relevance needs, consider Algolia, Klevu, or Bloomreach.

Why: MySQL search at 100k+ SKUs is too slow and returns poor relevance. The search backend is the single biggest performance + quality factor.

2. Faceted navigation, well-curated facets

Don't expose every attribute as a facet. Curate to ~5–8 facets per category. More facets = slower count calculation + UX overload.

For multi-make / multi-model auto parts: vehicle compatibility as primary facet (year → make → model → engine). Plus 3–5 secondary facets (brand, price range, condition, fitment type).

3. PLP pagination, not infinite scroll for SEO

For high-SKU, paginated PLPs with rel="prev" / rel="next" (now mostly ignored by Google but still semantically correct) plus a "load more" UX option. Avoid pure infinite scroll because it fragments crawl + analytics.

Default: 24–48 products per PLP page. More than that on mobile is information overload.

4. PDP optimisation, image priority + lazy below-fold

PDP LCP is usually the hero image. Add fetchpriority="high" to it; lazy-load image gallery below. Defer related-products and reviews to lazy-load on scroll.

5. Vehicle compatibility lookup (if relevant)

For auto parts specifically: Alpine.js cascading dropdown component (year → make → model → engine) + server-side compatibility data. Vehicle filter persists in cookie so subsequent pages auto-filter. See Hyvä for auto parts retailers.

6. Server-side caching, aggressive

Varnish in front of Magento for full-page caching. Redis for session + cache. CDN at the edge for static assets. None of this is Hyvä-specific but matters more at scale.

7. Search index optimisation

For Elasticsearch / OpenSearch specifically: tune the index mapping for your attribute structure, configure relevance scoring for your vertical, use synonyms + stop-words for your domain. This is search-specialist work, often £5k–£15k of one-time tuning.

The high-SKU implementation pattern

Beyond standard Hyvä migration, high-SKU stores typically add:

• Custom Hyvä PLP template with faceted-facet rendering optimised for your category structure: 5–10 days
• Search-backend integration (if not already configured): 5–15 days depending on backend choice
• Vehicle compatibility lookup (auto parts): 10–15 days
• PDP optimisation pass for image-heavy products: 3–5 days
• Custom search-results template with vertical-specific result rendering: 3–7 days
• Sitemap optimisation + crawl strategy for crawl efficiency: 2–5 days
• CDN + edge caching setup if not already in place: 2–7 days

Cumulative: 30–60 additional days on top of base Hyvä migration. Cost: £15k–£40k additional on top of standard Hyvä Theme migration cost.

For a typical 100k+ SKU Hyvä migration, total budget is £40k–£80k vs £20k–£35k for a smaller catalogue.

Hyvä for B2B high-SKU specifically

B2B high-SKU catalogues add complexity layers:

Customer-segmented catalogue visibility

Different customers see different products based on segment. PLP rendering needs to respect customer login state. Hyvä templates handle this with conditional rendering; Magento backend enforces the visibility logic.

Customer-specific pricing at PLP

PLP price display per customer tier. Adds a server-side pricing-calculation step per PLP page load. Cacheable per customer-segment, but adds complexity.

Requisition lists at scale

B2B customers maintain saved part lists with hundreds of items. Quick-add-all-to-cart needs to scale. Standard Magento requisition list works; Hyvä re-template handles the UI.

Bulk-pack / quantity-break rendering on PDP

B2B PDPs often show "buy 10+ for £X, buy 100+ for £Y" tables. Hyvä template work, straightforward but tedious for catalogues with complex tier structures.

Performance numbers at scale

For high-SKU stores post-Hyvä migration:

Metric	Pre-Hyvä (high-SKU Luma)	Post-Hyvä
PLP load time (200-product category, mobile)	6.5s	1.9s
Mobile Lighthouse PLP	31	89
Search autocomplete latency	800–1500ms	150–300ms
Facet selection latency	1500–3000ms	200–500ms
PLP page weight (200 products)	4.8 MB	870 KB
Crawl rate (Search Console)	baseline	+30–50%
Mobile checkout completion	34% typical	47% typical (+13pts)

These are typical numbers from our high-SKU Hyvä migrations. Your numbers will depend on specific catalogue structure + extension count + backend choices.

When Hyvä doesn't solve the high-SKU problem

A few honest caveats:

1. Bad search backend

If your search is on default Magento MySQL search at 100k+ SKUs, Hyvä migration alone doesn't fix it. You need to add Elasticsearch / OpenSearch / Algolia. Hyvä helps the frontend; search relevance + speed is a backend question.

2. Bad category structure

If your category hierarchy has 5,000+ categories with 20 products each, navigation UX is the problem, not rendering performance. Fix the category structure first; Hyvä migration second.

3. Slow Magento backend

If your Magento backend is undersized for the catalogue, server response times stay slow after Hyvä. Hyvä is faster in the browser, not faster on the server. Magento config tuning + better hosting first.

4. Bad product data

If your PDPs have low-quality images, missing attributes, no structured data, weak content, Hyvä migration doesn't fix any of this. Content + data quality matters more than frontend performance at the conversion-driving level.

Implementation timeline for high-SKU

Realistic timelines:

• 100k SKU Magento Open Source, B2C, clean catalogue: 12–14 weeks
• 100k SKU Adobe Commerce, B2B, vehicle compatibility: 16–20 weeks
• 250k+ SKU multi-segment with custom facets: 20–28 weeks

These are longer than standard Hyvä migration because of the additional search, faceted navigation, and PDP optimisation work.

Cost ranges

• 100k SKU Hyvä Theme: £35k–£60k
• 100k SKU Hyvä Commerce (Theme + Checkout): £55k–£85k
• 100k SKU Hyvä Enterprise (Adobe Commerce B2B): £75k–£120k
• 250k+ SKU full implementation: £80k–£150k+

Next steps

• Read Hyvä for auto parts retailers for the auto-parts-specific vertical
• Read Hyvä for B2B Ecommerce for B2B-specific patterns
• See the Hyvä Migration service page
• Book a scoping call for a fixed-price quote on your specific high-SKU store