Wenn ein Onlineshop nicht die erwartete Servicequalität anbietet, werden sie in Rekordgeschwindigkeit einen alternativen Anbieter ausmachen, um die begehrten Produkte schnellstmöglich zu erhalten.

E-Commerce-Seiten auf Performance zu optimieren, wird durch massiv zunehmende Anteile mobiler Surfer in Zukunft noch bedeutsamer. Zwar hat der mobile Traffic die Zugriffe mittels Desktop-Endgeräte bereits vor über einem Jahr überholt, mobile Konversionsraten liegen jedoch meist auf einem Bruchteil der Zahlen ihrer traditionellen Gegenstücke und die Wartezeit ist auch hier wesentlich. Gemäß Google verlassen 40 Prozent der mobilen Benutzer Shops, wenn eine Seite länger als 4 Sekunden lang lädt. Amazon wiederum hatte bereits 2006 festgestellt, dass nur 100 Millisekunden längere Ladezeiten mit 1 Prozent Umsatzrückgang einhergehen.

Die Gleichung ist also ein No-Brainer: Schnellere E-Commerce-Lösung bedeutet mehr Umsatz. Auf dem Desktop oder mobilen Endgeräten.

Was bedeutet also gute Geschwindigkeit?

Dummerweise gibt es auf diese Frage keine eindeutige Antwort. Es hängt alles vom jeweiligen Kunden, dem aktuellen Nutzungskontext, dem gewünschten Produkt und vielen anderen Parametern ab. Gemäß einer Erhebung von Pingdom  benötigen die Top 50 E-Commerce Webseiten durchschnittlich 2,51 Sekunden zum Laden. Die schnellste Seite lädt dabei in weniger als einer halben Sekunde, während die langsamste länger als acht Sekunden benötigt. Nach meiner eigenen Erfahrungen bewegen sich die meisten Onlineshops in der freien Wildbahn eher im unteren Leistungssektor - da sind auch 10 Sekunden Ladezeit oder mehr nicht ausgeschlossen.

Was kann man nun also tun, um seine Ladezeiten zu verbessern? Dazu muss man zunächst verstehen, wie Seiten im Web funktionieren und wie dadurch Ladezeiten entstehen. 

1. Der Browser fragt zunächst die jeweilige Seite auf dem Server ab. E-Commerce-Seiten bestehen generell nicht aus statischen Dateien, die man bei Bedarf einfach vom Server laden könnte. Viel mehr werden sie durch Programmiersprachen wie PHP zum Abrufzeitpunkt generiert. Der Webserver nutzt PHP dazu, alle interessanten Informationen über Produkte, den Warenkorb, den aktuellen Benutzer usw. zusammenzutragen und ansprechend optisch aufzubereiten. Das beinhaltet oft eine ordentliche Portion Komplexität und verbraucht entsprechend viel Zeit.
   Die meisten aktuellen Shop-Plattformen sind jedoch nicht schnell genug in der Generierung ihrer dynamischen Inhalte. Deshalb wurden in der Vergangenheit allerlei Hausmittelchen eingeführt, welche die Geschwindigkeitsprobleme lindern sollen. Die wichtigste Unterstützung stellen sogenannte Full-Page Caches dar, allen voran Varnish. Dabei wird der Inhalt einmal erstellt - was natürlich noch immer langsam ist - und anschließend im Arbeitsspeicher des Servers zwischengelagert. Das bedeutet, der arme erste Kunde sieht eine langsame Seite, aber alle nachfolgenden Besucher bekommen eine schnelle Seite präsentiert.
   Full-Page Caching bringt jedoch einige Problemstellungen mit, die sich mit modernem E-Commerce unserer Meinung nach nicht mehr vereinbaren lassen.

• Full-Page Caching macht dynamische Inhalte und damit Personalisierung deutlich schwieriger. Klar, es gibt Mechanismen wie Ajax oder ESI, mit denen man dynamische Inhalte in die statisch abgelegten Seiten integrieren, aber das hilft auch nicht, wenn die allgemeine Geschwindigkeit meines Systems im Eimer ist.
• Dazu kommt die zusätzliche Komplexität, die oft in einer Menge Zusatzarbeit und -zeit in der Entwicklung bedeuten. Entwickler müssen nun klarstellen, dass generierte Inhalte mit kontextspezifischen Ausgaben vereinbar sind. Aus meiner Erfahrung kann das mitunter einige Tage Arbeit für eine Funktion bedeuten, deren eigentliche Logik in wenigen Stunden erstellt war.
• Den gesamten Inhalt zwischenzuspeichern und dann vereinheitlicht auszuliefern, hört sich zunächst sehr gut an, erweist sich in der Praxis jedoch oft deutlich weniger effizient als zunächst angenommen. Das liegt an der sehr hohen Menge unterschiedlicher Seiten in einer E-Commerce-Lösung und der Menge an Änderungen der dargestellten Informationen. Die Veränderung von Preisen oder Verfügbarkeiten sorgt eben regelmäßig für veraltete Versionen im Cache.
• Schlussendlich muss man sich außerdem vor Augen halten, dass ein großer Teil von E-Commerce-Funktionalität gar nicht vorgehalten werden kann. Produkte in den Warenkorb zu legen und später einzukaufen, bedarf spezifischer Logik und Berechnung. Ich habe Situationen erleben "dürfen", in denen Varnish erfolgreich für die Darstellung des Katalogs sorgte, das System nachher jedoch nicht den Ansturm auf die Warenkörbe verarbeiten konnte. An der Stelle fehlen einem die Worte. Man hat den Kunden soweit, das ultimative Ziel zu erreichen. Man hat alles richtig gemacht und dann bricht das System wenige Meter vor der Ziellinie zusammen.

Im Grunde ist ein Full-Page Cache das Gegenteil von dem was man will, nämlich einen Shop, bei dem die Inhalte voll und ganz auf den jeweiligen Kunden optimiert sind. Das kann bspw. durch die promoteten Produkte auf der Homepage, individuelle Reihenfolge im Katalog, einstellbare Filter, ggf. kunden-individuelle Preise passieren. Ein hochwertiger Shop ist daher grundsätzlich überhaupt nicht cachebar. Tut man es doch, dann verbaut man sich die Konversionrate-Optimierung für die Zukunft

• Der zweite Teil der Ladezeiten wird häufig vergessen. Nachdem der Browser das generierte HTML bekommt, interpretiert er den Code und lädt alle verlinkten Ressourcen wie Bilder, Skripte oder Style-Definitionen herunter. In 98 Prozent der Fälle schlummern hier sehr große Optimierungspotentiale und Frontend-Code hat sich in den vergangenen Jahren auch fundamental weiterentwickelt. Man kann meist locker 20 Prozent oder mehr der Reaktionszeiten einsparen, indem man besseren Quelltext ausliefert, die verlinkten Ressourcen optimiert oder den Server korrekt einstellt. Jedes Mal, wenn in einem Projekt darüber nachgedacht wird, einen weiteren Dienst per JavaScript einzubinden, sollte darüber nachgedacht werden, ob es diese zusätzliche Verarbeitungszeit wert ist.

Pfeilschnelle E-Commerce Lösungen powered by Spryker

Immer wenn ich mit meinen alten Buddies aus der Magento-Welt erwähne, dass Spryker in der Lage ist, dynamisch generierte Seiten in einem Bruchteil einer Sekunde auszuliefern, bekomme ich die süßen Buchstaben des Unglaubens: "WTF?". Viele können gar nicht glauben, dass eine native PHP-Anwendung überhaupt in der Lage dazu ist. Und ich kann euch versprechen: Es ist möglich! 

Ich habe dann mal Pingdom bemüht und die Zugriffszeiten einiger öffentlicher Seiten unserer Kunden gemessen. Wie sie performt haben? Seht selbst:

×

Zur Erklärung: Ich habe Landing Pages, Kategorieseiten sowie Produktdetailseiten für einen schnellen Test genutzt. Und ja, die Reaktionszeiten werden mit allen herkömmlichen Webseiten verglichen, selbst wenn ein Großteil davon deutlich weniger komplex als E-Commerce-Anwendungen sind!)

Google

Die Zahlen sprechen ja für sich: Spryker erlaubt endlich pfeilschnelle E-Commerce-Anwendungen für die eigenen Kunden anzubieten. Wir erreichen das durch eine moderne Systemarchitektur, die für Flexibilität, Geschwindigkeit und Skalierbarkeit ausgelegt ist. Ohne die Nachteile von Full-Page Caching in Kauf nehmen zu müssen. Profitiere von dieser Geschwindigkeit und biete deine Services den Kunden an, ohne deren Zeit zu verschwenden.

Denn eines ist klar: Zeit ist Geld.

Wie Sie mit Spryker pfeilschnell werden können, klären wir gern in einem persönlichen Gespräch auf der Internet World. Vereinbaren sie jetzt einen Termin mit unseren Experten.