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

Für ein zentrales Management von Skripten

What's new in AEM6.5 Forms

All Blog Entries

Performance Optimierung in AEM (Teil 3): Tools und Tipps zur Erfassung der KPIs

Für ein zentrales Management von Skripten

In Teil 1 der Reihe über Performance Optimierungen in Enterprise Web Projekten, wurden die Ursachen von Performanceproblemen in Enterprise Projekten diskutiert. Dieser Teil soll die Messzahlen (KPIs) behandeln, mit denen die Performance von Webseiten gemessen werden, sowie einige Tools vorstellen, mit denen diese Zahlen erhoben und verfolgt werden können. In den darauf folgenden Teilen, sollen dann konkrete Tools und Maßnahmen vorgestellt werden, wie die Performance einer Webseite gemessen, verbessert und die Fortschritte persistiert werden können.

 

Traue keiner Statistik…

...abgedroschener Spruch. Aber immer wieder gern zitiert, weil er ja doch ausdrückt, dass korrekte Zahlen immer wieder genutzt werden, um inkorrekte Annahmen als offenkundige Tatsachen darzustellen. An Zahlen kann nicht gerüttelt werden und wir brauchen sie, denn: “You can’t manage what you can’t measure”; Doch schon Sherlock Holmes befand “Nichts ist trügerischer, als eine offenkundige Tatsache”...

Damit wir diese offenkundigen Tatsachen also hinterfragen und in all ihrer Tücke verstehen können, lohnt immer ein Blick aufs Detail. Gerade bei einem Querschnittsthema wie Performance, kann mit den richtigen Zahlen für die gleiche Webseite belegt werden, dass “alles OK” ist – oder aber, dass das nächste Infrastruktur- Architektur- oder Schönheitskur-Paket dringend fällig ist, um die drastisch verkorksten Zahlen wieder gerade zu biegen.

Also, wollen wir versuchen zu klären: Worauf sollen wir schauen? Was ist dabei zu beachten? Und mit welchen Tools?

 

Schritt 1: Analyse

Ob man nun die Performance verbessern möchte, weil es "von Außen" problematisiert wurde, oder weil man es "von Innen" einfach nur als nötig und sinnvoll erachtet, spielt eine zweitrangige Rolle. Wichtig ist es, zunächst zu prüfen, welchen Anwendungsfall man vorfindet und verbessern möchte. Kommt das Problem "von Außen", hat man einen kleinen Vorteil: Das Problem kommt aus der realen Welt – nicht aus der Unternehmensblase. Man kann also schon in etwa feststellen, wo der Schuh drückt.

 

Der erste Eindruck...

Hier ist dann auch der späteste Zeitpunkt gekommen, an dem man die Interaktion von NutzerInnen mit der Seite zu Tracken beginnen sollte. Wir müssen – von wichtig nach unwichtig geordnet – heraus finden:

  • Auf welche Seiten steigen unsere User ein?
  • Mit welchen Geräten besuchen die User unsere Seiten?
  • Mit welcher Bandbreite wird unsere Seite besucht?
  • Wie lange halten Sich die User auf welchen Seiten auf?

 

Das wichtigste zuerst: Der Einstieg auf unsere Plattform. Hier entscheidet sich, auf was bei Messung und Optimierung die meiste Kraft verwendet werden soll. Das muss nicht immer die Homepage sein: bewerben wir beispielsweise eines unserer Produkte massiv und haben den Hauptteil der Einstiege über eine Seite die mit einer Werbekampagne verlinkt sind, so sollte der Hauptaugenmerk auch darauf gelegt werden, diese Kampagnenseite zu optimieren und nicht etwa die Homepage. Doch nicht nur das: Ein essentieller Faktor der Performanceoptimierung ist das Caching: Rufen wir die erste Seite auf, haben wir nichts im Cache. Alles, was danach kommt, wird, sofern es schon mal heruntergeladen wurde, aus dem lokalen Speicher bedient und ist somit ungleich schneller. Daher müssen wir hier auch besonders gut darauf aufpassen, welche kritischen Bestandteile der Webseite wir hier schon ausliefern und das diese so gut wie möglich wiederverwendbar sind.

 

Dicht gefolgt wird die Frage nach dem Einstiegspunkt von der Frage nach den Gerätschaften, welche die User benutzen. Betreiben wir ein Online-Dokumente-Portal, so wird unser Traffic vermutlich immer noch hauptsächlich durch Desktop-PCs generiert, während Nachrichtenseiten inzwischen weit mehr als die Hälfte ihres Traffics über mobile Endgeräte generieren (Quellen: t3n, statista). Die Devices, welche die User benutzen, um unseren Content abzurufen, haben massiven Einfluss darauf, welche Faktoren wir bei Messung und Optimierung beachten müssen: Bildschirmgröße und -format, Leistung von CPU und GPU, Browser und so weiter.

 

Auf der Alm, da gibt's koa Netz

In Zusammenhang mit dem Faktor Mobile vs Desktop Devices, steht auch der Faktor der Bandbreite. Dieser Faktor hängt in mehrerer Hinsicht von der Zielgruppe ab. Haben wir beispielsweise zu einem großen Teil junge User, die unseren Content abrufen, wird dies vermutlich meistens auch mit mobilen Endgeräten über mobile Netzwerke getan. 3G und 4G sind dann die Richtwerte, die wir bei der Messung benutzen sollten. Betreiben wir eine Plattform im Bereich B2B, so werden unsere User vermutlich zumeist Desktop-PCs mit 100MBit Breitbandberbindungen benutzen. Doch der Zusammenhang mit den Devices ist nicht der einzige, der auszumachen ist. Tatsächlich sollte auch der regionale Faktor, trotz aller schmerzhafter Klischees, mit einbezogen werden. Betreiben wir eine Regionale News-Seite für Sachsen-Anhalt oder die Oberpfalz, werden wir vermutlich andere Herausforderungen und Prioritäten haben als bei der Bereitstellung einer Webseite eines jungen, urbanen Hauptstadtmagazins oder eines städtischen Energieversorgers. (Quelle: bmvi)

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.

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.

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.

 Paint KPIs: vom First Paint zum Visually Complete kann viel Zeit vergehen. Um die Effekte auf die User Experience zu messen, lohnt ein Blick auf die messbaren Zwischenwerte.

Paint KPIs: vom First Paint zum Visually Complete kann viel Zeit vergehen. Um die Effekte auf die User Experience zu messen, lohnt ein Blick auf die messbaren Zwischenwerte.

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.

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!