Performance Optimierung in AEM (Teil 2): Nutzergruppen und Kennzahlen

Private Breitbandverfügbarkeit ab 50 Mbit/s: Urbane Räume bewegen sich mit Hellgrün und Gelb meistens zwischen 75 und 100% - Ländlichere Gegenden sind im Allgemeinen weniger gut angebunden. (Quelle: https://www.bmvi.de/DE/Themen/Digitales/Breitbandausbau/Breitbandatlas-Karte/start.html)

Zu guter Letzt sollte auch noch die sogenannte User Journey beachtet werden. Das übliche Ziel einer Applikation im Bereich Online-Marketing ist die Conversion. Der Weg von Einstieg auf die Seite bis zur Conversion geht selten in ein bis zwei Schritten: Meistens müssen Produkte gewählt, Daten eingegeben, Formulare abgeschickt, oder gar ein Kauf getätigt werden. Wenn wir das Beispiel Onlineshop betrachten: Hier haben wir durch zahlreiche Optimierungsmaßnahmen einen fabelhaft schnellen Einstieg auf die Seite geschaffen, doch hilft uns das nichts, wenn die User beim Aufruf der Produktseiten abspringen, da diese nach 40 Sekunden immer noch nicht das Bild des gewünschten Produktes anzeigt. Zahlreiche Tools erlauben die Erfassung der gesamten User Journey und die Betrachtung dieser im Detail, um derartige Probleme auszuräumen.

Schritt 2: KPIs

Nun, da wir wissen, welche Faktoren wir bei der Betrachtung beachten sollten und jetzt, wo wir mit schneidigen Wörtern wie “Entry Points” und “User Journey” um uns schmeißen können, wäre es doch sehr passend, wenn wir diese Bestandteile unserer Messungen mit Zahlen schmücken könnten, um diese o.g. Faktoren nachhaltig zu verbessern – und Verschlechterungen Messen zu können. Dabei sollen im Folgenden einige Leistungskennzahlen bzw. Key Performance Indicators (KPIs) vorgestellt werden, die sich für die jeweiligen Messungen als nützlich erweisen sollten. Allerdings kann hier nicht jeder KPI diskutiert werden – das würde den Rahmen sprengen und wäre vermutlich schon in wenigen Monaten wieder überholt.

Auf die Plätze...

Wenn wir also unsere User betrachten, die auf die Seite einsteigen, welche Abläufe passieren? Wie können wir diese Abläufe unterteilen? Und welche Teile des Ablaufs haben welche Bedeutung?

Time to first Byte / Time to last Byte

Betrachten wir zunächst einen einfachen Fall: Wir sind Betreiber des Onlineshops amazing, dessen Namen bekannt ist, weshalb dessen Startseite der Haupteinstiegspunkt ist. Betrachten wir also den Ablauf, dass eine Userin die URL “amazing.com” des Shops in die Browserzeile eingibt und bestätigt, um auf die Seite zu gelangen. Ab hier fängt unsere Messung an.

Die Anfrage der Nutzerin läuft über Kabel, Glasfaser, Luft oder Rohrpost vom Rechner der Userin zum Server. Der Server verarbeitet die Anfrage und bereitet sich darauf vor, die Antwort zurückzusenden. Sobald der erste Buchstabe der Antwort zur Nutzerin zurück kommt, haben wir eine erste Messgröße: Die Time to first Byte bzw. Um genauer zu sein, die Time to first Byte of Response. Wohlgemerkt hat der Browser noch gar nicht anfangen können, die Antwort zu verarbeiten. Wir befinden uns noch vor der ersten sichtbaren Änderung. Time to first byte = Zeit, die vergeht zwischen der ersten Anfrage und dem ersten empfangenen Byte.

Unser Shop ist sicher, daher wird als erstes die Anfrage zu “amazing.com” auf “https://amazing.com” weitergeleitet. Zudem ist unser Shop international tätig, daher wird die Nutzerin, die aus Deutschland auf den Shop zugreift, danach auf die deutschsprachige Seite “amazing.de” weiter geleitet. Von “amazing.de” gibt es noch eine Weiterleitung zum Index in deutscher Sprache: “https://amazing.de/de/index.html”. Auch, wenn die Userin davon nichts mitbekommt, außer, dass sich die URL in der Browserzeile mehrfach ändert, haben wir schon mehrere Antworten des Servers erhalten. Nun wird endlich ein HTML-Dokument angefragt. Der Browser erhält nun zum Ersten mal Content, mit dem er etwas anfangen kann. Hier wird es schon wieder etwas kompliziert mit der Nomenklatur. Denn selbstverständlich lohnt es sich sehr, für dieses HTML die Time to first Byte zu messen. Es lohnt also, für die verschiedenen Bestandteile der Anfrage, die gleichen Messwerte anzusetzen. Die Time to first Byte des initialen HTMLs unterteilt die Messung in zwei Teile: auf der einen Seite stehen Backend-Architektur und Infrastruktur und was danach kommt, ist vorwiegend auf die Frontend-Architektur zurück zu führen. Daher wird die Time to first Byte des initialen HTML oftmals auch einfach als Backend Time bezeichnet.

Zudem können wir messen, wann das Herunterladen des HTML-Dokuments abgeschlossen ist: Die Time to last Byte des initialen HTML-Dokuments. Ist das initalie HTML-Dokument heruntergeladen, kann der Browser theoretisch anfangen, das Dokument zu rendern.

Time to First Byte: Zwei Redirects (301 und 302) und ihre Timings, lassen Aussagen über die Infrastruktur zu; Die TTFB und TTLB des HTMLs sind das Resultat dieser Timings und der Größe des HTMLs.

Paint KPIs

Nehmen wir an, unser Shop hat eine ganz besondere Farbe in der CI, sagen wir, ein dunkles Orange, und dieses dunkle Orange ist die Hintegrundfarbe unseres Shops. Diese grundlegende Information ist in den Styles enthalten, die in dem HTML-Dokument hinterlegt sind. Ruft die Nutzerin die Seite auf, wird sich zunächst der Hintegrund der Seite im Browser ändern. Sobald, meist nur für Bruchteile einer Sekunde, sich die ersten Änderungen im Fenster ergeben, hat man die nächste wichtige messbare Größe erreicht: den First Paint. Aus der persönlichen Erfahrung kommt einem dieser Moment vielleicht als erster bekannt vor: Man navigiert auf eine Seite und man bekommt die beruhigende Rückmeldung, dass sich etwas tut. Der First Paint ist als solcher also schon relevant für die User Experience auf unseren Online Shop.

Mit dem Hintergrund alleine, kann die Nutzerin allerdings noch nichts anfangen: Als Nächstes sollten sich beispielsweise die Bedienelemente der Navigation laden. Wird das erste Mal wirklicher Content auf der Seite dargestellt, egal, ob das Eingabefelder, Bilder, oder die Links der Navigation sind, so spricht man vom First Contentful Paint.

Allerdings ist dieser Content oftmals ein Trugschluss. Man kennt es beispielsweise von der Smartphonebenutzung in der U-Bahn oder dem mobilen Netz, mit dem man gerne mal seinen Laptop ans Internet anbindet, wenn man im Zug sitzt: Die Seite baut sich auf, es lässt sich aber noch nichts klicken oder eingeben – unser Shop reagiert noch nicht. Erst, wenn die Userin mit den Elementen interagieren kann, spricht man von der Time to interactive.

In einer Vielzahl von Fällen ist dieser Moment gleichzusetzen mit dem Moment, in dem sich im Viewport, auch genannt “above the fold”, also dem im Browserfenster sichtbaren Content, nichts mehr ändert. Die Zeit, die vergeht, bis sich also in den Initial für die Userin sichtbaren Inhalten nichts mehr ändert, nennt sich Visually Complete.

Response Time

Oftmals werden im Hintergrund allerdings noch weitere Inhalte geladen: Skripte für die weitere Benutzung oder Bilder, die außerhalb des Viewports liegen werden vorgeladen, oder es werden Tracking Skripte ausgeführt, die weitere Skripte herunterladen, für die Nutzerin aber keinen Sichtbaren Effekt haben. Dies äußert sich oftmals durch ein sich noch weiter drehendes “Lade-Symbol” im Browser, obwohl wir schon mit der Seite interagieren. Die Zeit bis diese weiteren Anfrage-Antwort-Zyklen abgeschlossen sind, wird oftmals als Response Time bezeichnet.

Anhand des beschriebenen Ablaufs zeigt sich deutlich, dass einzelne Punkte beim laden und beim Aufbau der Seite sehr gut messbar gemacht werden können. Die Fragen “Ab wann bekommen unsere NutzerInnen etwas zu sehen?”, oder “Ab wann ist die Seite voll funktionsfähig?”, lassen sich damit sehr gut beantworten.

Allerdings eignen sich die oben genannten Messwerte nur bedingt für das Erfassen und Messen einer gesamten “User Journey”. Zu diesem Zwecke hat das Unternehmen Dynatrace den Messwert der User Action Duration ins Leben gerufen. Dieser Messwert nimmt neben der Verbindungs-, Lade- und Renderzeiten auch die Interaktionszeiten auf, und erweitert somit die Aussagekraft von Messungen, die echte Interaktionen mit der Seite abbilden sollen. Weitere Infos zur User Action Duration finden Sie direkt bei Dynatrace.

Speed Index

Als weiteren nennenswerten Messwert lässt sich noch der Speed Index hervorheben, der die oben beschriebenen Timings von Time to first byte über First Paint bis zum Visually Complete in einem Punkte-Score zusammenfasst. Der Speed Index berechnet sich über eine umgekehrte Ableitungsfunktion über den sichtbaren Renderfortschritt der Seite.

Speed Index: Die Blaue Linie Stellt den Render-Fortschritt in Prozent während des Seitenaufbaus dar. Über die Fläche oberhalb des Graphen errechnet sich der Speed Index: Je kleiner die Fläche, desto besser. So können bspw. auch Unterschiede ermittelt werden für Render-Abläufe, die den gleichen First Paint und den gleichen Visually Complete haben.

Weitere KPIs

Das hört sich soweit schon relativ kompliziert und unübersichtlich an – soll aber natürlich nicht alles gewesen sein. Die Messwerte, die erfasst werden, hängen stark vom Zweck unserer Seite ab.

Generiert unser Online-Auftritt im Gegensatz zu einem Onlineshop beispielsweise seinen Umsatz oder einen Teil dessen über Werbung, die auf der Webseite geschaltet wird, so ist es sehr relevant, wann die User das erste Mal eine solche zu sehen bekommen. Hier wäre es dementsprechend Sinnvoll, die Time To First Ad zu messen.

Nehmen wir an, wir wir behandeln ein Unternehmen, dass keine Eigene B2C Vertriebsstruktur hat, aber großes Marketingbudget für Videokampagnen, die der Markenpflege dienen. Und nehmen wir an, die Produktion von Werbevideos ist relevanter Bestandteil der Markenpflege und unsere Webseite dient hauptsächlich dazu, die Werbevideos zu verbreiten. Für diesen Fall kann es sich zum Beispiel auch lohnen, eine Time To Video Playing zu messen.

Wie man an den letzten beiden Beispielen sieht, sind die gemessenen KPIs stark vom Anwendungsfall abhängig. Es gibt KPIs die allgemein gelten, die Messwerte beeinflussen sich, und sie haben verschiedene relevanz in verschiedenen Fällen. Der Zusammenhang dieser KPIs mit den beobachteten Geräten und Geschwindigkeiten erklärt sich hier auch umso mehr – und umso deutlicher wird, dass all diese Fälle einzeln betrachtet und priorisiert werden sollten. Hinzu kommt, dass Performanceprobleme nicht nur beim Laden der Webseite auftreten können, sondern auch bei der Interaktion. Was die Optimierung der Frontend-Performance angeht können nackte Zahlen alleine nicht immer die Lösung bringen: das Wesentliche ist für die Augen sichtbar.

Der nächste Teil der Serie wird sich mit den Tools befassen, mit denen die Performance einer Webseite gemessen werden kann und erste Probleme identifiziert werden können, um die Grundlage zur Diskussion von Lösungsansätzen zu schaffen.

Viele der hier genannten Messwerte und Messtechniken, sowie die Betrachtung der NutzerInnen, sind Bestandteil ausführlicher Diskussion und werden laufend verbessert und nachgeschärft. Über Kommentare mit Verbesserungsvorschlägen, Ergänzungen oder anderem Feedback freuen wir uns sehr!