Wird Magento 2 mit dem Hyvä-Theme immer schneller laufen als mit jedem anderen Theme?

Stellen Sie sich zwei Magento-Shops vor. Der erste nutzt Hyvä, startet aber direkt beim Einstieg ein Dutzend Marketing-Tools, lädt große Bilder und generiert die Seite jedes Mal neu. Der zweite verwendet ein anderes, sorgfältig optimiertes Theme, einen funktionierenden Cache und nur die Skripte, die der Kunde wirklich benötigt.

Welcher Shop ist schneller? Der Name des Themes reicht für eine Antwort nicht aus.

Hyvä gibt Magento einen sehr guten Ausgangspunkt für den Aufbau eines schnellen Shops. Es bietet jedoch keinen bedingungslosen Vorteil gegenüber jeder anderen Umsetzung. Das Ergebnis hängt von der gesamten Strecke zwischen dem Klick auf einen Link und dem Moment ab, in dem der Kunde das Produkt sieht und kaufen kann.

Deshalb lohnt es sich, die Hyvä-Implementierung mit einer Prüfung von Server, Modulen, Bildern und Interface-Design zu verbinden. Dann kann man auf ein ambitioniertes Ziel hinarbeiten: 95–100 Punkte in Google PageSpeed Insights, bei gleichzeitiger Beibehaltung der für den Verkauf benötigten Funktionen.

Was bedeutet ein Ergebnis von 95–100 in PageSpeed eigentlich?

Umgangssprachlich sprechen wir von 100% in PageSpeed, das Tool zeigt jedoch Punkte auf einer Skala von 0 bis 100 an. Im Lighthouse-basierten Teil bewertet es vier verschiedene Bereiche:

Diese Bewertungen ersetzen einander nicht. Ein schneller Shop kann unleserliche Buttons haben. Ein technisch korrekter Shop kann zu viel JavaScript laden. Lighthouse ist ein Diagnosetool, und der Umfang seiner Audits deckt nicht die gesamte Shop-Qualität ab. Beschreibung von Lighthouse.

Der Performance-Wert stammt aus einer Labormessung und kann sich zwischen einzelnen Versuchen ändern. PageSpeed zeigt außerdem, sofern verfügbar, reale Nutzerdaten aus CrUX an, die über einen gleitenden Zeitraum von 28 Tagen gesammelt werden. Eine neue Implementierung verändert diesen gesamten Datensatz nicht sofort. So funktioniert PageSpeed Insights.

In der Praxis brauchen wir zwei Ziele: wiederholbar gute Tests und gute Kundenerlebnisse. Für Core Web Vitals bedeutet das:

• LCP bis 2,5 s — schnelles Erscheinen des größten Elements im sichtbaren Bereich;
• INP bis 200 ms — zügige Reaktion auf Interaktionen;
• CLS bis 0,1 — stabiles Seitenlayout.

Diese Schwellenwerte werden im 75. Perzentil bewertet, getrennt für Mobilgeräte und Desktop. Der standardmäßige Lighthouse-Ladetest misst INP nicht; zur Diagnose von Browser-Blockierungen nutzt er unter anderem TBT. Ein niedriger TBT ist keine automatische Bestätigung für einen guten INP. Core Web Vitals.

Wie hilft Hyvä dabei, Magento zu beschleunigen?

Hyvä reduziert das Gewicht des Frontends im Vergleich zum Standard-Theme Luma. Es nutzt Alpine.js für Interaktionen und Tailwind CSS für das Styling. Weniger Code zum Herunterladen und Ausführen gibt dem Browser mehr Spielraum, das Angebot schnell anzuzeigen. Die Hyvä-Dokumentation nennt die Reduzierung von JavaScript und CSS als wichtigen Bestandteil dieser Architektur. Hyvä-Performance.

Dieser Vorteil lässt sich jedoch leicht verringern. Es genügt, dem schlanken Frontend einen umfangreichen Slider, einen Chat, mehrere Tracker und Module hinzuzufügen, die alte Abhängigkeiten aus dem vorherigen Theme übernehmen.

Hyvä behebt auch keine langsame Datenbankabfrage, keinen nicht funktionierenden Cache und keinen Server, der gerade mit einem Import ausgelastet ist. Deshalb sollte die Frage vor der Implementierung lauten: Was verzögert heute den Kauf und welche dieser Probleme löst ein Frontend-Wechsel?

1. Server: nginx und Varnish müssen die richtige Arbeit leisten

Bevor der Browser das Produkt anzeigt, muss er das HTML-Dokument erhalten. Wenn er lange auf das erste Byte der Antwort wartet, startet selbst ein leichtes Theme mit Verzögerung.

Nginx: effiziente Bereitstellung von Ressourcen

In einer typischen Magento-Architektur übernimmt nginx unter anderem HTTPS, statische Dateien und die Weiterleitung von Anfragen an weitere Dienste. Es lohnt sich, die Komprimierung textbasierter Antworten, HTTP/2 sowie Cache-Header für versionierte CSS- und JS-Dateien zu prüfen. Adobe stellt eine beispielhafte nginx-Konfiguration als Ausgangspunkt für eine Implementierung mit Varnish bereit. Varnish-Konfiguration in Adobe Commerce.

Nicht alle Antworten sollten dieselbe Aufbewahrungszeit erhalten. Ein versioniertes CSS-Stylesheet kann lange aus dem Browser-Cache genutzt werden. Preis, Warenkorbinhalt und Antworten für angemeldete Kunden erfordern eine andere Behandlung.

Wenn der Server WebP anhand des Headers Accept auswählt, müssen auch der Cache-Schlüssel und der Header Vary: Accept geprüft werden. Browser und zwischengeschaltete Cache-Schichten müssen die Bildvarianten unterscheiden können.

Varnish: Wir prüfen Cache-Treffer, nicht nur die Installation des Dienstes

Varnish ermöglicht es, öffentliche Seiten aus dem Cache auszuliefern, ohne dass Magento die gesamte Arbeit erneut ausführen muss. Adobe empfiehlt den Einsatz in Produktionsumgebungen. Magento-Cache-Verwaltung.

Der praktische Test ist einfach: Wir öffnen dieselbe öffentliche Adresse mehrmals und prüfen, ob nach der ersten Antwort HIT-Treffer erscheinen. Anschließend vergleichen wir die Antwortzeit aus dem Cache mit der Zeit für die Seitengenerierung bei MISS.

Wenn eine beliebte Kategorie den Cache dauerhaft umgeht, muss die Ursache gefunden werden: Konfiguration, Cookies, URL-Parameter, Personalisierung oder die Funktionsweise eines Moduls. Der Kauf eines größeren Servers kann das Problem dann nur kaschieren.

Wichtig ist auch die Korrektheit. Der Cache darf den Warenkorb oder die Daten eines Kunden nicht einem anderen Nutzer bereitstellen. Shop-Varianten, Währungen und Kundengruppen sowie die Aktualisierung von Inhalten nach einer Produktänderung müssen getestet werden. Ein schneller, aber veralteter Preis ist kein Erfolg der Optimierung.

Neben nginx und Varnish prüfen wir PHP-FPM, OPcache, einen zur Magento-Version passenden Backend-Cache, die Datenbank, Cron und die Indexierung. Die Anzahl der PHP-Prozesse sollte sich aus dem verfügbaren Arbeitsspeicher und der tatsächlichen Last ergeben. Eine Erhöhung ohne Messung kann die Situation verschlechtern.

2. Module für Hyvä: Kompatibilität ist erst der Anfang

Ein Modul kann korrekt mit Hyvä funktionieren und beim Seitenaufruf dennoch zu viel Arbeit verursachen. Gute Optimierung umfasst daher sowohl die Funktion als auch die Kosten ihrer Ausführung.

Bei kowal.store passen wir unsere Module an Hyvä an und entwickeln sie mit dem Ziel weiter, die Performance dieses Themes nach der Installation zu erhalten. Wir achten darauf, dass neue Funktionen das Frontend nicht unnötig belasten — durch die Begrenzung von Abhängigkeiten sowie eine geeignete Art, JavaScript und CSS zu laden. Sehen Sie sich unsere Magento 2-Module an und wählen Sie Erweiterungen für Ihren Shop. Den Effekt einer konkreten Implementierung sollte man durch Messungen bestätigen, da er auch von der Konfiguration und den übrigen Integrationen abhängt.

Nehmen wir einen Chat. Ein Kunde, der eine Kategorie durchsucht, benötigt am Anfang eine Schaltfläche zum Öffnen des Gesprächs. Die umfangreiche Chat-Oberfläche und ihre Bibliotheken können beim Öffnen geladen werden. Ähnlich lassen sich vollständige Suchvorschläge beim Einstieg in das Suchfeld vorbereiten, während ein sofort sichtbares und funktionierendes Formular bereitsteht.

Diesen Ansatz beschreibt Hyvä auch in den Empfehlungen zum Laden von externem JavaScript.

defer, async und die Verzögerung einer Komponente sind verschiedene Dinge

defer ermöglicht es, ein externes klassisches Skript nach der Verarbeitung des Dokuments auszuführen und die Reihenfolge dieser Skripte beizubehalten. async startet das Skript, sobald es bereit ist, ohne Garantie der Reihenfolge gegenüber anderen Skripten. Keines dieser Attribute bedeutet für sich genommen, dass die Datei erst nach einem Klick heruntergeladen wird.

Hyvä stellt außerdem x-defer bereit, mit dem die Initialisierung einer Alpine-Komponente verzögert werden kann, z. B. bis sie sich dem sichtbaren Bereich nähert. Das ist kein automatisches Aufschieben des Downloads all ihrer Dateien. Man muss auch an Ereignisse denken, die eine Komponente vor der Initialisierung verpassen kann, z. B. solche im Zusammenhang mit Kundendaten. x-defer-Dokumentation.

Änderungen sollten am Warenkorb, an Filtern, Formularen und Analyseereignissen geprüft werden. Das bloße Vorhandensein des Attributs defer beweist nicht, dass ein Modul gut optimiert ist.

CSS: Das benötigte Erscheinungsbild sollte vor dem ersten Rendering bereitstehen

Styles für Header, Produktliste und mobiles Layout werden von Anfang an benötigt. Werden sie zu spät geladen, kann dies zu Flackern der Seite und Layout-Verschiebungen führen. Gleichzeitig muss eine Produktkategorie nicht alle Styles jedes installierten Moduls laden.

Es lohnt sich, globale Stylesheets zu begrenzen, Reste des alten Themes zu entfernen und den produktiven Tailwind-Build zu prüfen. Bei dynamisch erzeugten Klassen muss sichergestellt werden, dass die benötigten Regeln im resultierenden CSS enthalten sind. Kritisches CSS, das in HTML eingebettet ist, kann helfen, erfordert aber Pflege und Tests; es sollte nicht die erste Antwort auf jedes Problem sein. Render-blockierende Ressourcen.

Auch Analytics und SEO-Daten haben ihren Preis

Bei der Optimierung eines Shops auf Magento 2 haben wir die Analytics-Belastung auf einer Kategorieseite geprüft. GTM und gtag machten etwa 304 KB aus, also 44% des Transfers, der in der ersten mobilen Messung registriert wurde. Das ist ein guter Grund, Tags und Trigger zu überprüfen. Es bedeutet jedoch nicht, dass man die gesamte Analytics ohne Überlegung verzögern sollte: Eine solche Änderung kann die Anzahl der erfassten Besuche und Ereignisse verändern.

Auch ein Blick in das HTML selbst lohnt sich. Umfangreiche JSON-LD-Daten, doppelte Produktinformationen und Modulkonfigurationen vergrößern die Serverantwort. JSON-LD wird nicht wie ein normales JavaScript-Programm ausgeführt, muss aber dennoch übertragen werden. Strukturierte Daten einer Kategorie sollten zur sichtbaren Liste, ihrer Paginierung und Reihenfolge passen.

3. Bilder: Format, Größe und Zeitpunkt des Downloads zählen

Ein Quellbild mit mehreren tausend Pixeln Breite sollte nicht unnötig in einer kleinen Produktkachel landen. Wir bereiten Varianten vor, die zur Anzeigegröße und Pixeldichte des Bildschirms passen, und srcset sowie sizes helfen dem Browser, die richtige Datei auszuwählen. WebP oder AVIF sollte man anhand konkreter Bilder in Bezug auf Qualität und Dateigröße vergleichen.

Die wichtigste Unterscheidung betrifft Bilder, die sofort sichtbar sind, und solche, die weiter unten liegen. Ein Bild, das LCP ist, sollte im HTML leicht auffindbar sein, ohne loading='lazy'; fetchpriority='high' kann gerechtfertigt sein. Bilder außerhalb des ersten Bildschirms sind gute Kandidaten für Lazy Loading. Maße oder Seitenverhältnisse reservieren ihnen Platz im Layout. Responsive Bilder.

Wir geben jedoch nicht jedem Bild eine hohe Priorität. Der Browser braucht Informationen darüber, was wirklich am wichtigsten ist. Fetch Priority.

Wir prüfen außerdem CMS-Banner, Logo, Favicon, Video-Thumbnails und Popup-Grafiken. Die Optimierung muss den Prozess zum Hinzufügen neuer Dateien umfassen, sonst bringt die nächste Kampagne schwere Bilder zurück.

Allein eine Adresse, die auf .png endet, entscheidet nicht darüber, was der Browser herunterlädt. Der Server kann unter dieser Adresse WebP ausliefern. Wir überprüfen Content-Type und den Transfer im Network-Tab.

4. Farbgebung: Den größten Einfluss sehen Sie bei der Barrierefreiheit

Ein blauer Button, der grün wird, beschleunigt Magento nicht. Farbe hat jedoch eine große Bedeutung für Lesbarkeit und den Accessibility-Wert.

Am häufigsten verursachen hellgraue Beschreibungen, pastellfarbene Buttons mit weißem Text, Aktionslabels und Text auf Bildern Probleme. Gemäß WCAG sollte der Kontrast von normalem Text mindestens 4,5:1 und von großem Text 3:1 betragen. Großer Text bedeutet mindestens 18 pt, also etwa 24 px, oder 14 pt bei Fettschrift, also etwa 18,7 px. Anforderungen an den Textkontrast.

Für wesentliche visuelle Elemente von Bedienelementen und Zustandskennzeichnungen gilt ebenfalls eine Kontrastanforderung von 3:1 gegenüber benachbarten Farben, mit den im Standard beschriebenen Ausnahmen. Kontrast nicht textlicher Elemente.

Die Palette sollte zentral definiert werden, z. B. über CSS-Variablen oder die Konfiguration eines Farbmoduls. So umfasst eine Änderung der Text- oder Button-Farbe den gesamten Shop. Auch Hover-, Focus-Zustände, Formularfehler und ausgewählte Filter müssen geprüft werden. Eine rote Umrandung sollte nicht die einzige Information sein, dass ein Feld einen Fehler enthält.

Die Performance kann durch die Art der Umsetzung des Erscheinungsbilds beeinflusst werden: zusätzliche Stylesheets, ein Skript, das Farben nach dem Laden ändert, oder schwere visuelle Effekte. Die Palette selbst ist jedoch kein Ersatz für die Optimierung von JS, Bildern und Server.

Warum reicht ein einziges gutes Ergebnis nicht aus?

Bei der Optimierung eines Magento 2-Shops mit Hyvä haben wir zwei lokale Lighthouse-Messungen für dieselbe Kategorieseite durchgeführt. Auf Mobile erreichten wir 94 und 73 Punkte. Der LCP betrug jeweils 2,5 und 5,7 s, obwohl er in beiden Fällen dasselbe Bild des ersten Produkts betraf. Desktop erreichte 100 Punkte.

Alle diese Durchläufe meldeten eine Überschreitung des Ladezeitlimits, daher behandelten wir die Ergebnisse als diagnostisch und potenziell unvollständig. Es waren keine bestätigten PageSpeed Insights-Ergebnisse und keine CrUX-Daten. Es ist auch kein Vergleich von Hyvä mit einem anderen Theme.

Im schwächeren Versuch wurde das Bild schnell heruntergeladen, aber seine Anzeige erfolgte später. Das zeigt, warum man Downloadzeit und Renderzeit voneinander trennen muss. Eine weitere Komprimierung der Datei allein erklärt ein solches Problem nicht. Analyse der LCP-Phasen.

Bei der Arbeit am Shop vergleichen wir mehrere Versuche, Median und Streuung, bei gleichen Bedingungen. Berichte mit Fehlern behandeln wir nicht als stabilen Referenzpunkt. Wir prüfen auch das Verhalten nach dem Akzeptieren von Cookies, nach dem Öffnen der Suche und nach dem Hinzufügen eines Produkts zum Warenkorb.

Magento- und Hyvä-Checkliste: der Weg zu 95–100 Punkten

Die folgende Liste hilft bei der Planung von Audit und Abnahme der Arbeiten. Sie ist keine Garantie für vier Ergebnisse von 100/100. Die Bewertung hängt von Seite, Konfiguration, Testbedingungen und Lighthouse-Version ab. Ein grünes Ergebnis ersetzt außerdem keine manuellen Barrierefreiheitstests, kein Sicherheitsaudit und keine SEO-Strategie.

Messung und Referenzpunkt

• Startseite, Kategorie, Produkt, Suche und zentrale Kaufschritte wurden untersucht.
• Separate Messungen für Mobile und Desktop wurden in mehreren vergleichbaren Versuchen durchgeführt.
• Tool-Version, Geräteprofil, Zustimmungsstatus und Ergebnisbereich wurden dokumentiert; Timeouts wurden erklärt.
• LCP, INP und CLS wurden aus CrUX oder eigenem Monitoring geprüft, sofern verfügbar.
• Daten einer einzelnen URL wurden von Daten der gesamten Domain unterschieden.
• Erstbesuch, Rückkehr eines Nutzers und Verhalten nach Interaktion wurden getestet.

Server, nginx und Varnish — Performance

• Magento läuft im Produktionsmodus, mit korrekt vorbereiteten statischen Ressourcen.
• Öffentliche Seiten erreichen Varnish HIT; auch die Antwortzeit bei MISS wurde geprüft.
• Der Cache unterscheidet Shop-Varianten korrekt, und private Daten gelangen nicht in eine gemeinsame Antwort.
• Eine Änderung von Produkt, Preis oder Inhalt invalidiert den passenden Cache korrekt.
• Nginx komprimiert passende textbasierte Ressourcen und unterstützt ein modernes HTTP-Protokoll.
• Versionierte Dateien haben passende Cache-Header; HTML und private Antworten haben eine separate Richtlinie.
• PHP-FPM, OPcache und Backend-Cache sind gemäß Magento-Version und Serverressourcen konfiguriert.
• Cron, Indexierung, Importe und Bots verursachen keine Sprünge in der Antwortzeit.

Module, JavaScript und CSS — Performance

• Jedes aktive Modul hat eine geschäftliche Begründung; unnötige Funktionsduplikate wurden entfernt.
• Hyvä-Integrationen bringen nicht unnötig schwere Abhängigkeiten des vorherigen Frontends zurück.
• JS und CSS von Modulen landen nur auf Seiten, die deren Funktionen verwenden.
• Skripte wurden unter Beachtung von Abhängigkeiten, Reihenfolge und Initialisierungsereignissen verzögert.
• Selektives x-defer und das Laden von Komponenten bei Nutzung wurden getestet.
• Kritische Styles sind vor dem ersten Rendering verfügbar; es tritt kein Layout-Flackern auf.
• GTM, Pixel, Chat und Widgets wurden hinsichtlich Triggern und Startkosten überprüft.
• Analytics-Änderungen behalten das vereinbarte Zustimmungsverhalten und korrekte E-Commerce-Ereignisse bei.
• HTML, DOM und JSON-LD enthalten keine unnötigen, doppelten Daten.
• Warenkorb, Filter, Sortierung, Paginierung und Checkout funktionieren nach der Optimierung.

Bilder und Layout-Stabilität — Performance

• Grafiken haben passende Maße, Qualität und Format; der tatsächliche Transfer wurde verifiziert.
• Responsive Bildvarianten entsprechen den Anzeigegrößen.
• Das LCP-Element wurde getrennt für Mobile und Desktop ermittelt.
• Das LCP-Bild wird nicht durch Lazy Loading oder unnötige JS-Initialisierung verzögert.
• Hohe Priorität wurde nur begründeten Ressourcen zugewiesen.
• Bilder, Banner und eingebettete Inhalte haben reservierten Platz im Layout.
• Logo, Favicon, CMS-Grafiken und durch Module hinzugefügte Bilder wurden geprüft.
• Der Prozess zur Veröffentlichung neuer Bilder umfasst die Generierung optimierter Varianten.

Farben und Bedienung der Oberfläche — Accessibility

• Text, Preise, Buttons und Meldungen haben den erforderlichen Kontrast auf realen Hintergründen.
• Der Kontrast wichtiger Bedienelemente und die Sichtbarkeit des Tastaturfokus wurden geprüft.
• Fehler, Aktion und Auswahl werden nicht ausschließlich durch Farbe kommuniziert.
• Links und Buttons haben verständliche zugängliche Namen; Formulare haben Labels.
• Informative Bilder haben einen passenden Alternativtext, dekorative Bilder ein leeres alt.
• Menü, Filter, Popups und Warenkorb lassen sich per Tastatur bedienen.
• Seitenzoom, kleiner Bildschirm und grundlegende Bedienung mit Screenreader wurden geprüft.

Technische Qualität — Best Practices

• Die Seite und ihre Ressourcen funktionieren über HTTPS, ohne Mixed Content.
• Konsolenfehler, fehlgeschlagene Anfragen und vom Audit gemeldete Warnungen wurden erklärt.
• Bibliotheken und Module werden gepflegt; gemeldete Schwachstellen wurden geprüft.
• Bilder behalten ihre Proportionen, und Funktionen verwenden nicht unnötig veraltete APIs.
• Ein hoher Wert wurde zusammen mit funktionierenden Zahlungen, Formularen und Zustimmungen bestätigt.

Technische Sichtbarkeit — SEO

• Für die Indexierung vorgesehene Seiten geben den richtigen Status zurück und haben kein versehentliches noindex.
• robots.txt blockiert keine benötigten Seiten oder Ressourcen.
• Titel und Meta Description entsprechen dem Seiteninhalt.
• Canonical ist korrekt; Sprachversionen und hreflang wurden separat geprüft.
• Navigationslinks sind für Bots lesbar, und die Paginierung funktioniert korrekt.
• Strukturierte Daten wurden mit einem separaten Tool verifiziert und entsprechen dem sichtbaren Inhalt.
• Sitemap und Indexierung in Search Console wurden überprüft — auch außerhalb der Lighthouse-Bewertung.

Automatische Barrierefreiheitstests decken nur einen Teil der möglichen Probleme ab. Selbst ein Ergebnis von 100 erfordert eine ergänzende manuelle Prüfung. Wie Barrierefreiheit in Lighthouse berechnet wird.

Womit sollte man die Arbeit am eigenen Shop beginnen?

Zuerst klären wir, worauf der Kunde wartet. Wenn es die Serverantwort ist — beginnen wir mit Backend und Cache. Wenn es ein Bild ist — prüfen wir dessen Erkennung, Download und Anzeige. Wenn die Seite sichtbar ist, aber verzögert reagiert — analysieren wir die Arbeit von JavaScript und Komponenten.

Anschließend implementieren wir eine logische Gruppe von Verbesserungen und wiederholen Messungen sowie Kaufpfad-Tests. So ist klar, was geholfen hat und ob der Aufwand der Änderung gerechtfertigt war. Das bloße Erreichen der Core Web Vitals-Schwellen garantiert keinen Wert von 95: Performance wird aus mehreren gewichteten Metriken berechnet. Lighthouse-Bewertungsregeln.

Hyvä ermöglicht den Start mit einem schlanken Frontend. Diesen Vorteil zu erhalten, erfordert bewusste Entscheidungen bei jedem weiteren Modul, Banner und Marketing-Tool. Es lohnt sich daher, Performance als Abnahmekriterium für weitere Implementierungen zu behandeln und nicht als einmaliges Projekt, das mit einem Screenshot eines grünen Ergebnisses endet.

Wenn Sie eine Hyvä-Implementierung planen oder einen bestehenden Shop beschleunigen möchten, kontaktieren Sie das Team von kowal.store. Ausgangspunkt sollte ein Audit konkreter Seiten und des Kaufpfads sein — mit einer Liste von Ursachen, Prioritäten sowie Messungen vor und nach den Änderungen.