Für Performance Optimierung in B2B eCommerce Projekten gilt: Schnell genug gibt’s eigentlich nie, aber zu langsam schon eher. Da Performance immer eine subjektive Bewertung ist, empfehlen wir Performance mit messbaren Kennzahlen zu versehen, die jederzeit eine Prüfung ermöglichen, um festzustellen, wie weit das Projekt ggf. vom Ziel entfernt ist.
Da eine Performance Optimierung nach der Fertigstellung schnell sehr aufwendig werden, bzw. die grundsätzliche Vorgehensweise im Projekt infrage gestellt werden muss, empfehlen wir Performance von Anfang an in den Projektfokus zu nehmen. Erst fertigmachen und dann optimieren ist beim Thema Performance nicht zu empfehlen.
Aber Performance ist nicht nur durch die e-Commerce Lösung sicherzustellen, sondern auch Drittsysteme, die es zu integrieren gilt, die Serverinfrastruktur und die Anbindung an das Internet sind ebenfalls von erheblicher Bedeutung für die Gesamtperformance eines Systems. Und genau diese gilt es immer im Blick zu haben. Eine Performance Optimierung einer eCommerce Lösung, die auf einer unzureichenden Hardware betrieben wird, führt letztlich auch zu einer mangelhaften Performance des Gesamtsystems.
Doch wie kann man eine gute Gesamtperformance in einem B2B e-Commerce Projekt sicherstellen? Zunächst muss das Thema Performance vollständig für alle an der Lösung beteiligten Komponenten und Systeme beantwortet werden.
Im Folgenden stellen wir vor, wie wir in typischen Projektsituationen vorgehen und wie wir in einigen Bereichen das Thema Performance Optimierung beantworten.
1. Performance Optimierung – Hosting und Server-Sizing
Beim Hosting geht es nicht nur darum, eine Serverhardware mit Strom und Internet zu versorgen und mit einem Betriebssystem auszustatten. Für eine performante Konfiguration ist Erfahrung mit den Applikationen unabdingbar und auch für das Hardwaresizing ist Erfahrung wesentlich.
Wir empfehlen deshalb immer das Hosting von Partnern durchführen zu lassen, die Ahnung von der Applikation haben bzw. das Projekt begleiten und z.B. Vorschläge zur Optimierung machen.
Um das Massengeschäft im Hosting sollte aber bei B2B eCommerce Projekten eine großer Bogen gemacht werden. Die hier angebotenen Lösungen sind i.d.R. billig und nicht günstig. Darüber hinaus steht man im Problemfall meist alleine da.
Unit M arbeitet deshalb mit einigen Hostern, die sich auf eCommerce spezialisiert haben, intensiv zusammen und empfiehlt gerne geeignete Hostingpartner für Ihre B2B eCommerce Lösungen.
2. Performance Optimierung – Integration von Drittsystemen optimieren
2.1 Dateibasierte Schnittstellen
Bei der Integration von Drittsystemen ist entscheidend, ob diese „Live“ angebunden werden müssen, oder regelmäßig zyklische Datenexporte in die B2B e-Commerce Lösung integriert werden sollen.
Bei Daten, die dateibasiert zu verarbeiten sind, ist eine Abschätzung, basierend auf Erfahrung im Umgang mit den Datenmengen und der Datenkomplexität, die einzige Antwort. Da die zu importierenden Dateien häufig bereits zu Projektstart zur Verfügung stehen, können in solchen Fällen, spätestens bei der Schnittstellenumsetzung, bereits die Performance Optimierungs-Notwendigkeiten erkannt werden.
Je mehr Daten in kürzerer Zeit verarbeitet werden müssen, führt i.d.R. mit ziemlicher Sicherheit zu viel höheren Umsetzungsaufwänden. Bei unseren Projekten kann schon mal die Laufzeit für einen kompletten Stammdatenimport über alle Sprachen mehrere Tage laufen. Somit lohnt es sich Delta-Updates zur Verfügung zu stellen, die nur die zum letzten Import geänderten Daten enthalten.
Sofern Kunden aber ein internationales Geschäft betreiben und somit die Nacht nicht für massendatenbasierte Verarbeitungsprozesse zur Verfügung steht, müssen Importe auf Importsysteme ausgelagert und, nach erfolgreichem Import, die Daten in die Livesysteme übertragen werden, sodass die Livesysteme nicht durch die Importvorgänge Performanceeinschränkungen erfahren.
2.2 Prozessorientierte „Live“-Abfragen
Bei der „Live“-Integration werden Systeme häufig durch z.B. Webservice- oder REST-API Kommunikation miteinander verbunden. Diese Form der Integration empfiehlt sich, wenn sich Daten sehr schnell ändern, wie z.B. Bestände, oder wenn die vollständige Ermittlung aller Datenkombinationen zu aufwendig ist, wie dies z.B. häufig bei kundenindividuellen Preisen der Fall ist.
Da hier häufig ERP Systeme eine Datenquelle für die B2B eCommerce Lösung sind, gilt es insbesondere die Performance dieser Systeme zu prüfen. Wird z.B. über das ERP System auch die Produktion gesteuert, würde eine Überlastung des ERP Systems durch Anfragen aus dem eCommerce System möglicherweise erheblichen wirtschaftlichen Schaden erzeugen.
Aus diesen Grund empfehlen wir die Leistungsfähigkeit durch Lasttests zu prüfen. Mit Lasttests können einzelne Vorgänge, wie z.B. Preis- oder Bestandsabfragen, simuliert werden und die benötigte Laufzeit wird ermittelt. Da sich die Anzahl der Anfragen beliebig variieren lässt, lassen sich damit die Auswirkungen von verschiedenen Annahmen hervorragend testen.
Der folgende Screenshot zeigt das Ergebnis eines Lasttestes aus einem unserer Projekte:
Lasttest Analyse
Hier sind 4 Integrationsprozesse mit jeweils ca. 1500 Aufrufen getestet worden. Die Lasttestergebnisse zeigen z.B. die minimale, die durchschnittliche und die maximale Laufzeit pro Integrationsprozesse über alle Testläufe. Der Test „Liefersperre“ hat z.B. eine durchschnittliche Laufzeit von 381 Millisekunden und eine mittlere Laufzeit von 331 Millisekunden ergeben.
Die Bewertung, ob diese Laufzeit in Ordnung ist oder nicht, leisten Lasttests aber leider nicht. Hier ist i.d.R. immer noch der Kunde gefordert.
3. Performance Optimierung – Ladezeiten verbessern
3.1 Ladezeiten optimieren
Bei der Verbesserung der Ladezeiten geht es darum die Zeit zu verbessern, die notwendig ist, bis eine Seite der B2B eCommerce Lösungen beim Kunden so weit geladen ist, dass sie im Browser angezeigt werden kann. Hierbei ist die Ladezeit jedes einzelnen Elementes einer Webseite zu messen, um z.B. auch unzureichend optimierte Grafikdateien schnell zu identifizieren.
Als schnellen Einstieg empfehlen wir z.B. das Tool Google PageSpeed Insights einzusetzen. Dieses Tool ermöglicht eine schnelle und einfache Bewertung der eigenen Webseitenperformance.
Der folgende Screen zeigt das Ergebnis einer ersten Ladezeitanalyse aus einem unserer Projekte:
Man kann schnell erkennen, dass hier noch zum Zeitpunkt des Tests erhebliche Optimierungspotentiale bestanden.
Die B2B eCommerce Lösung hat insgesamt mehr als 6 Sekunden benötigt, bis sie vollständig angezeigt ist. Hier fällt die „Time to first byte“ ins Auge. Dies ist die Zeit, die es benötigte, bis die erste Information beim Browser angekommen ist. Diese ist mit fast 2,6 Sekunden sehr lang. Dies weist häufig auf eine schlechte Anbindung des Providers, oder auf einen unzureichend konfigurierten Webserver oder Datenbankserver hin.
Ansonsten fällt auf, dass im obigen Beispiel sehr viele Dateien zu übertragen sind. Auch hier ist es sinnvoll die Grafiken auf Komprimierungspotentiale zu untersuchen bzw. mehrere Grafikdateien zu einer Datei zusammenzufassen, um so den Kommunikationsoverhead zu reduzieren.
Die Testergebnisse solcher Tests hängen aber immer sehr stark vom eigenen Standort und der eigenen Anbindung bzw. der Auslastung der eigenen Anbindung an das Internet ab. Wir empfehlen deshalb Standardsysteme einzusetzen, die es erlauben weltweit verteilte Standorte zu simulieren und so unabhängigere Testergebnisse zu erzeugen.
3.2 Ladezeiten vermeiden
Die Vermeidung von Ladezeiten ist ebenfalls eine gute Strategie, um Bestandskunden gute Ladezeiten zu ermöglichen. Am einfachsten geht dies, in dem man auf den Browsercache der Kunden einwirkt. Es folgen einige Tipps wie man beim Apache Webserver gezielt den Browsercache beeinflussen kann.
3.2.1 ExpiresByType Einstellungen
Beim Apache Webserver lassen sich über .htaccess Dateien Einstellungen an den Browser übergeben, die dem Browser mitteilen, wie häufig eine Datei voraussichtlich verändert wird.
Eine mögliche Konfiguration könnte z.B. so aussehen:
Der Browser wird bei diesen Einstellungen z.B. JPEG Grafikdateien erst wieder nach einem Jahr neu Anfragen und bis dahin seinen Cache verwenden.
3.2.2 Cache-Control
Etwas effizientere Kontrolle über die Cacheeinstellungen bietet die Cache-Control, die beim Apache Webserver ebenfalls in .htaccess Dateien hinterlegt werden kann. Im Folgenden eine mögliche Konfiguration:
# 1 Month for most static assets <filesMatch ".(css|jpg|jpeg|png|gif|js|ico)$"> Header set Cache-Control "max-age=2592000, public" </filesMatch>
Es fällt direkt auf, das, im Vergleich zu ExpiresByType die Cacheregeln viel effizienter und damit auch übersichtlicher und wartbarer hinterlegt werden können.
Max-age wurde übrigens in Sekunden hinterlegt werden. Im obigen Beispiel entsprechen 2592000 Sekunden den gewünschten 30 Tagen.
3.2.3 GZIP Komprimierung nutzen
Durch die GZIP Komprimierung können gezielt einzelne Dateitypen vor der Übertragung komprimiert werden.
Dazu ist beim Webserver Apache die Library mod_deflate erforderlich. Durch die Konfiguration kann man gezielt einstellen, welche Dateitypen komprimiert werden sollen. Hier eine Beispielkonfiguration:
<IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/shtml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript </IfModule>
Achten Sie bitte darauf, dass Bilder und Videos möglichst nicht über den Webserver komprimiert werden sollten, sondern dies i.d.R schon beim Upload auf den Webserver sein sollten. Somit würde eine weitere Komprimierung nur Rechenzeit kosten, aber nichts bringen. Im Folgenden verweisen wir auf einige gute Tools für die Bildkomprimierung.
3.2.4 Hinweise zu häufigen Problemen
Ab und zu ist aber die Aufgabe genau das Gegenteil. Man möchte sicherstellen, dass der Browser eine bestimmte Datei auf jeden Fall neu lädt. Dies ist häufig bei Änderungen in CSS Dateien oder JavaScript Dateien der Fall. Um sicherzugehen, dass ein Browser hier keine alten Dateien aus seinem Cache verwendet, sollten Sie die Dateien einfach umbenennen. So wird aus main.css eben main_1.css und schon ist sichergestellt, dass die letzten Änderungen auf jeden Fall zum Kunden kommen.
3.3 Toolbasierte Bewertung
Wer es bei der Analyse ganz bequem haben will, kann einfach ein Tool nutzen, um die eigene Webseite zu analysieren. Es lohnt sich toolbasierte Performancebewertungen regelmäßig zu wiederholen, auch wenn jedes mal Arbeit dabei herumkommt ;-).
Wir empfehlen die folgenden beiden Tools:
3.3.1 Webpagetest.org
Die Webseite Webpagetest.org bietet ein kostenfreies Tool, bei dem man zu einen den Standort und den Browser für den Performancetest auswählen kann.
Neben einem Wasserfall-Blick auf die Ladezeit, die auch animiert als Video genutzt werden kann, bietet Webpagetest.org eine gute Ausgangsbasis für die eigene Performanceoptimierung.
3.3.2 GTMetrix
Auch die Webseite gtmetrix.com bietet eine kostenfreie Plattform für die Performanceanalyse der eigenen Webseite. Es empfiehlt sich das kostenfreie Konto anzulegen, da man anschließend auf den Ausgangspunkt der Performancebewertung und auf den Browser Einfluss nehmen kann.
3.3.3 GZIP Komprimierung prüfen
Sie möchten mal eben prüfen, ob Ihre Webseite GZIP Komprimierung verwendet? Dann ist das kostenfreie Tool von Vavry gut geeignet.
Sie können nicht nur auf Komprimierung prüfen, sondern Varvy sagt Ihnen auch, wieviel Speicher Sie durch die Komprimierung einsparen konnten.
3.4 Bildkompression
Häufig das Grauen für jede Marketingabteilung, aber zur Optimierung der Ladezeiten ist die Bildkomprimierung unerlässlich. Hier gilt es einen Kompromiss zwischen Bildqualität und Ladezeit zu finden. Im optimalen Fall sollte man die Ladezeit allerdings bereits bei der Bildauswahl berücksichtigen und bei grossflächigen Bildern bereits gut komprimierbare Fotos auswählen.
Für die Komprimierung stehen viele, zum größten Teil kostenlose Tools zur Verfügung. Der Beitrag „9 Free Jpeg Compression Tools With Lossy And Lossless Optimization“ gibt eine gute Übersicht über die verfügbaren Tools.
Wir setzen bei uns gerne ImageOptim ein.
ImageOptim optimiert den Screenshot von sich 😉
Darüber hinaus möchten wir die Liste noch um das Webtool Imagecompressor ergänzen.
Imagecompressor kannten wir bislang auch nicht, wurde uns von Ritta Blens als Feedback auf diesen Artikel empfohlen. Vielen Dank dafür Ritta!
3.5 CSS Sprites
CSS Sprites helfen die Anzahl der Anfragen zu reduzieren. Dadurch sinkt der Zeitbedarf, der durch den „Kommunikation-Overhead“ benötigt wird. Bei einer hohen Anzahl von Dateien ist dies nicht zu unterschätzen.
Wird z.B. ein Share-Button für Facebook, Twitter, Pinterest und Google+ verwendet, sind die 5 Symbole, die zum Laden pro Browsersession 5 Anfragen benötigen. Man kann aber auch alle Button in eine Grafik zusammenfassen und über CSS den anzuzeigenden Bereich steuern. Dadurch kann die Anzahl der Ladevorgänge auf einen reduziert werden.
3.6 Content Delivery Network (CDN)
Wenn sich das eigene Angebot an Kunden weltweit richtet, spielt der Standort des Servers eine enorme Rolle. Sind die Kunden in Australien und der Server in Deutschland, müssen alle Daten einmal um die halbe Welt geschickt werden und dies ist messbar.
Genau für dieses Problem eignen sich CDNs. Diese sorgen dafür, dass man nach wie vor Bilder, JavaScripts, CSS, etc. auf einen Server hochlädt, das CDN verteilt diese Informationen aber weltweit und automatisch und sorgt dafür, dass die weltweit verteilten Inhalte je nach Standort des Besuchers eingebunden werden.
Für alle, die auf der Suche nach einem CDN Anbieter sind, empfehlen wir Cloudflare.
3.7 Lazy Loading
Es ist prinzipiell eine gute Idee Inhalt erst dann laden zu lassen, wenn der Benutzer diese auch tatsächlich sehen will. Diese Technik nennt man Lazy Loading. Allerdings aufgepasst bei den eigenen SEO Anforderungen. Der Googlebot ist ein Besucher, der weder klickt noch scrollt und nur die zu Anfang sichtbaren / lesbaren Inhalte indizieren und bewerten kann.
3.8 Preload
Für das schnelle Anzeigen von Webseiten ist es erforderlich, das der Browser alle für das Rendern der HTML Seite erforderlichen Ressourcen so schnell wie möglich herunterladen kann. Die für das Rendern notwendigen Ressourcen kann man deshalb mit dem Hinweis „preload“ entsprechend kennzeichnen. Der Browser lädt die so gekennzeichneten Inhalte dann direkt herunter, auch wenn er das Parsen der HTML Seite noch gar nicht begonnen hat.
<link rel="preload" href="style.css"> <link rel="preload" href="logo.png">
(Ein Beispiel für den „preload“ Einsatz)
4. Performance Optimierung – Profiling von B2B e-Commerce Lösungen
Ein weiterer Aspekt bei der Optimierung ist die B2B eCommerce Lösung selber genauer zu analysieren. Fragt man die Programmierer warum die Lösung nicht schneller ist, sagen diese immer gerne, dass die Datenbank Schuld ist. Die Administratoren argumentieren übrigens häufig immer genau umgekehrt;-).
Um den Ursachen für Laufzeit und somit letztlich für Performance auf den Grund zu kommen, setzen wir deshalb Profilingtools ein, die es ermöglichen, dass man sich in den Programmablauf einhängt und so die tatsächlichen Funktionsaufrufe in Ihrer Anzahl und ihrem jeweiligen Laufzeitverhalten analysieren kann.
Der folgende Screen zeigt das Ergebnis eines solchen Profilings aus einem unserer Projekte.
Hier kann man z.B. gut erkennen, dass 47,6% und 46,3% der gesamten Laufzeit durch 2 Funktionen verursacht sind. Die jeweilige Funktion ist nun per Drilldown genauer zu analysieren, bis schließlich die Ursache gefunden ist.
Im obigen Screenshot lässt sich z.B. sehr gut erkennen, dass der curlexec Funktionsaufruf für 99,6% der Laufzeit verantwortlich ist. Hinter diesem Funktionsaufruf verbirgt sich z.B. eine Webservicekommunikation mit einem Drittsystem, die für einen erheblichen Laufzeitanteil verantwortlich ist.
Bei der genaueren Analyse ist in diesem Beispiel übrigens herausgekommen, dass nicht der Webservice ein Performanceproblem hatte, sondern das die Authentifizierung beim Webservice falsch eingestellt war, sodass jeder Webserviceaufruf zunächst auf einen internen Fehler auf dem Webserver des Webservice gelaufen ist bevor die eigentliche Authentifizierung erfolgen konnte. Das Protokollieren und Reagieren auf diesen Fehler war letztlich für die Laufzeit verantwortlich. Es lohnt sich also genauer hinzuschauen.
5. Fazit zur Performance Optimierung
Wir hoffen, dass wir einige Möglichkeiten aufzeigen konnten, wie Performance in B2B eCommerce Projekten analysiert und optimiert wird. Performance Optimierung ist allerdings nach unserer Erfahrung nicht pauschal standardisiert zu lösen, sondern die Aufgabe bleibt eine projektindividuell zu lösende Aufgabe. Die Analyse kann allerdings standardisiert über die oben erwähnten Wege erfolgen.
Allerdings möchten wir darauf hinweisen, dass die oben aufgeführten Punkte zur Performance Optimierung natürlich nicht vollständig sein können und auch diesen Anspruch nicht haben. So sind z.B. Server Caching Mechanismen, wie z.B. Varnish, oder Master-Slave Datenbank-Setups noch nicht erwähnt und dargestellt worden. Dies würde aber den Rahmen dieses Beitrags sprengen. Gerne können Sie uns aber jederzeit auf das Thema und generell auf Performance Optimierung ansprechen.
Interessiert an einem kostenlosen Beratungsgespräch?
Dann sprechen Sie uns doch einfach an.
