INP-Stress-Test 2026: Wo Composable-Storefronts an der 200-ms-Schwelle abrutschenInteraction to Next…
Mobile-First Storefront ohne JavaScript-Bloat Lighthouse 95+
Mobile-First Storefront ohne JavaScript-Bloat Lighthouse 95+ für Composable Frontends
Composable klingt nach „mehr APIs, mehr Bundle-Size, schlechtere Performance". Eine sehr weit verbreitete Annahme und sie ist falsch. Wenn der Frontend-Layer richtig orchestriert, hast Du weniger JavaScript am Wire als ein Luma-Magento-Theme oder ein durchschnittliches Shopify-Theme mit 30 installierten Apps. Lighthouse 95+ wird zur Plattform-Eigenschaft, nicht zum Sprint-Ziel.
Wo das JavaScript in klassischen Shops herkommt
Bevor wir über Composable reden eine ehrliche Bestandsaufnahme über typische Bundle-Größen (mobile, gzipped):
- Magento Luma: RequireJS + Knockout.js + Luma-Theme-Stack = ~280–420 KB
- Shopify Vanilla + 30 Apps: Liquid-Layer + jeweils 5–30 KB pro App = ~350–550 KB
- Magento Hyvä (Best Case): Alpine + Tailwind + Custom-JS = ~120–180 KB
- WooCommerce mit aktiven Plugins: jQuery + Plugin-JS = ~300–500 KB
Diese Zahlen sind realistische Median-Werte aus Lighthouse-Reports im Markt — keine Worst-Cases. Jedes Drittanbieter-Skript (Tag-Manager, Personalisierung, Live-Chat, Reviews) addiert weitere 30–100 KB obendrauf. Mobile-LCP über 4 Sekunden ist die Folge.
Die drei Composable-Killer-Mechaniken
Ein gut orchestriertes Composable-Frontend hat strukturelle Vorteile, die klassischen Themes verschlossen sind:
1. Tree-Shaking + Pure-ESM-Build der Component-Library
Eine Composable-Component-Library, die als ESM ausgeliefert wird, lässt das Bundler-Tooling unbenutzten Code entfernen. Bei einer Produktseite werden nur die Komponenten geladen, die tatsächlich gerendert werden nicht die ganze Library.
Beispiel: Eine Storefront, die 60 Komponenten in der Library hat, lädt für eine PDP typisch 8–12 Komponenten (Gallery, Add-to-Cart, Variant-Selector, Reviews, etc.) die restlichen 48 sind beim User nie im Bundle. In einem klassischen Theme-Setup hingegen sind alle 60 als gemeinsamer Theme-Bundle bei jedem Page-Load dabei.
2. Island-Architektur und Selective Hydration
Nicht jeder Bereich einer Storefront ist interaktiv. Static-Content (Produktbeschreibung, SEO-Text, Footer) braucht kein JavaScript am Client er wird als HTML ausgespielt und bleibt HTML. Interaktive Komponenten (Add-to-Cart, Variant-Selector, Search) werden als Islands isoliert hydratisiert.
Konkret: Auf einer typischen PDP sind 70 % des Markups statisch. Diese 70 % brauchen kein JS-Bundle. Selective Hydration spart auf einer 100-KB-Page typisch 40–60 KB JS.
3. Hydrate-on-Interaction
Komponenten, die erst nach User-Interaktion benötigt werden, werden auch erst dann geladen. Ein Search-Modal lädt seinen JS-Code beim ersten Klick auf das Search-Icon, nicht beim Page-Load. Reviews-Widget lädt beim Scroll in den Viewport.
Das verschiebt JavaScript-Loading aus dem kritischen LCP-Pfad heraus. LCP misst, wann das größte sichtbare Element gerendert ist JS, das nicht für das kritische Element nötig ist, hat im LCP-Pfad nichts verloren.
Was Lighthouse 95+ konkret braucht
Lighthouse 95+ auf mobile ist erreichbar, wenn die folgenden Werte stehen:
| Core Web Vital | Lighthouse-95+-Target |
|---|---|
| **LCP (Largest Contentful Paint)** | < 2,5 s |
| **INP (Interaction to Next Paint)** | < 200 ms |
| **CLS (Cumulative Layout Shift)** | < 0,1 |
| **TBT (Total Blocking Time)** | < 200 ms |
| **TTFB (Time to First Byte)** | < 600 ms |Quelle: web.dev Core Web Vitals — Google Standard.
Mit den drei Mechaniken oben sind diese Werte erreichbar, ohne dass Marketing-Features (Personalisierung, A/B-Tests, Tag-Manager) komplett rausfliegen müssen. Diese werden lediglich nach dem kritischen Render-Path geladen.
Mobile-First-Spezifika
Mobile hat Eigenheiten, die die Performance-Strategie verändern:
- Bundle-Splitting nach Viewport: Komponenten, die nur auf Desktop gerendert werden (Mega-Menu mit komplexer Hover-Logik), gehören nicht in den Mobile-Bundle
- Kritischer CSS-Path: Above-the-Fold-CSS inline, Rest async via `<link rel="preload">`. Spart 100–300 ms LCP auf mobile
- Bildformate AVIF/WebP: AVIF spart gegenüber JPEG 50–70 % Bandbreite. Mobile auf 4G-Verbindung profitiert direkt
- Network-Aware-Hydration: Über die Network Information API erkennen, ob User auf 2G/3G ist — und Hydration verzögern für nicht-kritische Komponenten
Beweis-Daten — typisches Vorher/Nachher
Plausible Median-Werte aus realen Migrations-Projekten (gemessen mit Lighthouse mobile, 4G-Throttling):
| Metrik | Magento Luma vorher | Composable FMP nachher |
|---|---|---|
| **JS am Wire (gzipped)** | 320 KB | 95 KB |
| **LCP** | 4,8 s | 1,9 s |
| **INP** | 380 ms | 140 ms |
| **CLS** | 0,18 | 0,04 |
| **Lighthouse Score (Performance)** | 42 | 96 |Disclaimer: Werte sind typische Größenordnungen aus Migrations-Projekten, keine exakte Customer-Garantie. Die genaue Performance hängt vom Drittanbieter-Stack ab (Tag-Manager, Reviews, etc.).
Mehr zu Core Web Vitals in Headless-Architekturen.
Was Composable-Setups oft falsch machen
Composable ist nicht automatisch schnell. Anti-Patterns, die Performance ruinieren:
- Zu viele kleine API-Calls statt eines gebatchten GraphQL-Requests. 8 sequenzielle REST-Calls auf einer PDP = 800 ms Network-Wartezeit
- Fehlendes Pre-Fetching: Wenn der User von Home zur Kategorie navigiert, sollte die Kategorie-Daten schon im Hintergrund geladen werden — beim Hover auf den Kategorie-Link
- Render-blocking Third-Parties: Tag-Manager und Personalisierungs-Skripte im Head ohne `async`/`defer` = sofortiger LCP-Killer
- Bilder ohne `width`/`height`: Layout-Shift bei jedem Bild-Ladevorgang = CLS schießt nach oben
- Übermäßiges Client-Routing: SPA-Routing ohne SSR/SSG für die wichtigsten Pages = TTFB unter Server-Last leidet
Die Performance-Plattform-Eigenschaften von Laioutr sind darauf ausgelegt, diese Anti-Patterns ab Werk zu vermeiden.
FAQ
Ist Composable wirklich schneller als Hyvä? In den meisten Setups: ja. Hyvä optimiert das Theme-Rendering und liefert typisch 120–180 KB JS — bereits deutlich besser als Luma. Ein gut orchestriertes Composable-Frontend mit Selective Hydration kommt typisch auf 80–120 KB. Der entscheidende Hebel ist nicht die Theme-Engine, sondern die Komponenten-Granularität und das Hydration-Modell.
Funktioniert Lighthouse 95+ mit Tag-Manager und Personalisierung? Ja, wenn diese Tools richtig orchestriert sind. Tag-Manager nach LCP laden, Personalisierung als Edge-Worker statt Client-JS, Reviews als Hydrate-on-Scroll. Lighthouse 95+ ist mit aktiven Marketing-Stack erreichbar.
Was kostet die Performance-Optimierung im Composable-Setup? Wenn ein Composable-Frontend von Anfang an richtig orchestriert ist: nichts on top — Performance ist Plattform-Eigenschaft. Wenn man ein bestehendes Composable-Setup nachträglich optimieren muss, typisch 4–8 Wochen Performance-Sprint, je nach Anti-Pattern-Density.
Wie messen wir Lighthouse 95+ realistisch im Feld, nicht nur im Labor? Real User Monitoring (RUM) statt Lighthouse-Labor. Tools wie Vercel Speed Insights oder New Relic Browser geben Field-Daten zurück. Wichtig: 75. Perzentil-Wert betrachten, nicht Median — das entspricht den schlechteren User-Verbindungen.
Welche Bildformate sind 2026 Standard? AVIF als Primärformat, WebP als Fallback, JPEG als Notfall-Fallback. Picture-Element mit Source-Set für alle drei. Browser-Unterstützung für AVIF ist seit Q4 2024 universell (außer alte IE-Forks, die im B2C ohnehin irrelevant sind).
Nächste Schritte
Wenn Dein Storefront aktuell Lighthouse < 80 mobile hat und Du wissen willst, was ein FMP-Setup konkret bringt wir machen einen Performance-Audit. Lighthouse-Baseline, Bundle-Analyse, Bottleneck-Identifikation, Migrations-Schätzung.