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

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: