Magento Performance, gebaut für deine echten Besucher

Warum Magento standardmassig langsam ist

Magento 2 wurde für Flexibilität und Erweiterbarkeit gebaut, nicht für Geschwindigkeit. Eine Standard-Magento-Installation mit ein paar popularen Extensions liefert bereits ein JavaScript-Bundle, für dessen Parsing der Browser Sekunden benötigt, bevor etwas sichtbar wird.

• Schweres Theme-JavaScript: Frameworks wie Infortis Ultimo oder RWD laden vollständige UI-Bibliotheken, auch auf Seiten, die sie nicht verwenden.
• RequireJS Module-Loading: Magentos Frontend-Bundle-System ist für Kompatibilität gebaut, nicht für Performance. Jedes Modul ladt seine eigenen Abhangigkeiten in einem Wasserfall von Requests.
• Plumrocket und Cookie-Consent-Plugins: Diese Module injizieren Scripts, die render-blocking sind, solange keine Nutzer-Einwilligung vorliegt.
• Plugin Sprawl: Jede Extension fugt CSS und JavaScript zu jeder Seite hinzu, ohne zu prüfen, ob es dort benötigt wird.
• Keine Hero LCP-Priorisierung: Das Produkt-Hero oder Banner-Bild wird standardmassig wie ein normales Bild behandelt, ohne Eager-Load oder fetchpriority.
• Shared Hosting TTFB: Auf Hypernode-Planen, die nicht gut konfiguriert sind, oder in Shared-Umgebungen ohne Full Page Cache, uberschreitet die Time to First Byte bereits 800ms.

PSI Lab simuliert dies unter Worst-Case-Bedingungen: 4-facher CPU-Throttle, Slow 4G Netzwerk. Das erklärt, warum Lab-Scores für Magento-Shops so niedrig ausfallen. Es ist kein Zeichen, dass der Shop unbrauchbar ist. Es ist ein Signal, dass Verbesserungspotenzial besteht, das echte Besucher direkt spuren werden.

PSI Lab versus CrUX: was echte Besucher erleben

PageSpeed Insights zeigt zwei Datentypen nebeneinander, und die meisten Shop-Betreiber lesen nur den Lab-Score. Das ist die Zahl, die variiert und enttauscht. Die Field-Data darunter, gespeist vom Chrome User Experience Report (CrUX), ist das, was deine Kunden tatsächlich erleben.

Lab misst auf einem simulierten Gerät: 4-facher CPU-Throttle, Slow 4G, Lighthouse-Engine auf einem Google-Server. Field-Data misst auf der Hardware und den Verbindungen echter Besucher über die letzten 28 Tage. Für Magento-Shops, die hauptsachlich Desktop-Traffic haben oder Besucher mit 4G+-Verbindungen, ist der Unterschied zwischen Lab und Field erheblich.

Bei CarCare24 lag der mobile Lab-LCP bei 14 bis 16 Sekunden. Der CrUX-LCP über 28 Tage: 2,14 Sekunden. Das liegt nicht daran, dass der Shop so gut abschneidet, dass Lab nicht mithalten kann. Es liegt daran, dass Lab ein Worst-Case-Szenario simuliert. Ich optimiere für das, was deine Kunden erleben, nicht für das, was Lighthouse berichtet. CrUX ist die Wahrheitsquelle für Core Web Vitals-Ranking in Google.

Mein Audit-Ansatz für Magento 2

Ein Magento Performance-Audit beginnt nicht mit Raten. Ich messe zuerst, dann analysiere ich, dann priorisiere ich. Der Unterschied zu einem generischen Web-Performance-Audit: Ich kenne die Magento-Interna, die andere ubersehen.

• PSI API auf Homepage, Kategorieseite, Produktseite und Checkout-Seite: Jeder Seitentyp hat sein eigenes Engpass-Profil.
• Network Waterfall in Chrome DevTools: Welcher Request ist der LCP-Kandidat, was ladt davor, welches Script blockiert das Rendering.
• CrUX-Dashboard und Google Search Console CWV-Bericht: Was echte Besucher in den letzten 28 Tagen sehen, pro Seitentyp.
• Magento-Mode-Check: Läuft der Shop im Developer-Mode auf Produktion? Dann läuft RequireJS unbundled und jede JS-Datei ist ein separater Request.
• Full Page Cache Status: Ist Varnish oder Magento FPC aktiv und korrekt konfiguriert? TTFB über 800ms ist fast immer ein Cache-Miss.
• MagePack oder RequireJS-Bundle-Analyse: Ist JS bereits gebundelt und minifiziert, und wenn ja, wie ist die Bundle-Strategie eingerichtet?
• Third-Party-Impact: Wie viel Main-Thread-Zeit beanspruchen Plumrocket, GTM, Chat-Widgets und Consent-Banner zusammen?

Aus dieser Analyse ergibt sich eine priorisierte Liste von Engpassen. Nicht sortiert nach Leichtigkeit der Behebung, sondern nach Auswirkung des Fixes auf CrUX. Das ist der Unterschied zwischen Score-Chasing und tatsachlicher Verbesserung.

Was ich typischerweise bei Magento fixe

Nach dem Audit implementiere ich die Fixes mit der hochsten CrUX-Wirkung. Bei Magento-Shops handelt es sich fast immer um eine Kombination der folgenden Eingriffe:

• Hero-Image: loading=eager und fetchpriority=high auf dem LCP-Kandidaten. Das ist der schnellste Gewinn bei fast jedem Magento-Shop. Das Banner oder Produktbild above the fold wird standardmassig lazy-geladen. Das ist genau falsch.
• WebP-Konvertierung: Magento 2.4.x hat eingebaute WebP-Unterstützung über die Media Gallery. Aktivieren und Testen per Browser-Support ist eine Frage der Konfiguration.
• Deferred Third-Party Scripts: Plumrocket Consent, GTM, Livechat-Widgets und Social Embeds werden nach dem First Contentful Paint verschoben. Sie dürfen das Rendering nicht blockieren.
• Custom CSP-Modul: Eine Content Security Policy, die zu breit oder zu permissiv ist, blockiert auf manchen Magento-Installationen Scripts, die benötigt werden. Ich schreibe ein Modul, das die CSP korrekt durchsetzt, ohne Funktionalität zu beeintrachtigen.
• MagePack Bundle-Tuning: MagePack gruppiert RequireJS-Module pro Seitentyp. Falsche Konfiguration ergibt größere Bundles. Ich analysiere das Bundle-Profil und passe die Konfiguration an.
• Full Page Cache Warming: Ein kalter Cache führt zu hohem TTFB beim ersten Besucher. Mit einem Cache-Warmer-Script wird jede Seite vorab generiert.

Welche dieser Fixes zutreffen, hängt von deiner Installation, deinem Theme und deinem Extension-Set ab. Auf einer Hypernode-Umgebung mit Cloudflare Free stehen andere Hebel zur Verfugung als auf einem generischen VPS. Ich passe den Ansatz an das an, was dein Stack erlaubt.

Was ich nicht tue

Es gibt Moglichkeiten, einen Lighthouse-Score nach oben zu drucken, ohne dass Besucher davon profitieren. Ich verwende sie nicht und erklare immer, warum eine bestimmte Taktik nicht empfehlenswert ist.

• Score-Chasing ohne CrUX-Kontext: Ein Score von 90 im Lab, der sich nicht in CrUX-Field-Data widerspiegelt, ist wenig wert. Ich optimiere für Field-Data, nicht für Lab-Screenshots.
• Unberechtigte Preload-Hints: fetchpriority=high auf Ressourcen, die nicht auf dem kritischen Pfad liegen, gibt dem Browser falsche Prioritätssignale und kann die Performance verschlechtern.
• Theme-Rewrites ohne Kostenanalyse: Eine vollständige Hyvä-Migration löst vieles, kostet aber auch erheblich. Wenn der aktuelle Stack mit gezielten Fixes bereits CrUX-Ziele erreicht, ist ein Theme-Rewrite keine proportionale Wahl.
• Bilder verstecken, um CLS zu senken: Den visuellen Stabilitätsscore durch Verbergen von Elementen zu verbessern, löst die Ursache nicht.
• Leichtere Seiten an Bots ausliefern: Google erkennt Cloaking und bestraft es. Die Seite, die Lighthouse sieht, muss identisch mit dem sein, was Besucher sehen.

Ich gebe immer Einblick in die Abwagung: Was kostet ein Fix, was bringt er in CrUX, und wie ist die Risikobewertung für den Rest des Shops.

Verwandte Seiten