Performance Profiling einer Website auswerten

Wenn neue Features implementiert werden, erhöht sich dadurch oft die Komplexität der Seite oder schlicht die Grösse des angezeigten Inhaltes, was unter Umständen zu einer Verschlechterung der allgemeinen Performance führen kann.

Damit es ob der Zunahme der Ladezeiten nicht eines Tages ein böses Erwachen gibt, stehen eine riesige Menge an unterschiedlichen Tools und Vorgehensweisen zur Verfügung, um eine gute Übersicht über die Performance einer Website zu behalten.

So bietet z.B. das Produkt SENTRY nebst Error-Tracking auch eine sehr übersichtliche Ansicht für aufgezeichnete Requests, welche auf einer Website abgesetzt wurden.

Die richtige Umgebung

Bevor man mit irgendwelchen Tests beginnt, ist es wichtig, sich zuerst einmal darüber Gedanken zu machen, wie und was genau man testen will.

Weiter können wir nicht einfach unsere Test-Tools auf die Live-Applikation unseres Kunden loslassen und somit vielleicht sogar seinen täglichen Betrieb gefährden. Ausserdem wären die Tests nicht repräsentativ, da wir in der Regel nicht wissen, wie viele User sich gerade auf der Website bewegen oder wie viele vorhaben, sich in den nächsten 5 Minuten darauf zu verbinden.

Wir müssen einerseits genau das testen, was vorhanden ist, aber andererseits sicherstellen können, dass wir den Betrieb nicht gefährden. Unsere Auswertungen sollten Aufschluss über die tatsächliche Performance einer Website liefern; es braucht gute und verlässliche Referenzen.

Vor dem Profiling kommt das Profiling

Es ist essenziell zu wissen, womit wir unsere Daten vergleichen. Wenn wir nun z.B. mit dem Performance Profiling von Sentry eine Woche lang Daten sammeln, zeigt uns dies zwar, wie lange jeder einzelne Seitenaufruf gedauert hat und wo sich die Lastspitzen befinden, aber wir haben noch keine Ausgangslage, mit der wir unsere frischen Daten vergleichen könnten.
Also muss das Profiling zuerst einmal eine Weile das tun, was es am besten kann: profilen!

Sobald eine gewisse Menge an Daten vorliegt (diese Menge ist sehr individuell), können diese Daten verwendet werden, um weitere resp. später registrierte Daten damit zu vergleichen.

Deshalb ist es sehr wichtig, immer wieder eine Bestandsaufnahme der Performance einer Web-Applikation zu machen, damit Daten vergleichbar sind.

Daten richtig auswerten

«EIN BILD SAGT MEHR ALS TAUSEND WORTE!»

Dieser Aussage können sicher die meisten zustimmen. Die Faktoren müssen bekannt und Ausschläge erkennbar sein.

Hier ein Beispiel:

Über einen Zeitraum von 1 Stunde wurden auf einer Website 1600 Aufrufe verzeichnet. Die folgenden Daten zeigen aber nicht die Gesamtladedauer, welche der Browser benötigt (mit allen Scripts und Styles), sondern es geht hier um die Auslieferung der Daten an den Client.

Die nächste Abbildung zeigt die durchschnittliche Ladezeit aller dieser Aufrufe:

Eine Ladezeit von unter 2 Sekunden ist gerade noch akzeptabel. (Der wissenschaftliche Artikel zu «Drei Sekunden sind zu lang» zeigt dies sehr gut auf).

Wenn wir anstelle der einen Durchschnittszahl die Statistik der Aufrufe etwas detaillierter anschauen, ergibt sich ein differenzierteres Bild:

Interpretation: 50% der Aufrufe dauern länger als 0.9875 Sekunden (⌀ p50)
25% der Aufrufe dauern länger als 2.51 Sekunden (⌀ p75)
5% der Aufrufe dauern länger als 6.12 Sekunden (⌀ p95)
1% der Aufrufe dauert länger als 8.07 Sekunden (⌀ p99)
Die längste Ladedauer beträgt 31.14 Sekunden (⌀ p100)

Obige Abbildung zeigt ein differenzierteres Bild und ermöglicht uns, einige sehr nützliche Informationen über die Performance dieser Website zu erhalten. Immerhin sind 50% der Aufrufe innerhalb einer Sekunde bedient.

Schauen wir uns die Datenreihe nochmals in einer anderen Form an:

Die vertikale Achse zeigt die Dauer der Aufrufe in Millisekunden (0 - 35000) während auf der horizontalen Achse aufgezeigt wird, wann diese Aufrufe getätigt wurden. Hier werden von den 1600 Aufrufen die 10 längsten aufgeführt.

Genau ein einziger Aufruf beansprucht aussergewöhnlich viel Zeit.

Gerade unterhalb der Spitze (also zum selben Zeitpunkt der 31 Sekunden) befindet sich der zweitlängste Aufruf mit 12 Sekunden Dauer. Da es sich bei diesem Ausreisser um einen Einzelfall handelt, ist dieser zu vernachlässigen (vgl. auch Absatz «Trugbilder»).

Dennoch sind die Ladezeiten generell zu hoch, also müssen für diese Applikation Verbesserungen vorgenommen werden.

Mögliche «Trugbilder»

Normalerweise sitzt der Benutzer mit seinem Computer, Smartphone oder Tablet nicht direkt im Rechnerzentrum, in dem sich der Webserver der Website befindet, auf die er gerade zugreift.

Es ist möglich, dass der Request eines Benutzers über dutzende Zwischenschritte reisen muss, bis er am Zielserver, auf dem die Applikation läuft, angelangt ist. Danach muss die Antwort zum Client zurückgeschickt werden. Hier kann die Ladedauer für den Benutzer durch etliche Faktoren negativ beeinflusst werden: Schlechtes WiFi / Mobiles Netzwerk, Firewall Einstellungen, Proxy, Zugriff über VPN etc.

Sinnvollerweise wird die Dauer vom Eintreffen des Requests des Clients beim Webserver bis die Antwort den Webserver wieder verlässt gemessen und nicht von dem Moment, wenn der Client den Request abschickt bis er ihn wieder erhält. Denn nur so wird die effektive Ladezeit gemessen und allfällige Störfaktoren ausgeschaltet.

Fazit

Beim Auf- und Ausbau einer digitalen Applikation ist auf die Ladezeit = Performance zu achten, um dem Besuchenden ein optimales Nutzererlebnis zu bieten und im SEO Ranking nicht abgestraft zu werden. Mit gängigen Tools kann unter anderem sehr genau eruiert werden, wie sich die Performance einer Lösung entwickelt. Wichtig ist es dabei, Vergleichswerte zu haben und die Datenreihen genauer zu betrachten, um Handlungsbedarf abschätzen zu können.

Verwandte Themen

Weiterführende Projekte und Inhalte zum Thema