Onlineshops – Geschwindigkeit versus Flexibilität.
Ladegeschwindigkeiten und Spitzenlastfähigkeit sind zunehmend wichtige Eigenschaften von Onlineshops. Gründe dafür sind steigende Besucherzahlen, Änderungen am Google Pagerank, nachweislich steigende Abbruchquoten bei längeren Ladezeiten und Lastspitzen z.B. durch Fernsehwerbung.
Need for speed
In den letzten 12 Monaten sind daher viele grosse und mittlere Onlineshops dazu übergegangen, Full-Page-Chaching einzusetzen. Der Erfolg der Bemühungen kann sich sehen lassen. Noch vor einiger Zeit waren Ladezeiten von 3-6 Sekunden für eine Kategorie- oder Artikeldetailseite eines durchschnittlichen Onlineshops normal. Anbieter, die bereits die Ladezeiten ihrer Shops optimiert haben verblüffen hingegen (falls es die eigene Internetanbindung hergibt) mit Ladezeiten von zum Teil unter 1,5 Sekunden – inklusive aller Bilder und Skripte wohlgemerkt. Die HTML Seite alleine ist meist schon nach 100ms ausgeliefert.
Ist nun also alles eitel Sonnenschein?
Nicht ganz. Es gibt im Leben nichts umsonst, wie meine Oma zu sagen pflegte. Die beeindruckende Steigerung der Geschwindigkeit wird mit anderen Einschränkungen erkauft. Stellen wir die Vor- und Nachteile doch einmal kurz gegenüber:
| Shops ohne Full Page Cache | Shops mit Full Page Cache |
|---|---|
| Vorteile | |
| + Dynamische Seitenerstellung ermöglicht jede denkbare Anpassung an Client, Herkunft, Marketing etc.
+ Änderungen an Artikeln, Kategorien und Landingpages sind sofort online |
+ Extrem schnell (für cachebare Seiten)
+ Gesteigerte Skalierbarkeit + weniger Anfälligkeit für Lastspitzen |
| Nachteile | |
| – Langsame Antwortzeiten
– Hohe Systemlast |
– Nur bestimmte Seitentypen sind cachebar
– Die Invalidierung von Seiten kann komplex und fehleranfällig sein – Gecachte Seiten sind nicht mehr personalisierbar – Gecachte Seiten können nicht mehr serverseitig auf Geräteklassen angepasst werden – Gecachte Seiten können nicht mehr serverseitig auf Marketingmassnahmen angepasst werden – Gecachte taugen nicht zu serverseitigen multivariatem Testing – Tools zur Erfolgsmessung von Marketingmassnahmen werden schwieriger |
In der Gegenüberstellung wird deutlich, dass man sich den Geschwindigkeitszuwachs mit einer erheblichen Einschränkung der Flexibilität erkauft. Für einige Anbieter – Je nach Sortiment und Geschäftsmodell mag das unbedeutend sein. Für andere Anbieter ist dies jedoch eine empfindliche Einschränkung. Neue Geschäftsmodelle lassen sich so zudem ebenfalls nicht einführen.
Lösungen für die goldene Mitte
Zur Zeit gibt es nur Shops die entweder in die eine oder in die andere Richtung optimiert sind. Es fehlen jedoch Lösungen für die goldene Mitte: Shops, die flexibel sind und dennoch schnell. Der Bedarf dafür ist vorhanden, wie ich in einigen Gesprächen mit Shopbetreibern in letzter Zeit feststellen durfte. Was kann man nun tun?
Im Prinzip gibt es zwei Möglichkeiten, wie man das Ziel hoher Performance bei gleichzeitiger Flexibilität erreichen kann:
- Herausnahme von Snippets mit variablem Inhalt aus der gecachten Seite
- Ein geschwindigkeitsoptimierter Catalogserver.
Schauen wir uns bei Möglichkeiten etwas genauer an:
1.) Caching und Snippets
Wenn eine Seite nur deshalb nicht gecacht werden kann, weil sie ein oder zwei veränderliche Element enthält, bietet es sich an, diese Elemente als separates Snippet vom Caching auszunehmen. Ein Element, an dem das sehr deutlich wird, ist der Mini-Warenkorb, der heutzutage auf fast jeder Shopseite zu finden ist.
Sobald der Kunde etwas in den Warenkorb gelegt hat, ist dieser Bereich individuell. Somit kann für diesern Kunden quasi keine Seite mehr aus dem Cache bedient werden, obwohl sich der Rest auf den Seiten überhaupt nicht verändert hat.
Daher wird dieser Bereich als Snippet definiert. Das Caching System liefert weiterhin die Seite aus dem Speicher aus, ersetzt jedoch zuvor den Mini-Warenkorb Bereich per Server Side Include durch die individualisierten Code vom Application Server.
Vorteil: Der Anteil der direkt aus dem Cache auslieferbaren Seiten erhöht sich spürbar, Gesamtperformance und Systemlast sinken.
Nachteil: Durch die zusätzlichen Regeln wird das Caching komplizierter und langsamer. Falls mehrere Snippets pro Seite definiert werden, verringert sich die Performance signifikant durch mehrfache Abfrage des Application Servers und den damit verbundenen Overhead.
2.) Optimierter Catalogserver
Um wirkliche Flexibilität zurückzugewinnen, kommt man um einen optimierten Catalogserver nicht herum. Die Geschwindigkeit erreicht er durch konsequentes Weglassen und Datenoptimierung, wie ich bereits im Artikel “Schnell, schneller, noch schneller !!!” schrieb.
Es sollte ein radikal reduziertes, geschwindigkeitsoptimiertes Framework zum Einsatz kommen. Normale Shopframeworks haben durch die maximale Flexibilität zuviel Overhead
Die Datenstrukturen müssen auf minimierte Suchzeiten optimiert werden. Flattables sind hier normalisierten Strukturen vorzuziehen. Hier ist zu prüfen, ob Key-Value Stores, wie z.B. Couchbase signifikante Vorteile gegenüber SQL haben.
Vorteil: Eine immer noch hohe Geschwindigkeit, bei hoher Flexibilität
Nachteil: Langsamer als echte Full Page Caches, eine Anpassung von Code und Daten an das Produkte und Geschäftsmodell ist nötig, die Einbindung des eigentlichen Shopsystems als Transaktionsserver bietet einige Hürden.
Der Blick in die nahe Zukunft
Beide Wege zur Performancesteigerung haben ihr für und wieder. Je nach Angebot und Geschäftsmodell kann der eine oder der andere Weg sinnvoller sein.
Beide Wege sind nicht ohne Stolpersteine und mit den gegenwärtigen Shopsystemen nicht out-of-the-box realisierbar. Der zunehmende Druck in der Branche zu performanten und dennoch flexiblen Lösungen wird jedoch dazu führen, dass die Herausforderungen angegangen werden. Daher erwarte ich in der nächsten Zeit verstärkte Bemühungen auf beiden Wegen.