Archiv der Kategorie: RUM

RUM: Was soll ich messen?

Wie man in meinem Blogpost RUM: Technischer Einsatz im Web sieht, gibt es beim RUM vielerlei Möglichkeiten Abläufe zu messen. Allein die Möglichkeiten, die die Timing Objekte mit ihren Events bieten, können einem am Anfang erschlagen. Es stellt sich schnell die Frage „Was soll ich messen?“ bzw. welche Metriken sind wichtig? Vorab eine wichtige Info: Es gibt keine allgemeingültige Aussage, da jede Webanwendung individuell ist. Nichtsdestotrotz gibt es ein paar Ansätze, die einem den Weg aufzeigen können.

In der Vergangenheit stand im Kontext von Web Performance oder Web Performance Optimization (WPO) oft die Zeit, die benötigt wird, um den „Download der Webseite“ abzuschließen. Von der technischen Seite hat man dies so definiert bis das loadEvent getriggert wurde. Vor 10 bis 15 Jahren war dies eine eindeutige Metrik, da zu diesem Zeitpunkt wirklich alle Elemente geladen waren. Mittlerweile haben sich die Web-Technologien rasant entwickelt, vor allem durch JavaScript, welches sehr mächtig geworden ist. Vielen Dinge passieren mittlerweile asynchron oder erst nach Interaktion des Nutzers, um ein ansprechendes Erlebnis zu liefern – nicht nur aus Sicht der Performance.

Wie in allen meinen Posts werde ich auch an dieser Stelle nicht müde das Mantra zu wiederholen: Der Endnutzer steht im Mittelpunkt. Um den Endnutzer in den Fokus zu stellen, muss man sich etwas von der rein technischen Sicht entfernen. In diesem Zusammenhang bedeutet dies, weg vom loadEvent hinzu einer Metrik, die wirklich das Erlebnis des Endnutzer widerspiegelt und seine Wartezeit verkürzt.

Die Evolution des Webs bringt es mit sich, dass wir warten bis unserer Ansicht nach die Seite komplett geladen ist. Gelernt haben wir dieses Verhalten durch den Browser, der früher beim loadEvent, uns ein Signal gegeben hat, dass nun nichts weiter passiert, also z.B. die Sanduhr verschwindet. Als Konsequenz daraus fangen wir frühestens an zu interagieren, wenn dieses Signal erscheint oder der sichtbare Teil des Browser sich nicht mehr verändert, also unserer Ansicht nach vollständig ist – ungeduldige und hektische Nutzer mal ausgenommen. 🙂 Dieser sichtbare Teil im Browser heißt „Above the fold“ also „über dem Knick“. Die dazugehörige Metrik heißt entsprechen Above-the-fold-Time (AFT) und lässt sich mit etwas Aufwand erfassen. Allerdings ist AFT auch eine Metrik, die problematisch sein könnte. Je nach Device, Bildschirmauflösung und Fenstergröße gibt es nahezu eine unendliche Anzahl Möglichkeiten wie groß der sichtbare Bereich wirklich ist. Dieser Bereich wird Viewport genannt und ist durch seine Variabilität schwer in Beziehung und Vergleichbarkeit zu setzen. Für mobile Geräte bietet sich dieser Ansatz noch am Ehesten an, da dort der Browser meist im Fullscreen Modus verwendet wird.

Für einen einfacheren und besseren Einstieg schauen wir uns als Beispiel eine typische Nachrichtenseite an – wie etwa spiegel.de. Auf deren Homepage werden viele Nachrichten mit einem Teaser kurz angerissen. Ruft der Besucher die Homepage dieser Nachrichtenseite auf und hat eine interessante Nachricht in der Übersicht gefunden, möchte er schnell den dazugehörigen Artikel lesen und nicht warten bis die Homepage komplett geladen ist. Er will vielmehr direkt zur Nachricht also zum Inhalt gelangen. Daher ist die loadEvent Metrik hier nicht wirklich aussagekräftig. Ebenso versagt AFT, da der Nachricht-Teaser nicht im sichtbaren Bereich sein muss.
Vielmehr ist der Zeitpunkt interessant, zu dem der User auf den Link klicken kann, also wann er mit der Seite interagiert. Dafür bietet sich das domInteractive Event an. Dieses Event wird getriggert, wenn das DOM komplett geladen, geparst und erzeugt ist – auch wenn vielleicht noch Elemente wie Bilder fehlen. In diesem Moment kann der Nutzer auf Links klicken, um so zur nächsten Seite zu navigieren. Eine Stoppuhr, die beim unloadEvent startet und beim domInteractive stoppt, beschreibt also die Zeit bis der Nutzer die Möglichkeit besitzt mit der Seite zu interagieren.
An dieser Stelle muss darauf hingewiesen werden, dass CSS, Fonts und Scripte Einfluss auf das domInteractive Event haben. Es kann sein, dass der User bereits mit der Seite interagieren kann, obwohl ein Script das Event blockiert. Ziel ist es natürlich diese Situation zu verhindern oder eigene Metriken einzusetzen, wie im folgenden Absatz beschrieben. Hierzu passend: SPOFs.

Wichtig zu domInteractive zu erwähnen ist, dass der Besucher die „Möglichkeit“ hat. Das ist nicht gleich zusetzen mit, dass er es auch macht. Zumal ihm nicht zwingend klar sein muss, dass er ab diesem Moment den Link klicken kann. In der Regel gibt es keinen Hinweis vom Browser, dass es so weit ist. Durch sich drehende Sanduhren oder Derivate wird ihm eher das Gegenteil suggeriert. Dem Nutzer wird diese Möglichkeit erst klar, wenn er z.B. mit dem Cursor über einen Link fährt und sich der Mauszeiger dabei ändert.
Um die Zeit zu messen, die der Nutzer wirklich benötigt, um mit der Seite zu interagieren, bedarf es mehr Aufwand. Auch hier gehen wir von einer technischen Standard-Metrik weg und messen wirklich beim Enduser. Und zwar messen wir wann der User klickt, scrollt oder die Maus bewegt. Alle diese unterschiedlichen Aktionen, liefern uns unterschiedliche Informationen darüber, wann der User das Gefühl hat, mit der Seite interagieren zu können.
Leider sind diese Möglichkeiten nicht Build-In in JavaScript oder Bestandteil des Browsers. Daher muss diese Art zu messen per JavaScript Tools oder Frameworks nachgerüstet werden – was natürlich auch wieder einen Einfluss auf die Performance haben kann. Dies kann man aber elegant mit den User Timings umsetzen.

Zusammenfassung
Wie bereits am Anfang beschrieben, gibt es nicht die eine Metrik, die einem jedem Schmerz in Sachen Endnutzer-Performance nimmt. Denn gerade der Endnutzer ist so individuell wie die Anwendung, die er verwendet. Daher Bedarf es auch etwas Forschung und Eigeninititative, welche Messmethode die beste für seinen Zweck ist. Niemals verkehrt ist das loadEvent zu erfassen, da es die bekannteste Metrik und ein gängiger Indikator ist. Ebenso liefert domInteractive einen guten Start, um das Endnutzer Erlebnis zu verstehen. Darauf aufbauend kann man dann das Ganze vertiefen. Wirklich interessant wird es, wenn die Performance Metriken mit dem Business Metriken korreliert werden.

Links:

RUM: Technischer Einsatz im Web

Die JavaScript Umgebung bietet seit ein paar Jahren verschiedene Möglichkeiten um so genannte Timings des Enduser zu erfassen. Timings sind eine Art Stoppuhren, um die Dauer einer bestimmten Aktion oder eines Prozesses zu erfassen. Dabei ist zu aller erst das Navigation Timing zu nennen, welches die Zeiten zwischen verschiedenen Surf/Klick Aktionen (also Navigation) des Enduser misst, z.B. dem Klick auf den Suchen Button (unload / navigationStart Event) bis die komplette Suchergebnisseite geladen ist (load Event). Eine weitere Möglichkeiten ist das Erfassen der Resource Timings, wobei hier Metriken zu den in die Seite integrierten Ressourcen gemessen werden. Unter Ressourcen versteht man Objekte wie Bilder, Skripte, Schriften, CSS, etc. die in die Seite eingebunden sind. Mit den User Timings können dann eigene Stoppuhren in der Webseite gestartet und gestoppt werden, um so z.B. die Laufzeit einer Search-Completion zu messen.

 

Da diese Funktionen noch nicht so allzu lange Teil von JavaScript sind (W3C Recommendation seit Dez. 2012), sind sie in älteren Browsern nicht verfügbar. Einige Hersteller tun sich ebenfalls schwer die Funktionalitäten komplett zu unterstützen, so sind z.B. in allen Apple Browsern die Resource Timings nicht verfügbar. Welche Browser ab welcher Version was unterstützen, kann man sehr gut bei caniuse.com herausfinden.

 

Insbesondere Navigation und Resource Timings bieten mit ihrer Vielzahl an Standardevents viele Möglichkeiten ein Timing zu erfassen. Um genau zu sein, wird hier nicht jedes mal eine eigene Stoppuhr gestartet und gestoppt, sondern wenn ein Event eintritt, wird vom globalen Timer die Zeit genommen und diesem Event zu geordnet. Die Subtraktion zwischen dem gestoppten Zeitpunkt und der Zeit vom Start Event ergibt dann die zeitliche Länge der Aktion.

 

In der Grafik unten erkennt man diese vielen Events des Navigation Timings, die als Standard definiert sind. Die Dauer vom navigationStart bis hin zum loadEventEnd Event entspricht dem Klassiker der Annahme der Ladezeit einer Seite, wie sie allgemein verstanden wird bzw. wurde. Also vom Klick auf einen Link, welches den Start der Navigation zu einer anderen Seiten entspricht, bis hin zum vollständigen Laden aller Objekte dieser neuen Seite. Diese Annahme (Achtung: keine Definition!) stimmt mittlerweile nicht mehr, vieles wird heutzutage asynchron geladen, um die Zeit bis zur Interaktion mit der Seite zu verkürzen. Wie erwähnt ist die Zeit bis zum loadEvent heute nicht mehr das Maß der Dinge, um die Ladezeit einer Webseite zu bestimmt. Viel interessanter ist die Zeit bis der Enduser wirklich mit der Seite interagieren kann, um z.B. etwas in den Warenkorb zu legen. D.h. es ist nicht entscheidend, dass alles geladen ist. Aus technischer Sicht kann der Enduser mit dem Auftretens des domInteractive Events die Seite verwenden, z.B. auf Links klicken. Daher wäre die Zeit von navigationStart bis domInteractive  eine sehr interessante Metrik.

Ein weiteres Beispiel:
Bei vielen Webshops gibt es eine so genannte Browser-Weiche, die erkennt welche Art von Gerät, z.B. Mobile, Tablet, Desktop, die Seite anfragt und eine entsprechende Seite passend für den Screen des Geräts ausliefert. Oft führt diese zu einem oder mehreren Redirects, die alle wertvolle Zeit kosten, während dieser der Enduser keinerlei Aktion sieht, sondern nur warten muss. Bei so einer Architektur kann es sich lohnen das redirectEvent zu erfassen – eventuell auch für einzelne Objekte wie JavaScripts.

 

Zusammenfassung:
Wie man sieht, gibt eine Vielzahl von Möglichkeiten, welche Timings man erfasst. Die Auswahl welche geeignet sind, hängt auch immer davon ab wie die Web-Application verwendet und technisch umgesetzt wird. Es gibt aber ein paar Faustregeln wie das Erfassen von domInteractive, die dabei helfen die Performance und das Verhalten des Endusers besser zu verstehen. Diese Feld bietet viel Raum zu Experimentieren, wie die meisten Bereiche im neuen Medium Web. Der Einsatz und das Verständnis der Faustregeln kann aber schnell zu sehr guten Erfolgen führen, auf die man aufbauen kann.

 

Links:

 

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.