Archiv der Kategorie: User-Engagement

Autoskaleriung: Performancetests noch nötig?

Vor ein paar Tagen saß ich in einem Meeting, in dem es um Monitoring von Web-Anwendungen ging. Dabei ging es um Ende zu Ende Monitoring, also vom Backend bis zum Frontend. Genauer um das Überwachen auf Server-Ebene, Application-Ebene, Netzwerk-Ebene und Enduser-Ebene, also volle Transparenz von der First zur Last Mile, was nicht nur eine gute Sache, sondern in meinen Augen Pflicht ist. Dabei kamen wir auf das Thema Load Testing zu sprechen, da jemand in die Runde einwarf, ob es noch sinnvoll ist Performance- und Last-Tests durch zuführen, wenn man eine automatisch skalierende Infrastruktur betreibt. D.h. also je mehr Last auf das System kommt, desto mehr Ressourcen automatisch bereit gestellt werden. Mit heutigen Cloud und SaaS Technologien ist das durchaus möglich.

Autoskaleriung: Performancetests noch nötig? weiterlesen

Was ist RUM und warum sollte ich es einsetzen?

RUM steht für Real User Monitoring oder auch Real User Measurement. Beides ist zutreffend, da es sowohl für eine Überwachung in Echtzeit als auch für eine nachgelagerte Analyse oder Reports steht. Gegenwärtig wird RUM in der Regel über ein JavaScript realisiert, welches in die zu messende Webseite/-anwendung integriert wird. Viele Dienstleister bieten mittlerweile auch native Lösungen für mobile Plattformen wie Android, iOS & Windows an. (Mehr Informationen zur Technik in diesem meinem Blogpost: RUM: Technischer Einsatz im Web)

 

RUM wird oft als Teil von Application Performance Monitoring (APM) gesehen, dessen Aufgabe die Überwachung einer Applikation in Hinsicht auf Ladegeschwindigkeit und Verfügbarkeit ist. Im täglichen Gebrauch spricht man bei APM von der Überwachung der eigenen Infrastruktur, also Datenbanken, Application-Server, Web-Server, Caches, Loadbalancer, Firewalls, etc. Beim RUM steht der End-User im Mittelpunkt und nicht die Applikation. So kann es geschehen, dass das APM zwar grünes Licht meldet – also alles läuft intern wie gewünscht, aber der Enduser erfährt trotzdem eine schlechte Performance oder kann die Applikation gar nicht verwenden (d.h. die Verfügbarkeit ist nicht gegeben). Es gibt also eine große Intransparenz zwischen dem Backend und dem Frontend und diese versucht u.a. RUM zu schließen. Eine komplementäre Möglichkeit wäre synthetisches Monitoring.

 

RUM erhebt die Daten direkt beim Enduser (Browser), z.B. durch die Integration eines JavaScript in eine Web-Applikation, welches beim Aufruf ausgeführt wird. Diese Art des Messens stellt Metriken bereit, die uns die direkte Enduser Erfahrung wiedergeben. Zum Beispiel erfährt man die Ladezeit der Seite in dem jeweiligen Enduser Profil. Das Enduser Profil ist dabei von großer Bedeutung, da jeder Enduser die Applikation mit anderen Eigenschaften anspricht. Diese Eigenschaften bestimmen zum großen Teil wie sich die Performance der Applikation für den einzelnen Enduser darstellt. Es gibt eine Vielzahl von Metriken, die in diesem Zusammenhang erhoben werden können. Eine Auswahl:
  • Performance Metriken: DNS Lookup, TCP Connect, SSL Connect, First Byte Time, Load Time
  • Userprofil: Device-Type, Connection-Type, Geolocation, Bandwidth
  • User Engagement: Session Time, Bounce-Rate, Session-Length, Conversion-Rate, Revenue, Orders

 

Vor allem die User-Engagement Metriken sind dabei sehr interessant, da es den direkten Zusammenhang zwischen Performance und Business Metrics darstellt. Es beantwortet also Fragen wie: „Bei welcher Ladezeit habe ich die größte Conversion Rate und/oder wird der größte Umsatz gemacht?“

 

Wichtig bei der Wahl eines RUM Tools ist, dass es die Daten in Echtzeit verfügbar stellt, also dass kein größeres Zeitfenster zwischen den Sammeln der Daten (Data Collection) und dem Visualisieren und Analysieren der Daten entsteht. Die Notwendigkeit lässt sich sehr gut an dem Beispiel einer Email-Kampagne zeigen:
Wird der Newsletter raus gesendet und tausendfach geklickt, kommt kurzfristig sehr hohe Last auf die gesamte Infrastruktur. Kommt es zu einer Überlast, kann sich dies negativ auf die Enduser Performance auswirken, d.h. es kann zu langen Ladezeiten kommen, z.B. der Landingpage. Ist die Toleranz-Grenze der Enduser überschritten, brechen sie die Interaktion ab, z.B. den Kauf eines Sonderangebots aus dem Newsletter. Eventuell macht sich der Enduser Luft direkt beim Anbieter oder sogar über die sozialen Medien und lässt seine Meinung bei Twitter, Facebook und co raus. Zudem kommt, dass die Investition in diese lang geplanten Kampagne stark gefährdet ist und einige zehntausend Euro und mehr in Gefahr sind. Viele Risiken, die man mit RUM besser kontrollieren kann.
Denn mit einem RUM  in Echtzeit kann ich die Enduser Erfahrung überwachen und entsprechende Maßnahmen treffen, wie z.B. eine statische Landingpage ausliefern, überlastete 3rd Party Inhalte abschalten oder die User in einen Waitingroom schicken. Ebenfalls wichtig wird der Echtzeit Aspekt, wenn es zu Zwischenfällen (Incidents) kommt. Über solche Incidents soll so schnell wie möglich informiert werden, um Schaden abzuwenden oder zu begrenzen. Daher müssen Alarme (Alerts) schnell getriggert werden können, am Besten direkte in entsprechende Prozesse und Systeme, wie z.B. BigPanda.

 

Auch in der Nachbetrachtung hat RUM viele Stärken. Durch RUM sammele ich sehr viele Daten über meine Nutzer und kann auf dieser „Big Data“ Menge interessante und wichtige Erkenntnisse gewinnen. Ist man an dem Punkt, an den man weiß, dass man zu langsam für seine Nutzer ist – man hat also den Status Quo erhoben – und möchte die Web-Application optimieren, stellt sich die Frage: Wo fange ich damit an? Die erfassten Business Metriken kann man mit den Performance Metriken korrelieren und bekommt so die Antwort. Ist mir z.B. die Conversion-Rate am Wichtigsten, finde ich heraus, welche Seite oder welche Komponente der Applikation den höchsten Einfluss auf die Conversion-Rate hat. Habe ich diese erkannt, analysiere ich diese Komponente und stelle fest, welches Objekt (oder welche Objekte) den größten Einfluss auf das Laden dieser Komponente hat und – voila – ich habe einen Punkt an dem beginnen kann und sollte.

Zusammenfassung:
RUM stellt den Enduser in den Vordergrund und ist daher sehr mächtig, denn wie der Enduser eine Webapp erfährt, ist das Erfolgskriterium das im Mittelpunkt stehen sollte. Es liefert eine Vielzahl von Informationen, die zum Einen Lücken in der bisherigen Transparenz des Monitorings fehlen. Und zum Anderen viele Informationen für meine Business Entscheidungen liefern können.
Der Einsatz von Agenten, wie z.B. beim synthetischen Monitoring, führt nur zu einer sehr eingeschränkten Datenmenge, auf der sich nur sehr schwer Hypothesen bestätigen lassen – Geschäftsentscheidungen kann man auf dieser Grundlage nicht treffen. Beim RUM sammele ich große Datenmengen, die direkt durch meine Endkunden generiert werden. Auf dieser kann ich Hypothesen bestätigen, z.B. durch statistische und mathematische Werkzeuge und Schlüsse in der eigenen digitalen Strategie ziehen.

WTF ist ein SPOF?

Eine Webseite ist ein wunderbarer Spielplatz für Marketing & Business (und manchmal auch IT), um verschiedene Tools auszuprobieren, die es ermöglichen sollen den (potentiellen) Kunden und sein Verhalten zu verstehen. Von den klassischen Analyse-Tools wie Google Analytics bis hin zu Heatmap Tracking Tools, wie crazyegg, ist die Bandbreite weit gefächert. Letztere zeichnen auf wie es sich mit der Aufmerksamkeit des Users auf einer Seite verhält. Oft wird die einfache Einbindung in die Seite über so genannte Tag Manager ermöglicht, so dass der Aufwand für die IT sehr gering ist. So weit so gut.

Leider kommt es häufig vor, dass sich diese Ressourcen als Single Point of Failure (SPOF) in einer Seite entpuppen. Ein SPOF ist ein Element in einem Konstrukt, dass, wenn es „bricht“, es zu einem Scheitern des gesamten Konstrukt kommt. Im Kontext von Webseiten bedeutet es, dass die Webseite verlangsamt geladen wird. Dieses verlangsamte Laden kann nur ein paar Millisekunden bedeuten, was für den Besucher vielleicht kaum merkbar ist. Es kann aber auch bedeuten, dass die Webseite sehr lange braucht, um komplett geladen zu werden. So lange dass ein Besucher das Laden abbricht und woanders hin surft, da er denkt, dass die Seite nicht mehr reagiert. Im schlimmsten Fall sieht der Nutzer nur ein leeres Browserfenster – auch White Screen of Death (WSoD) genannt.

Dabei ist nicht die Ressource selber das Problem oder die Verwendung eines Tag-Managers. Es kommt darauf an, wie die Ressource in die Seite eingebunden wird. Oft sind solche SPOFs JavaScripte, die das Laden weiterer Elemente blockieren, so lange sie selber nicht komplett geladen, geparst und prozessiert sind. Dies ist übrigens das Standardverhalten von Webbrowsern, wenn ihm nix anderes mitgeteilt wurde. Wird ein Script ganz zu Beginn in einer Seite referenziert (z.B. HEAD), kann es zu einem WSoD kommen.

Dieses Verhalten ist natürlich unschön und mindert das User-Engagement deutlich, da steigender Ladezeit der Besucher der Seite ungeduldiger wird. Daher ist es wichtig SPOFs zu identifizieren und nach Möglichkeit zu entfernen. Insbesondere bei 3rd Party Integrationen fällt das Erkennen manchmal schwer. Zur Analyse eignet sich das Tool SPOF-O-Matic sehr gut, dass als Chrome Erweiterung erhältlich ist. Es wurde von den Betreibern von webpagetest.org entwickelt und enthält eine Möglichkeit ein Video mit dem Worst Case zu generieren – also dann wenn die Ressource nicht geladen werden kann.

Dabei gibt es zwei Kategorien von Ressourcen: Die Einen, die einen wesentlichen Bestandteil der Aufgabe der Seite liefern – visuell oder funktional. Und die, die sekundäre Aufgaben erfüllen, wie Analytic Tools. Bei der ersten Kategorie muss bewertet werden, ob sie wirklich das Risiko eines SPOFs wert ist. So können nachgeladene Schriften (z.B. von Google) ebenfalls blockieren. Natürlich hat eine Schrift keinen funktionalen Wert, aber der visuelle Character der Seite geht ohne diese Schrift eventuell verloren. Die zweite Art sollte ganz klar entschärft und asynchron nachgeladen werden, denn die Enduser Experience steht im Vordergrund. In diesem Zusammenhang sollte man sich die Frage stellen, ob die eingebundene Ressource es überhaupt wert ist, dass sie in der Webseite enthalten ist und Ladezeit kostet.

Ist man zu dem Schluss gekommen, dass man die Ressource benötigt, muss dafür gesorgt werden, dass sie asynchron und nicht blockend geladen wird. Dazu bieten sich die Möglichkeiten DEFER und ASYNC als Attribut von <script> an. Beide verhindern das Blockieren der Weiterverarbeitung der Webseite im Browser. In der Regel ist DEFER die richtige Wahl, da die Ressource dann parallel zum restlichen Inhalt geladen wird, aber erst geparst und prozessiert wird, nach dem das HTML Dokument selbst komplett geladen und geparst ist (DOMContentLoaded). Es gibt nur sehr wenige Situationen in denen ASYNC über DEFER gewählt werden sollte, da bei ASYNC die Ressource zwar auch parallel geladen wird, aber sobald sie vollständig geladen ist, sofort geparst und prozessiert wird. D.h. wenn sie schnell geladen ist, kann sie sich wieder blockierend auswirken. Daher ist eine genaue Kenntnisse der Webseite bzw -applikation von Nöten. Insbesondere bei Applikationen, die sich aus vielen Quellen zusammensetzen. Darüberhinaus gibt es noch weitere Möglichkeiten mit JavaScript Ressourcen asynchron nachzuladen, auf diese gehe ich in einem späteren Blogpost ein. Das Beispiel „Web Font Loader“ sei hier aber erwähnt.

Um es noch einmal zu verdeutlichen: Die in diesem Beispiel angeführten Analytic Tools sind nicht die einzigen Ressourcen, die blockieren können. Sie fallen allerdings häufig auf, da sie vermehrt zum Growth Hacking eingesetzt werden. Social Media Plugins sind ebenfalls ein oft gesehener Kandidat und diese haben meist nichts mit der Aufgabe der Seite zu tun. Aber auch extern geladene Web-Schriften können das Laden blockieren, wie wir gesehen haben.

 

Anmerkung: Den Begriff White Screen of Death (WSoD) verwende ich nicht ganz korrekt, da er eher beschreibt, dass die Anwendung oder das Device überhaupt nicht mehr reagiert. Das ist aber wie beschrieben weder für Browser noch Webseite der Fall. Es kommt nur zu einer Verzögerung. Diese kann allerdings sehr lang sein und ich kenne niemanden, der bereit ist 20 Sekunden und mehr auf eine Antwort zu warten. Und das ist auch gut so.