Jenseits des Themes: Magento Core Web Vitals sind ein Problem der Frontend-Schicht

Wenn euer Magento-2-Storefront auch nach einer Hyvä-Migration weiterhin an den Core Web Vitals scheitert, war das Theme nie die eigentliche Grenze. Core-Web-Vitals-Probleme bei Magento entstehen in der Rendering-Schicht, nicht in der Template-Engine, die darüber liegt. Der Wechsel von Luma zu Hyvä, oder zu einem Custom-Theme, ändert Markup, CSS und JavaScript-Gewicht, rührt aber selten an den architektonischen Entscheidungen, die LCP, INP und CLS bestimmen: Serverantwortzeit, Hydration-Strategie, das Laden von Drittanbieter-Skripten und wie dynamischer Content gerendert wird.

Warum das Theme immer die Schuld bekommt

Magento-Shops mit dem Standard-Luma-Theme zeigen häufig ein mobiles LCP zwischen 4 und 7 Sekunden. Taucht diese Zahl in einem Lighthouse-Audit auf, ist der naheliegende Reflex ein Theme-Projekt: Umbau auf Hyvä oder Investition in einen PWA-Studio-Storefront. Beide Schritte helfen tatsächlich, Hyvä bringt das mobile LCP in typischen DACH-Mittelstand-Deployments auf etwa 2 bis 3 Sekunden. Aber "etwa 2 bis 3 Sekunden" ist nicht "unter 2,5 Sekunden", und es ist nicht für die nächste Anforderung gebaut: eine zweite Marke, ein Personalisierungs-Slot oder ein Marketing-Team, das eine Landingpage ohne Engineering-Ticket veröffentlichen will.

Das Theme ist die Schicht, die Nutzer sehen. Die Core Web Vitals entscheiden sich eine Schicht darunter, in der Art, wie der Storefront gerendert, hydratisiert und ausgeliefert wird.

Was Core Web Vitals bei Magento tatsächlich bestimmt

LCP: der Render-Pfad, nicht das Farbschema

Largest Contentful Paint hängt davon ab, wie schnell der Server antwortet, wie viele Round-Trips der Browser braucht, bevor er das Hero-Bild oder die Headline malen kann, und wie viel JavaScript vorher ausgeführt werden muss. Ein Luma- oder Hyvä-Theme rendert weiterhin gegen Magentos PHP-Stack und dessen eigene Template-Hierarchie. Jeder zusätzliche GraphQL-Round-Trip, jedes render-blockierende Skript, jedes unkomprimierte Hero-Bild zahlt auf diese Zahl ein, unabhängig davon, welches Theme darüber liegt.

INP: was auf dem Main-Thread läuft

Interaction to Next Paint misst, wie schnell die Seite reagiert, nachdem jemand auf einen Filter tippt, in den Warenkorb legt oder einen Größenwähler öffnet. Diese Reaktionsschnelligkeit hängt davon ab, was um den Main-Thread konkurriert: Tracking-Skripte von Drittanbietern, Chat-Widgets, Personalisierungs-Tags und unoptimiertes Theme-JavaScript. Hyväs Alpine.js-Ansatz ist leichter als Lumas Knockout-/RequireJS-Stack, genau deshalb verbessert Hyvä das INP gegenüber Luma, es eliminiert aber nicht die Main-Thread-Konkurrenz durch alles andere, was auf der Seite läuft.

CLS: was nach dem ersten Paint nachlädt

Cumulative Layout Shift entsteht meist durch dynamischen Content: Empfehlungs-Karussells, Personalisierungs-Banner oder Werbeflächen, die nach dem initialen Rendering nachladen und Inhalte verschieben. Das ist eine architektonische Entscheidung darüber, wie und wann dynamische Slots aufgelöst werden, keine Theme-Entscheidung.

Hyvä hat das Symptom verbessert, nicht die Schicht

Hyvä ist eine echte Verbesserung gegenüber Luma, und es als "nur ein weiteres Theme" abzutun, wird der Engineering-Leistung dahinter nicht gerecht. Aber Hyvä bleibt ein Rendering-Ansatz, der auf Magentos server-gerenderte Template-Hierarchie aufgesetzt ist. Es ändert nicht, wo GraphQL-Aufrufe passieren, wie Drittanbieter-Skripte gesteuert werden oder wie ein Marketing-Team eine neue Landingpage veröffentlicht. Teams, die auf Hyvä migrieren und erwarten, dass sich das Core-Web-Vitals-Thema damit erledigt, sehen es meist sechs Monate später wieder aufmachen, sobald eine zweite Marke, ein neuer Markt oder ein Personalisierungs-Anbieter dazukommt. Und PWA Studio, die Adobe-geführte Alternative, verliert seit 2024 spürbar an Community-Momentum, was die reinen Theme-Optionen eher verengt als erweitert.

Die Frontend-Schicht, nicht das Theme

Das Reframing der Frage ändert die Lösung. Statt "welches Theme ist am schnellsten" lautet die bessere Frage: welche Schicht liegt zwischen Magentos GraphQL-API und dem Browser, und behandelt diese Schicht Rendering, Hydration und Skript-Governance als eigenständige Aufgabe, statt als nachträglichen Theme-Zusatz.

Eine entkoppelte Frontend-Schicht spricht direkt mit Magentos GraphQL-API, dieselbe Standard-Anbindung, auf die sich Hyvä und PWA Studio ebenfalls stützen, übernimmt aber den Render-Pfad vollständig: Edge-Rendering, kontrollierte Hydration und einen zentralen Governance-Punkt für Drittanbieter-Skripte und Personalisierungs-Slots. Backend-Patches an Magento erzwingen keinen kompletten Frontend-Re-Test mehr, weil das Frontend auf einem API-Vertrag steht, nicht auf Magentos Theme-Renderer.

Was sich mit einer entkoppelten Frontend-Schicht ändert

Was Laioutr anders macht

Laioutrs Agentic Frontend Management Platform koppelt sich als Standard-Integration an Magentos GraphQL-API, denselben Anschlusspunkt, den Hyvä und PWA Studio nutzen, behandelt Performance aber als Architektur-Eigenschaft statt als Theme-Feature. Edge-Rendering und kontrollierte Hydration sind Standard, kein nachgelagerter Optimierungs-Sprint. Komponentengenaues Core-Web-Vitals-Monitoring meldet LCP-Regressionen, bevor sie in Produktion landen, und dieselbe Composable-Headless-Frontend-Schicht deckt auch die Skript-Governance ab, damit ein neuer Tracking-Pixel das INP nicht stillschweigend in den roten Bereich schiebt.

Magento bleibt die Commerce-Engine. Die Schicht, die entscheidet, ob euer Storefront die Core-Web-Vitals-Schwellenwerte tatsächlich erreicht, wird zu etwas, das ihr prüfen, überwachen und steuern könnt, unabhängig davon, welche Magento-Version oder welcher Extension-Stack darunterliegt. Teams, die bereits mitten in der Entscheidung Hyvä vs. Headless vs. FMP stecken, stoßen typischerweise als Erste an diese Grenze. Die Theme-Entscheidung und die Schicht-Entscheidung sind nicht dieselbe Entscheidung, und beide zu vermischen ist der Grund, warum das Core-Web-Vitals-Thema alle paar Monate wieder aufmacht.

Dieselbe Rendering-Schicht-Logik gilt weit über Magento hinaus. Die SSR-, Hydration- und Core-Web-Vitals-Mechanik, die LCP und INP bei einem Magento-Storefront bestimmt, ist dieselbe Mechanik, die sie bei jedem anderen Commerce-Backend bestimmt, genau deshalb überlebt eine Frontend-Schicht-Lösung ein Replatforming-Ereignis, ein reiner Theme-Fix nicht.

FAQ

Löst der Wechsel von Luma zu Hyvä die Core Web Vitals? Er verbessert sie spürbar, typischerweise von 4-7 Sekunden mobilem LCP auf 2-3 Sekunden, adressiert aber nicht den Render-Pfad, die Drittanbieter-Skript-Governance oder die Multi-Brand-Skalierungsfragen, die entscheiden, ob die Core Web Vitals grün bleiben, während der Storefront wächst.

Müssen wir von Magento weg migrieren, um das zu lösen? Nein. Magento bleibt in beiden Szenarien die Commerce-Engine. Die Frontend-Schicht koppelt sich an Magentos GraphQL-API und kann ohne Backend-Migrationsprojekt ergänzt werden.

Wie lange dauert die Einführung einer entkoppelten Frontend-Schicht? Typischerweise Wochen für einen Single-Store-DACH-Shop, inklusive GraphQL-Connector-Setup und Komponenten-Mapping, gegenüber den 6 Wochen bis 8 Monaten, die ein Hyvä-Migrationsprojekt typischerweise braucht.

Ersetzt das Hyvä komplett? Es ersetzt die Fragestellung, nicht zwingend die bereits getätigte Theme-Investition. Teams mitten in der Hyvä-Migration können die Frontend-Schicht ergänzen, um die Governance- und Multi-Brand-Lücken zu schließen, die Hyvä allein nicht löst.

Nächste Schritte

Wenn das Core-Web-Vitals-Thema nach jedem Theme-Projekt wieder aufmacht, liegt die Lösung wahrscheinlich eine Schicht tiefer. Sprecht mit uns darüber, wie eine Magento-GraphQL-Anbindung mit einer dedizierten Frontend-Schicht für euren Storefront aussieht, oder startet mit der Performance-Produkt-Seite, um zu sehen, was "ab Werk eingebaut" tatsächlich abdeckt.

Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr.