WEBPERFORMANCE – ZUFRIEDENE KUNDEN STATT SCHNELLE SEITEN

Die Bedeutung von performanten Webapplikationen und Webseiten hat in den letzten Jahren immer mehr zugenommen. Der Spagat zwischen immer komplexeren Webseiten sowie ansteigenden Seitengrößen und der immer größer werdenden Zahl an (mobilen) Endgeräten, die unterschiedliche Ansprüche und Bedürfnisse produzieren, ist eine Herausforderung für jedes Entwicklungsteam. Tools zur Messung, Analyse und Evaluation der Performance von Webapplikationen sollten daher in keinem Entwicklungsprozess fehlen.

Web Performance Monitoring

Zur Messung der Performance einer Webseite werden im Allgemeinen die Ladezeiten als Metrik verwendet. Hier gibt es mehrere Zeitpunkte, die vom Browser ausgelöst und damit gemessen werden können. Eine weit verbreitete Metrik, die bei Messungen der Ladezeiten genutzt wird, ist die sogenannte Document-Complete-Metrik (die Bezeichnung domComplete wird mitunter synonym verwendet). Unter Document Complete versteht man den Zeitpunkt, an dem der Browser die Seite als geladen einordnet. Dies geschieht im Allgemeinen nachdem alle Bilder sowie weitere statische Ressourcen wie Stylesheets und Javascript-Dateien der Seite geladen wurden. Auch in den hier vorgestellten Ladezeiten wurde die Document-Complete-Metrik als Referenz genutzt.

Eine einfache und sehr gute Möglichkeit die Ladezeiten zu messen, bieten die Entwicklertools der verschiedenen Browser (vgl. Abbildung 1). Diese im Browser integrierten Werkzeuge eignen sich hervorragend für die genaue Untersuchung einer Seite und unterstützen den Entwickler bei der Problemlösung. Ein echtes Performance-Monitoring lässt sich über den lokalen Einsatz derartiger Werkzeuge allerdings nicht realisieren. Zum einen lassen sich Veränderungen über die Zeit – wie z. B. sich langsam einschleichende Performance-Probleme – ohne kontinuierliche Messungen nicht nachweisen. Zum anderen sind reproduzierbare Ergebnisse unter immer denselben Bedingungen eine wichtige Anforderung an ein sinnvolles Monitoring. Ad-hoc-Messungen auf lokalen Entwickler-Rechnern können diesen Anforderungen nicht standhalten.

Einen ersten Schritt hin zu einem automatischen Performance-Monitoring von Webseiten bietet die Open-Source-Webapplikation WebPagetest⁽¹⁾. Diese nutzt viele der von den Entwicklertools bereitgestellten Messwerkzeuge. Eine erste einfache Messung wird durch Eingabe der Webadresse sowie der gewünschten Internetanbindung und des Browsers gestartet. Als Ergebnis erhält man eine detaillierte Übersicht des Ladevorgangs der Seite. Um eine kontinuierliche Überwachung der gewünschten Seiten zu realisieren, kann man die Programmierschnittstelle von WebPagetest nutzen. Da es sich auch unter Nutzung dieser Schnittstelle weiterhin um Einzelmessungen handelt, können die Detailansichten wiederum nur zur Problembehandlung verwendet werden. Es fehlt der Überblick über die gesamten Messungen.

Der OpenSpeedMonitor⁽²⁾ schließt genau diese Lücke. Mit dem OpenSpeedMonitor wurde und wird ein Open Source Tool entwickelt, das auf WebPagetest aufbaut. Es ermöglicht auf einfache Art und Weise, Messungen regelmäßig durchzuführen und stellt die Messergebnisse zum Beispiel als Zeitreihen dar. Dadurch sind Auffälligkeiten in den Ladezeiten einfach zu erkennen und durch die Integration von WebPagetest lassen sich diese jederzeit auch sehr detailliert untersuchen.

Wir haben im Januar 2017 mithilfe des OpenSpeedMonitors die Performance von einigen der größten deutschen eCommerce-Seiten gemessen. Anhand der Ergebnisse dieser Messungen soll hier eine beispielhafte Analyse der Wettbewerber erfolgen und so Strategien und Möglichkeiten für eine individuelle Markteinschätzung aufgezeigt werden.

Ladezeiten der Homepage

Will man die Performance einer Webseite messen, stellt sich nicht nur die Frage, wie man diese misst, sondern auch welche Seite hierfür überhaupt als Grundlage dienen soll. Auf eCommerce-Webseiten unterscheidet man beispielsweise Seitentypen wie die Startseite, Produktlistenseiten oder auch Artikeldetailseiten. Oftmals wird die Startseite als Referenz für die Performance einer Webseite herangezogen. Ausgehend von den im Januar 2017 erhobenen Daten zeigt Abbildung 2 die durchschnittlichen Ladezeiten der gemessenen Startseiten.

Die Ergebnisse zeigen ein breites Spektrum zwischen durchschnittlich zwei und zehn Sekunden Ladezeit bis die jeweiligen Startseiten der verglichenen Anbieter geladen waren. Dabei bewegen sich mit Otto, Applestore und Bonprix nur drei Wettbewerber im Bereich von akzeptablen Ladezeiten.

 

Kundenzufriedenheit als Messgröße

Aber was sagen die Ladezeiten nun über die Performance der jeweiligen Homepage aus? Ist der User mit der Ladezeit zufrieden? Denn genau das ist ja das Ziel jeder kundenorientierten Webseite. Aus diesem Grund wurde eine neue Metrik als maßgebendes Performance-Kriterium entwickelt und bei unseren Kunden etabliert: Die Kundenzufriedenheit. Zur Ermittlung dieser Metrik wird die Ladezeit einer Seite auf den prozentualen Anteil der Kunden abgebildet, der mit dieser Ladezeit noch zufrieden wäre. Abbildung 3 zeigt die Standard-Mappings, die im Folgenden benutzt wurden, um die Kundenzufriedenheit für die einzelnen Seiten zu bestimmen.

 

Der Verlauf der Graphen resultiert aus den Erfahrungen, die wir im Rahmen zahlreicher durchgeführter Performance-Untersuchungen gesammelt haben. Zudem flossen die Ergebnisse aus dem Buch High Performance Browser Networking von Ilya Grigorik⁽⁴⁾, die in Tabelle 1 zusammengefasst sind, in die dargestellten Mappings mit ein.

---

Reaktion der Webseite auf User-Interaktion	Wahrnehmung des Anwenders
< 100 ms	Augenblicklich
100 – 300 ms	Wahrnehmbare Verzögerung
300 – 1000 ms	Die Anwendung arbeitet
1000 – 10000 ms	Mentaler Kontext-Wechsel wahrscheinlich
> 10000 ms	Die Anwendung reagiert nicht mehr

Tabelle 1: Wahrnehmung von Ladezeiten für Nutzer (Quelle: High Performance Browser Networking. Ilya Grigorik, 2013).

---

 

Es ist deutlich zu erkennen, dass der Zusammenhang zwischen Ladezeit und Kundenzufriedenheit nicht linear ist. Wie ist die dargestellte Kundenzufriedenheit also zu betrachten? In der ersten Sekunde bleibt diese auf einem hohen Niveau, fällt in den nächsten vier Sekunden jedoch enorm ab. Daraus leiten sich zwei Zeitpunkte ab, die als Referenz eingesetzt werden (so auch in Abbildung 2): die Ziel-Ladezeit sollte bei einer Sekunde liegen um die Kundenzufriedenheit auf über 90% zu halten. Bei einer Ladezeit von ungefähr drei Sekunden haben 50% der Besucher einen mentalen Kontext-Wechsel vollzogen und werden mit hoher Wahrscheinlichkeit die Seite verlassen.

Aufgrund der oben erwähnten verschiedenen Seitentypen einer Anwendung, existieren verschiedene Mappings. So zeigt sich, dass Nutzer geduldiger mit längeren Ladezeiten sind, wenn die geladene Seite Daten zu verarbeiten hat, wie zum Beispiel einen Bestellvorgang. Um dieser Erkenntnis Rechnung zu tragen, können je Seitentyp unterschiedliche Mappings für die Umrechnung genutzt werden (siehe Abbildung 3). Bei Bedarf können speziell auf die zu messende Webapplikation zugeschnittene Mappings ergänzt und genutzt werden.

Betrachtet man nun die auf die Kundenzufriedenheit umgerechneten Ladezeiten, so ergibt sich, wie in Abbildung 4 dargestellt, eine deutlich aussagekräftigere und vergleichbarere Ansicht bezüglich der Performance der Homepages als die vorige Abbildung der reinen Ladezeiten.

Die Customer Journey ist repräsentativer als eine einzelne Seite

Der Besuch eines Users auf einer eCommerce-Webseite endet im Allgemeinen nicht auf der Einstiegsseite. Vielmehr schaut sich ein Kunde z. B. die Produktliste einer bestimmten Kategorie an oder sucht nach einem Artikel und landet im Idealfall zum Schluss im Warenkorb. Entsprechend ergibt es nur bedingt Sinn, die Performance einer gesamten Webseite anhand der Einstiegsseite zu evaluieren.

Deswegen sollten sogenannte Customer Journeys gemessen werden, um die Performance der gesamten Webseite zu beurteilen. Customer Journeys simulieren einen als typisch angesehenen Besuchsverlauf eines Kunden. In Abbildung 6 ist am Beispiel von Zalando eine solche Customer Journey zu sehen. Eine Kundin möchte sich beispielsweise eine Jacke kaufen. Nach dem sie auf der Homepage gelandet ist, klickt sie auf Oberbekleidung und anschließend auf Jacken. Sie schaut sich die Artikel an und sucht dann nach „leichte Sommerjacke“. Ihr gefällt eine Jacke und sie schaut sich die Artikeldetailseite dieser Jacke an, entscheidet sich dafür, diese zu kaufen und geht in den Warenkorb um die Bestellung abzuschließen.

 

Die Artikeldetailseite ist in diesem vereinfachten Szenario die fünfte Seite, die im Laufe der Customer Journey besucht wurde. Der Browser speichert bei jeder der zuvor aufgerufenen Seiten viele Informationen und auch Inhalte in seinem Speicher. Bei den nachfolgenden Seiten müssen diese Informationen dann nicht neu vom Server geladen werden, sondern können direkt aus diesem Zwischenspeicher abgerufen werden und ermöglichen so ein viel schnelleres Laden der Seite. Die Auswirkung dieses Effekts auf die Ladezeit der Seiten ist in Abbildung 6 deutlich zu erkennen.

Zudem sollte bei der Erstellung der Customer Journey berücksichtigt werden, welche Seitentypen der jeweiligen Anwendung vom Kunden als Einstieg aufgerufen werden. Dieser Einstieg in die Applikation erfolgt keinesfalls ausschließlich über die Homepage. So können gerade in eCommerce-Anwendungen nennenswerte Anteile der Kunden von Suchmaschinen-Treffern aus über Produktlisten oder Artikeldetailseiten den Einstieg in die Applikation finden. Warum also die Homepage als einzige Einstiegsseite ansehen und nicht die Artikeldetailseite? Idealerweise stehen Business-Kennzahlen zur Verfügung, aus denen sich das Verhältnis der relevanten Einstiegs-Seitentypen ableiten lässt.

 

Customer Satisfaction Index der Customer Journey

Um eine Vergleichbarkeit der Customer Journeys zwischen den Wettbewerbern zu ermöglichen, müssen die Daten aller Messungen aggregiert werden (unterschiedliche Customer Journeys, Browser, Internet-Anbindungen, Devices). Aus diesem Grund wurde der sogenannte Customer Satisfaction Index (CSI) entwickelt. Der CSI lässt sich im OpenSpeedMonitor auf der Basis der oben beschriebenen Kundenzufriedenheiten ermitteln. Dazu bietet der OpenSpeedMonitor die Möglichkeit, drei Gewichtungen vorzugeben: die Gewichtung verschiedener Seitentypen, die Gewichtung der Internetanbindung bzw. des Endgeräts und die Gewichtung der Tageszeit. Schließlich sind für den Kundenstamm einer Anwendung nicht alle Seitentypen oder Browser gleich wichtig. Damit ist es möglich, die ermittelten Kundenzufriedenheiten aus der Customer Journey mit einer zuvor gewählten Gewichtung zu einem Key Performance Indicator (KPI) zusammenzufassen: dem CSI.

Für die Wettbewerber-Messungen dieser Untersuchung wurde mit einer konstanten DSL 6.000 Internetanbindung im Browser Chrome gemessen. Die Seiten- und Tageszeitengewichtung wurden entsprechend unserer in zahlreichen Performance-Untersuchungen gesammelten Erfahrungen erstellt. So liegt hier der Schwerpunkt bei Seitentypen wie der Homepage und der Kategorienseite. Außerdem sind die Abendstunden für eCommerce-Unternehmen wichtiger als frühe Morgenstunden. Daraus ergeben sich die in Abbildung 7 dargestellten CSI-Werte für die verschiedenen Wettbewerber.

 

Fazit

Verglichen mit den in Abbildung 4 dargestellten Kundenzufriedenheiten der Homepage der Wettbewerber, sind diese näher zusammengerückt. Zudem ist eine Änderung der Rangfolge festzustellen. OTTO landet in der Gesamtübersicht nun vor Bonprix und dem Applestore auf Platz 1, am schlechtesten schneiden Tchibo, Amazon und Zalando ab. Die Verschiebung in der Rangfolge im Vergleich zur Betrachtung der Homepages lässt sich durch die beschriebenen Gewichtungsfaktoren bei der Ermittlung des CSI erklären.

Die aggregierten CSI-Werte geben einen schnellen Überblick über die aktuelle Gesamt-Performance einer Webseite. Mit einem kontinuierlichen Monitoring der CSI-Werte gewinnt man zusätzlich die Sicherheit, Veränderungen in der Performance einfach und schnell zu erkennen. Aufgrund der Vielfalt an Einflussfaktoren ist es jedoch unerlässlich, das CSI-Monitoring mit Detail-Analysen zu begleiten. Der OpenSpeedMonitor bietet die dazu erforderlichen Tools und Lösungen.

Die Ergebnisse der hier präsentierten Messungen sind auf der Demo-Seite (3) des OpenSpeedMonitors einzusehen. Außerdem sind dort weitere detailliertere Informationen zu den einzelnen Messungen zu finden und auch Messungen mit mobilen Geräten sind dort aufgesetzt. Gerade mobile Messungen werden in Zukunft immer wichtiger werden, denn die Anforderung von Kunden, auch unterwegs direkt auf Smartphones und Tablets zu surfen und Bestellungen aufzugeben nimmt stetig zu.

 

Autor:

Johannes Weiß

Email:
Johannes.Weiss@iteratec.de

 

Links

1. https://www.webpagetest.org
2. http://www.openspeedmonitor.org
3. http://demo.openspeedmonitor.org/csiDashboard/showAll?dashboardID=1
4. https://hpbn.co

 

Aufmacherbild/ Quelle / Lizenz
Pixabay / CC0 Creative Commons