B2B-Katalog: 250.000 Artikel performant ausspielen

Ausgangslage: B2B-Großhandel mit großem Sortiment, 250.000 aktive Artikel im Shopware-6-Katalog, 14 Filter-Dimensionen (Material, Norm, Maß, Hersteller, etc.), gestaffelte Preise pro Kundengruppe (8 Gruppen). Kategorie-Listing-Pages waren mit 6,2 s Ladezeit der erste konkrete Conversion-Killer. Such-Conversion B2B lag bei 2,4 %, weit unter dem Benchmark.

Diagnose: Performance-Profiling ergab drei Hauptursachen — (1) Komplette Produktdaten pro Listing-Item geladen (auch was nicht angezeigt wurde), (2) Filter-Berechnung über MySQL-Queries statt Elasticsearch, (3) Kundengruppen-Preise pro Item einzeln berechnet ohne Batch-Strategie.

Umsetzung: (1) Custom Listing-Endpoint, der nur die für die Card sichtbaren Daten lädt (slug, Titel, Listing-Bild, Preis-Bracket, Verfügbarkeits-Status). (2) Filter-Berechnung auf Elasticsearch ausgelagert mit aggregierten Buckets pro Dimension — Filter-Counts werden gleichzeitig mit dem Listing geliefert, nicht in separaten Queries. (3) Kundengruppen-Preise mit Redis-Cache pro Kundengruppen-Hash, 5-Minuten-TTL.

Ergebnis: Kategorie-Ladezeit von 6,2 s auf 1,3 s (−79 %). Such-Conversion B2B von 2,4 % auf 5,1 % (+113 %). Bounce-Rate auf Kategorie-Pages von 57 % auf 29 % (−49 %). Als Nebeneffekt sank die Server-Last in Spitzenzeiten von 82 % auf 31 % CPU — gleicher Server-Park hält jetzt das doppelte Traffic aus.

Lessons Learned: Bei B2B-Katalogen mit > 100.000 Artikeln ist Elasticsearch keine Option, sondern Pflicht. Plus: Listing-Endpoints sollten nur das laden, was die Card zeigt — das macht den größten Performance-Unterschied. Kundengruppen-Preise eignen sich exzellent für Cache, weil sie sich selten ändern und pro Gruppe deterministisch sind.