Magento Performance, gebaut fur deine echten Besucher

Warum Magento standardmassig langsam ist

Magento 2 wurde fur Flexibilitat und Erweiterbarkeit gebaut, nicht fur Geschwindigkeit. Eine Standard-Magento-Installation mit ein paar popularen Extensions liefert bereits ein JavaScript-Bundle, fur dessen Parsing der Browser Sekunden benotigt, bevor etwas sichtbar wird.

• ▸Schweres Theme-JavaScript: Frameworks wie Infortis Ultimo oder RWD laden vollstandige UI-Bibliotheken, auch auf Seiten, die sie nicht verwenden.
• ▸RequireJS Module-Loading: Magentos Frontend-Bundle-System ist fur Kompatibilitat gebaut, nicht fur 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 pruefen, ob es dort benotigt 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 erklart, warum Lab-Scores fur 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 tatsachlich erleben.

Lab misst auf einem simulierten Gerat: 4-facher CPU-Throttle, Slow 4G, Lighthouse-Engine auf einem Google-Server. Field-Data misst auf der Hardware und den Verbindungen echter Besucher uber die letzten 28 Tage. Fur 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 uber 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 fur das, was deine Kunden erleben, nicht fur das, was Lighthouse berichtet. CrUX ist die Wahrheitsquelle fur Core Web Vitals-Ranking in Google.

Mein Audit-Ansatz fur 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: Lauft der Shop im Developer-Mode auf Produktion? Dann lauft RequireJS unbundled und jede JS-Datei ist ein separater Request.
• ▸Full Page Cache Status: Ist Varnish oder Magento FPC aktiv und korrekt konfiguriert? TTFB uber 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-Unterstutzung uber 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 durfen 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 benotigt werden. Ich schreibe ein Modul, das die CSP korrekt durchsetzt, ohne Funktionalitat zu beeintrachtigen.
• ▸MagePack Bundle-Tuning: MagePack gruppiert RequireJS-Module pro Seitentyp. Falsche Konfiguration ergibt grossere Bundles. Ich analysiere das Bundle-Profil und passe die Konfiguration an.
• ▸Full Page Cache Warming: Ein kalter Cache fuhrt zu hohem TTFB beim ersten Besucher. Mit einem Cache-Warmer-Script wird jede Seite vorab generiert.

Welche dieser Fixes zutreffen, hangt 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 fur Field-Data, nicht fur Lab-Screenshots.
• ✕Unberechtigte Preload-Hints: fetchpriority=high auf Ressourcen, die nicht auf dem kritischen Pfad liegen, gibt dem Browser falsche Prioritatssignale und kann die Performance verschlechtern.
• ✕Theme-Rewrites ohne Kostenanalyse: Eine vollstandige Hyva-Migration lost 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 Stabilitatsscore durch Verbergen von Elementen zu verbessern, lost 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 fur den Rest des Shops.

Verwandte Seiten