Die User-Experience (UX) ist ein zentraler Aspekt digitaler Plattformen. Egal, ob online oder in der realen Welt: Erleben die Benutzer die Interaktion mit Produkten oder Dienstleistungen als zufriedenstellend, ist die Wahrscheinlichkeit hoch, dass sie diese erneut nutzen oder weiterempfehlen. Eine wichtige, wenn nicht die entscheidende Rolle für das Nutzererlebnis bei Websites und digitalen Plattformen spielt − neben Aspekten wie Barrierefreiheit, Klarheit und auch Spaß − die Geschwindigkeit (siehe Abb. 1). Lange Reaktionszeiten können dazu führen, dass die Aufmerksamkeit der Benutzer schwindet, und die Anwender schließlich den vorgesehenen Benutzerprozess vorzeitig verlassen.
Abbildung 1: Wichtige Aspekte der User Experience (UX)
Geschwindigkeit und Reaktionszeit haben nicht nur aus Sicht der Endanwender (Besucher, Kunden oder potenzielle Kunden) einen hohen Stellenwert, sondern sind auch unerlässlich dafür, dass unterstützende Bereiche des Backoffice wie Content-Autoren oder Webmaster gut arbeiten können. Verzögerungen des Systems wirken sich nämlich nicht nur auf deren Produktivität aus, sondern können sogar zentrale Geschäftsbereiche in Mitleidenschaft ziehen, etwa, wenn eine neue Marketingkampagne gestartet oder Produktspezifikationen aktualisiert werden sollen – in Fällen also, in denen die termingerechte Veröffentlichung von Inhalten entscheidend ist.
Bei den meisten Projekten wird die Web-Performance entsprechend den technischen Anforderungen definiert. Eine solche Festlegung ist allerdings nicht ganz einfach und muss mit allen Beteiligten gründlich abgesprochen werden.
Ein erster, einfacher Versuch, die Performance einer Website festzulegen, könnte so aussehen:
Die Ladezeit muss bei allen einzelnen Seiten unter 2 Sekunden liegen.
Allerdings ist diese Anforderung bei Weitem nicht optimal. Damit die Definition der Web-Performance als verbindliche technische Anforderung verwendet werden kann, muss sie präziser formuliert werden und die verschiedenen Aspekte berücksichtigen, die sich auf die Performance-Analyse auswirken können:
Aufgrund der vielen verschiedenen Einflussfaktoren ist es sinnvoller, sich klarzumachen, dass die Ladezeiten nun mal stark unterschiedlich verteilt sind, und diese Verteilung bei der Festlegung von Performance-Anforderungen zu berücksichtigen (siehe Abb. 2).
Abbildung 2: Verteilung der Ladezeiten für eine Seite (Quelle: Google)
Entsprechend könnte eine deutlich enger gefasste Definition der Web-Performance folgendermaßen lauten:
„In 95 % der Fälle sollte der Speed Index für eine schnelle 3G-Verbindung (25 Mbps) unter 3 Sekunden liegen. In den übrigen 5 % der Fälle sollte der Speed Index für dieselbe Art von Verbindung unter 6 Sekunden liegen.“
Mit dieser Definition können Performance-Tests deutlich präziser erläutert und unnötige Diskussionen vermieden werden.
In der Abbildung 3 unten dauert es 445 Millisekunden, bis der Nutzer alle Inhalte der Seite sehen und entsprechend beginnen kann, mit den dargestellten Inhalten zu interagieren. Unterdessen werden die übrigen, nicht sichtbaren Elemente der Seite geladen, ohne dass der Nutzer davon beeinträchtigt wird.
Abbildung 3: Verschiedene Phasen des Seitenladeprozesses
Die Gesamtladezeit einer Seite hängt nicht nur davon ab, wie schnell der Seiteninhalt vom Server an den Browser übertragen wird, sondern auch maßgeblich davon, wie effizient der Browser die Inhalte der Seite darstellt.
Wenn es um Web-Performance geht, wird häufig zwischen zwei Bereichen unterschieden: Die Frontend-Performance betrifft alle Aspekte des Seitenladeprozesses, die unmittelbar mit dem Seiten-Rendering im Browser zusammenhängen. Unter die Backend-Performance fallen dagegen die Vorgänge, die von der Server-Infrastruktur ausgeführt werden, um Seiteninhalte zu erstellen.
Bei der Frontend-Performance geht es darum, HTML-, CSS- und JavaScript-Dateien herunterzuladen und diese Ressourcen zu kombinieren, damit die Seite so dargestellt wird, dass der Benutzer darauf zugreifen und mit der Seite interagieren kann.
Heutzutage gibt es eine ganze Reihe von Tools, die Sie bei der Prüfung der Frontend-Performance unterstützen. Diese Tools geben einen umfassenden Einblick in den vom Browser ausgeführten Rendering-Prozess. Ein bekanntes Beispiel sind die Chrome DevTools (siehe Abb. 4). Sie dienen nicht nur der Überprüfung der Seitenstruktur, sondern bieten auch einen Einblick in den Ressourcen-Download über das Netzwerk − einschließlich einer Simulation unterschiedlicher Netzgeschwindigkeiten.
Abbildung 4: Chrome DevTools
Die größten Engstellen, die die Frontend-Performance beeinträchtigen, sind unserer Erfahrung nach folgende Aspekte:
Abbildung 5: Zeiten für Browser-Seitenanfrage/Reaktionszeit
In der Abbildung oben setzt sich die Time-To-First-Byte (TTFB) aus folgenden Bestandteilen zusammen:
Bei der Backend-Performance spielt der Einfluss der Webserver-Performance auf die TTFB des HTML-Hauptdokuments eine besonders wichtige Rolle. Wenn die TTFB sehr groß ist (Google empfiehlt einen Wert unter 200 Millisekunden), müssen gegebenenfalls backend-seitige Verbesserungen vorgenommen werden.
Caching wird oft dafür eingesetzt, eine schlechte Backend-Performance zu verschleiern. Unter bestimmten Umständen mag das funktionieren, dennoch sollte Caching nicht als Universallösung für Performance-Probleme verwendet werden. Es gibt nämlich eine Reihe von Situationen, in denen Caching-Systeme nicht in der Lage sind, Seitenanfragen zu verarbeiten: etwa, wenn die angefragte Seite (noch) nicht in den Cache geladen wurde oder die Anfrage die Bereitstellung von personalisierten Inhalten erfordert (Beispiele: authentifizierte Besucher oder Content-Autoren).
Darum sollte Caching ausschließlich dazu genutzt werden, gut funktionierende Systeme weiter zu verbessern. So kann es etwa sinnvoll sein, zur Bewältigung extremer Traffic-Spitzen einen Reverse-Proxy-Cache wie Varnish zu verwenden. Dadurch wird die Last auf Seiten der Backend-Infrastruktur reduziert.
Um böse Überraschungen in späteren Projektphasen zu vermeiden, sollten vom ersten Schritt der Anwendungserstellung an durchgängig automatisierte Performance-Tests vorgenommen werden.
Bei Maßnahmen zur Performance-Optimierung von bestehenden Anwendungen muss unbedingt jeweils vor und nach Änderungen die Performance überprüft werden, um Fortschritte zu messen.
In jedem Fall muss die Zielsetzung des Performance-Tests präzise festgelegt werden: Was genau soll unter welchen Umständen geprüft werden?
Angenommen, es soll geprüft werden, wie viel Zeit das Backend-System benötigt, um häufig besuchte Seiten eines Web-Auftritts bei einer Last von 500 gleichzeitigen Benutzern zu generieren. Es sollen hier weder der Rendering-Prozess des Browsers noch die Verbindungsgeschwindigkeit oder die Latenz betrachtet werden. Gut geeignet für diesen Lasttest ist etwa das Tool Apache JMeter.
Im konkreten Beispiel werden folgende Schritte durchgeführt:
Die richtige Konfiguration des Lasttest-Tools spielt eine entscheidende Rolle dafür, dass repräsentative Ergebnisse erzielt und die richtigen Schlussfolgerungen gezogen werden können.
Die User-Experience spielt für Unternehmen eine zunehmend zentrale Rolle, um sich von der Konkurrenz abheben und Nutzer bzw. Kunden für sich gewinnen zu können. Damit wird auch die Performance digitaler Plattformen für Websites und Anwendungen immer wichtiger. Um die Performance in verschiedenen Projektphasen überprüfen zu können, müssen eindeutige Anforderungen definiert und automatisierte Lasttests durchgeführt werden.
In diesem Artikel wurden die verschiedenen Faktoren vorgestellt, die sich auf die Performance auswirken. Dabei haben wir zwischen der Frontend- und der Backend-Performance von Websites unterschieden. Die Identifizierung und Behebung von Problemen im Frontend ist meist weniger komplex als im Backend, da die Überprüfung der Backend-Performance Kenntnisse in unterschiedlichen Bereichen erfordert (beispielsweise in Bezug auf das verwendete CMS, die Hardware-Infrastruktur oder den Anwendungs-Stack).