Inhaltsverzeichnis
Die Performance eines Online-Shops hat den größten Einfluss auf die Zufriedenheit der Besucher und wirkt sich damit direkt auf den Umsatz aus. Dabei liegen durchschnittlich etwa 80 bis 90% der Optimierungspotentiale im Bereich der Frontend-Performance.
Erwartungshaltung und Nutzungsverhalten
Nach aktuellen Untersuchungen erwartet ein potentieller Kunde eine durchschnittliche Ladezeit von etwa 1 bis 1,5 Sekunden beim Stöbern im gesamten Shop. Die Messlatte liegt hoch, wenn man bedenkt, dass aufwendige CMS-Seiten viele Bilder enthalten, eine Kategorie meist schon 24 Produkte pro Seite lädt und spätestens auf einer Detailseite alle verfügbaren Bilder eines Produkts dargestellt werden.
Hinzu kommt, dass sich das Nutzungsverhalten immer weiter von der Bedienung eines klassischen Navigationsmenüs entfernt und stärker auf die Verwendung von Filtern oder eine intelligente Suche setzt.
Es werden mehr und mehr dynamische Inhalte (an-)gefordert, wodurch die Systemlast in den Bereichen PHP und Datenbank steigt.
Produktiver Online-Shop ≠ Ideal
Moderne Shop-Systeme berücksichtigen diesen Aspekt natürlich, speichern einzelne Elemente oder ganze Seiten in einem lokalen Cache und beantworten wiederkehrende Anfragen von dort. So werden Ladezeiten von deutlich unter einer Sekunde erzielt - unter Idealbedingungen!
Bei einem über Jahre gewachsenen produktiven Online-Shop haben sich diese Bedingungen jedoch meist durch die Verwendung unterschiedlicher Module und Plugins, weitaus mehr Artikeldaten, ein unzureichendes Asset-Management (Bilder, CSS, Javascript) und die Integration verschiedener Tracking-Pixel stark verändert.
Und dann sind da auch noch die realen Besucher, die potentiellen Kunden ...
Schlechte Performance dynamischer Inhalte
Was ist mit den Seiten, welche sich über geänderte Sortierung, Paginierung oder die Verwendung der vielen Filtermöglichkeiten ergeben? Sofern diese Objekte nicht über den Cache beantwortet werden können, zeigt sich hier die eigentliche Performance des Online-Shops.
Sind alle Hausaufgaben der Performance-Optimierung aus den Bereichen PHP- und MySQL-Tuning, Optimierung von Bildern und anderen Assets oder Umstellung des Session-Management gemacht, benötigen dynamische Inhalte weiterhin vergleichsweise viele Systemressourcen z.B. beim Suchen und Sortieren relevanter Datensätze.
Die tatsächliche Frontend-Performance ist meist nicht zufriedenstellend!
Alternative Varnish Caching
Zweifelsohne lassen sich z.B. durch den Einsatz von Varnish Caching enorme Verbesserungen der Antwort- (TTFB) und Ladezeiten erzielen, doch ist die Einrichtung eines solchen Setup deutlich komplexer und dauert aufgrund der individuellen Anforderungen eines gewachsenen Online-Shops oft mehrere Wochen oder gar Monate.
Jede Änderung am Shop-System (Core Upgrade, neues Plugin, neues Template) kann gravierende Auswirkungen auf das Caching und somit auf die Funktion des gesamten Shops haben, sodass hier u.U. stets nachgearbeitet werden muss.
Zu guter Letzt gilt auch hier, dass ein Varnish Caching seine Pluspunkte nur dann voll ausspielen kann, wenn die Objekte über den Cache ausgeliefert werden können. Nach einer Änderung wird also stets ein Cleanup (mit anschließendem Warmup) erforderlich.
Die Performance ergibt sich auch beim Varnish Caching direkt aus der Caching Quote - dynamische Inhalte wie z.B. individuelle Produktsortierung je Besucher sind schwer umzusetzen und zeigen die reale Performance.
Ursache und Wirkung
Der Online-Shop als komplexes Gesamtkunstwerk
In der Realität besteht ein Online-Shop aus einer Vielzahl unterschiedlicher Software Komponenten und kann daher als hoch komplexes Gesamtkunstwerk betrachtet werden.
Alleine die Aktualisierung einer einzelnen Komponente kann u.U. das gesamte System oder eine entscheidende Funktion lahmlegen. Gleiches gilt für die potentielle Auswirkung auf den Bereich der Frontend-Performance!
Der Kampf um die Systemressourcen
Im Produktivbetrieb konkurrieren stets verschiedene Prozesse um die selben Systemressourcen. So steigt die Last z.B. durch das nächtliche Backup der MySQL-Datenbank, durch die vielen Cronjobs zur Artikelpflege oder den Produktexport.
Jeder Prozess versucht in der Regel seine Arbeit so schnell wie möglich zu erledigen und nutzt die verfügbaren Systemressourcen daher maximal.
Ein Cronjob etwa benötigt neben der eigentlichen Rechenleistung (CPU) einen Teil des Arbeitsspeichers (RAM) und zieht meist automatisch einen höheren Bedarf über die Datenbank (CPU, RAM, DiskIO) nach sich.
es kommt noch schlimmer ...
Die Warenwirtschaft steuert die API-Schnittstelle des Online-Shops direkt an und übermittelt im großen Stil geänderte Artikeldaten (Preis, Verfügbarkeit). Der Webserver muss die Anfragen entgegennehmen und einen PHP Prozess für die Verarbeitung bestimmen. Jeweils wird die gesamte Applikation gebootet, eine Verbindung zur Datenbank hergestellt und die SQL-Abfragen abgesetzt.
Eventuell erfolgt nach der Aktualisierung eines einzelnen Artikels sogar die Invalidierung der zugehörigen Cache Objekte, sodass der nächste Seitenaufruf zunächst wieder die tatsächliche Performance des gesamten Setups (jetzt unter Last) widerspiegelt...
Fazit
Im Kosmos eines produktiven Online-Shops gibt es vielfältige Ursachen mit unterschiedlicher Zusammensetzung, die alle einen negativen Einfluss auf die Frontend-Performance des Shops haben.
Unangenehmer Weise zeigen sich diese Effekte meist nur sporadisch und sind daher oft schwer im Detail zu analysieren. Häufig ist der Effekt bereits wieder vorüber, bis jemand sich die Sache wirklich anschauen kann. Analysiert man den Shop dann auf einem isolierten Testsystem, lässt sich die Situation häufig nicht reproduzieren, da die beschriebenen Wechselwirkungen und auch die realen Besucherzahlen fehlen.
Kann man daran wirklich nichts ändern?
Nein! Im Produktivbetrieb können wir nicht auf das nächtliche Backup oder die Ausführung der Cronjobs verzichten! Die API-Schnittstelle wollen wir auch nicht abschalten, weil es teuer genug war, die Warenwirtschaft daran anzubinden! Den Datenfeed können wir wohl auch nicht nur einmal im Monat ausspielen und zu guter Letzt können wir auch unsere Besucher nicht aussperren, oder!?
Doch!
Wir brauchen eine Möglichkeit, das herkömmliche Setup zu verlassen. Wir müssen schlichtweg Systemressourcen schonen, um die Performance zu steigern! Wir müssen es schaffen, weniger CPU, RAM und DiskIO zu verbrauchen! Wir dürfen nur noch gezielt die Daten laden und ausspielen, die gerade vom Benutzer angefragt werden!
Aktuelle Shopsysteme bieten hier (zumindest in der Enterprise Version) den Export von MySQL nach Elasticsearch an. Bingo!
Dies kann in der Tat eine starke Entlastung der MySQL-Datenbank und damit eine Steigerung der Performance bedeuten, doch (spätestens) jetzt stellt sich die Frage, mit welchem Anteil der Shop seine Informationen tatsächlich aus Elasticsearch bezieht und welcher Bedarf an Ressourcen durch die Applikation selbst verbleibt.
- können alle Daten einer Kategorieseite vollständig aus Elasticsearch geladen werden?
- können alle Produktdetails vollständig aus Elasticsearch geladen werden?
- wird die Katalogsuche vollständig über Elasticsearch bedient?
- können wir die MySQL-Datenbank jetzt abschalten?
So einfach geht es dann leider nicht, da ein typisches Shopsystem in der Regel als PHP-/MySQL-Applikation entwickelt wurde (und wird) und auch sämtliche Erweiterungen auf diesem Konzept aufsetzen. Was uns fehlt, ist ein leichtfüßiges PHP Frontend, welches für das Zusammenspiel mit Elasticsearch optimiert ist!
A New hubble Shop Frontend is born
Basierend auf dem Laravel PHP Framework haben wir eine schlanke Applikation entwickelt, die ihre Daten ausschließlich über Elasticsearch bezieht.
Der Ansatz erfüllt damit direkt alle Anforderungen an die zuvor genannte Frontend-Performance und legt zugleich den Grundstein für weiterführende Optimierungen:
-
Performance
-- geringe Anforderungen an Systemressourcen (Hosting, Kosten)
-- optimale Antwort- und Ladezeiten auch unter Hochlast (Benchmark, Campaign)
-- einfachste Skalierbarkeit von Applikation und Elasticsearch -
Search
-- intelligente Suche
-- optimale Suchergebnisse mit Kontext -
Personalization
-- individuelle Inhalte aus Basis von Real User Monitoring - Time To Market & Developer Experience
-- Frontend Developer vs. Shop Spezialist
-- schnelle Umsetzung Frontend Development
-- moderne Tools und Toolchain
Der ganzheitliche Ansatz stellt die Zufriedenheit des potentiellen Kunden in den Fokus und verfolgt damit das Ziel, Ihren Online-Shop in allen Bereichen besser zu machen und damit letztlich mehr Umsatz zu generieren.
— Philipp Herz
