Kategorien und Listings
Wir prüfen die Anzahl der Operationen beim Erzeugen von Produktlisten, Preisen, Attributen und Filtern.
Magento-Performanceoptimierung
Der Shop lädt lange. Suche und Administrationsbereich werden immer langsamer. Weitere Korrekturen bringen nur vorübergehende Verbesserungen, danach kehrt das Problem zurück.
In dieser Situation beginnen wir nicht mit zufälligen Versuchen, „Magento zu beschleunigen“. Zuerst messen wir die Plattform und bestimmen, wo der tatsächliche Engpass liegt.
Erst danach entscheiden wir, was optimiert werden sollte.
Ein kostenloses Gespräch von 30–60 Minuten. Wir besprechen die Symptome, vorhandene Messwerte und die Architektur der Plattform. Wir zeigen auf, mit welchen Daten und Tests die Diagnose beginnen sollte.
Diagnose
Ein langsamer Shop ist ein Symptom
Bei Magento zeigt das sichtbare Problem nicht immer seine Ursache.
Eine langsame Kategorie kann durch eine Datenbankabfrage, das Laden von Attributen, ein Drittanbieter-Modul oder die Indexierung verursacht werden. Eine langsame Suche kann an der OpenSearch-Konfiguration liegen, ebenso aber am Datenmodell oder am Aufbau der Abfragen.
Zusätzlicher Cache oder mehr Serverressourcen können die Symptome vorübergehend mindern, lösen aber nicht zwingend die Ursache.
Deshalb beginnen wir mit einer Diagnose und nicht mit einer vorgefertigten Änderungsliste.
Analyseumfang
Was wir diagnostizieren
Meist analysieren wir mehrere Bereiche gleichzeitig.
Produktseiten
Wir analysieren den Aufwand für das Laden von Attributen und verwandten Produkten sowie für zusätzliche Module, die bei jeder Anfrage ausgeführt werden.
Suche und OpenSearch
Wir prüfen die Indexstruktur, den Aufbau der Abfragen und den Umfang der von der Suchmaschine verarbeiteten Daten.
Datenbank und SQL
Wir suchen nach aufwendigen und wiederholten Abfragen sowie nach Operationen, die häufiger als nötig ausgeführt werden.
Cache
Wir prüfen die Konfiguration und ob der Cache den Arbeitsaufwand der Anwendung tatsächlich reduziert.
Infrastruktur
Wir analysieren, ob die Umgebung passend zur Arbeitsweise der jeweiligen Plattform ausgelegt ist.
Auch das Frontend ist Teil der Analyse. Erweist es sich als Hauptengpass, suchen wir nicht zwanghaft im Backend nach einem Problem.
So arbeiten wir
So arbeiten wir
-
01
Diagnose
Wir beginnen mit Diagnose und Profiling.
-
02
Prioritäten
Auf dieser Grundlage setzen wir Prioritäten - nicht alles muss gleichzeitig geändert werden. Zuerst bearbeiten wir die Bereiche, die im Verhältnis zu Kosten und Risiko die größte Wirkung erzielen.
-
03
Änderungen
Wir führen Änderungen schrittweise ein und messen das Ergebnis nach wesentlichen Anpassungen.
-
04
Entscheidung
Zeigt die Analyse, dass eine weitere Optimierung eines Bereichs wirtschaftlich nicht sinnvoll ist, sprechen wir das offen an und schlagen einen anderen Ansatz vor.
Profiling
Messungen sollen eine konkrete Frage beantworten
Wir profilieren die Plattform, um festzustellen, wo tatsächlich Zeit verloren geht, und prüfen anschließend, ob eine Änderung eine Verbesserung gebracht hat.
Wir vergleichen Messungen unter möglichst ähnlichen Bedingungen.
Nicht jedes Ergebnis muss später zu einem formalen Kundenbericht werden. Ein Teil des Profilings ist schlicht ein Arbeitswerkzeug des Teams.
Bei großen Plattformen endet die Optimierung oft nicht mit einem Projekt. Katalog, Code und Integrationen verändern sich laufend, sodass ein Engpass später an anderer Stelle auftreten kann.
Optimierungsbeispiele
Kategorien und Listings
SQL-Abfragen
- Vorher
- 652
- Nachher
- 99
Backend-Zeit
- Vorher
- 2,69 s
- Nachher
- 0,787 s
CPU-Auslastung
−65%
In einem profilierten Projekt führte die Generierung einer einzelnen Kategorie 652 SQL-Abfragen aus. Nach den Änderungen sank die Zahl auf 99 - rund 85 % weniger.
Im selben Vergleich sank die Backend-Generierungszeit der Kategorie von 2,69 s auf 0,787 s - etwa 71 % weniger - und die CPU-Auslastung ging um rund 65 % zurück.
Die Änderungen umfassten unter anderem die Optimierung von Abfragen, Indexierungsverfahren und der Arbeitsweise zusätzlicher Module.
Produktseiten
Eine Produktseite kann viele aufwendige Operationen ausführen, besonders bei umfangreichen Attributen, Empfehlungen und verwandten Produkten.
In weiteren Profilings desselben Projekts erreichten wir:
kürzere Backend-Generierungszeit der Produktseite
bis zu 62 %
weniger I/O-Operationen
bis zu 71 %
weniger CPU-Zeit
bis zu 54 %
SQL-Abfragen
- Vorher
- 373
- Nachher
- 151
Die Optimierungen betrafen unter anderem das Laden von Attributen und verwandten Produkten, Drittanbieter-Module sowie die Nutzung von OpenSearch.
Was diese Zahlen bedeuten - und was nicht
Eine schnellere Backend-Ausführung bedeutet weniger Arbeit pro Anfrage und kann der Plattform bei steigender Last mehr Ressourcenreserve lassen.
Das bedeutet jedoch nicht automatisch bessere Core Web Vitals, ein höheres Google-Ranking oder mehr Umsatz.
Die User Experience wird auch von Frontend, Bildern, Drittanbieter-Skripten, CDN, Netzwerk und dem verwendeten Gerät beeinflusst.
Wir verwenden Ergebnisse des Backend-Profilings nicht als Beleg für eine höhere Conversion.
Dies sind Ergebnisse eines vergleichbaren technischen Backend-Profilings ohne FPC und OPcache. Sie stellen weder durchschnittliche produktive Antwortzeiten noch Core-Web-Vitals-Ergebnisse dar und sind keine Zusage für bessere SEO-Rankings, Conversion oder einen bestimmten PageSpeed-Wert.
Daten und Suche
Suche und OpenSearch
OpenSearch ist nicht nur für das Suchfeld zuständig. Bei großen Katalogen ist es auch ein wichtiger Bestandteil der Filterung und Arbeit mit Katalogdaten.
Wir analysieren die Indexierung und die an die Suchmaschine gesendeten Abfragen.
Manchmal ist es effizienter, bestimmte Lesevorgänge aus der relationalen Datenbank in einen passend vorbereiteten Index zu verlagern. Das ist jedoch kein allgemeingültiges Rezept - die Entscheidung ergibt sich aus Messungen und der Datennutzung.
Datenbank und SQL
Datenbankprobleme können lange verborgen bleiben, besonders wenn der Cache einen Teil der aufwendigen Operationen überdeckt.
Wir prüfen, welche Abfragen am längsten dauern, welche mehrfach ausgeführt werden und ob Module mehr Daten laden als tatsächlich benötigt.
Manchmal bewirkt eine kleine Änderung beim Datenabruf mehr als zusätzliche Infrastrukturressourcen.
Umgebung
Cache und Infrastruktur
Redis, Varnish, PHP, Datenbank und Umgebungskonfiguration beeinflussen das Verhalten von Magento unmittelbar.
Cache ist notwendig, sollte aber nicht ausschließlich dazu dienen, aufwendigen Code zu verbergen.
Zeigt die Diagnose, dass das Problem tatsächlich in der Infrastruktur liegt, können wir auch bei ihrer Änderung oder Optimierung helfen.
Frontend
Was ist mit dem Frontend?
Diese Leistung konzentriert sich vor allem auf Backend, Daten und Infrastruktur, ignoriert das Frontend jedoch nicht.
Bei neuen Implementierungen arbeiten wir standardmäßig mit Hyvä. In älteren Shops kann das bestehende Frontend jedoch selbst eine wesentliche Problemquelle sein.
Erzeugt das Backend schnell eine Antwort, der Shop bleibt für Nutzer aber schwerfällig, kann ein Neuaufbau der Präsentationsschicht der richtige Weg sein.
In diesem Fall empfehlen wir Hyvä für Magento → , anstatt ein Frontend-Problem mit Änderungen an Datenbank oder Cache lösen zu wollen.
Einordnung
Wann eine andere Leistung benötigt wird
Große Kataloge in Magento
Wenn das Problem vor allem mit der Kataloggröße wächst und aus Datenmodell, Indexierung oder dem Umgang mit vielen Werten entsteht, kann eine auf große Magento-Kataloge ausgerichtete Analyse der bessere Ausgangspunkt sein.
große Kataloge in Magento →Hyvä für Magento
Ist das Backend schnell und liegt das Problem in der Frontend-Schicht, kann ein Neuaufbau der Präsentationsschicht mit Hyvä die passende Lösung sein.
Hyvä für Magento →Magento-Übernahme und Stabilisierung
Ist die Plattform insgesamt instabil, kehren Fehler zurück und ist der technische Zustand schwer einzuschätzen, empfiehlt sich der Einstieg mit einer Projektübernahme und Stabilisierung.
Magento-Übernahme und Stabilisierung →Fragen
FAQ
VLCT
Ohne Diagnose lässt sich keine seriöse pauschale Zahl nennen. In einem unserer Projekte sank die Backend-Generierungszeit einer Kategorie von 2,69 s auf 0,787 s. Das ist jedoch das Ergebnis einer konkreten Plattform und eines konkreten Änderungsumfangs.
VLCT
Sie kann helfen, wenn die Backend-Antwortzeit das Problem ist. Die Core Web Vitals hängen jedoch auch von Frontend, Assets, Rendering und Drittanbieter-Skripten ab. Zunächst muss geklärt werden, welche Schicht tatsächlich begrenzt.
VLCT
Nur wenn ein wesentlicher Teil des Problems im Frontend liegt. Hyvä behebt weder eine langsame Datenbank noch Probleme mit OpenSearch, Integrationen oder Indexierung.
VLCT
Nicht immer. Leistungsfähigere Infrastruktur kann helfen, wenn die vorhandenen Ressourcen begrenzen, behebt aber keinen ineffizienten Code oder ein ungeeignetes Datenmodell. Zunächst prüfen wir, wo Ressourcen tatsächlich verloren gehen.
VLCT
Der Umfang der Dokumentation hängt vom Projekt ab. Wir messen, um Entscheidungen zu treffen und Änderungen zu verifizieren. Nicht jede Messung muss ein separates formales Ergebnisdokument werden.
VLCT
Für das beseitigte Problem kann sie dauerhaft sein, doch die Plattform verändert sich weiter. Neue Module, Integrationen und Daten kommen hinzu. Bei größeren Systemen sollte die Performance deshalb auch im Rahmen der laufenden Wartung überwacht werden.