Speedforce – Pt. III: Wasserfall Diagramm

Veröffentlicht von Florian - 19. Oktober 2016

Was bisher geschah: In der letzten Folge haben wir unsere erste Webseite analysiert. Heute stürzen wir uns in die Tiefen des Wasserfall Diagramms... Wasserfälle sind toll. Sie eignen sich zum Wildwasser-Rafting oder als Geheimversteck für verfluchte Inkaschätze. Als malerischen Hintergrund für eine Dschungel-Szene oder zur Analyse von Website Performance.

speedforce_part_III-1

In den Wasserfall…

Das Prinzip ist dabei denkbar einfach: die verwendeten Ressourcen werden chronologisch untereinander angeordnet. Die benötigte Zeit auf einem Zeitstrahl markiert. Dadurch entsteht die Optik eines Wasserfalls. Zur Anschauung ein Beispiel!

Webpagetest

Im Wasserfall werden die Requests chronologisch dargestellt.

In der linken Spalte aufgelistet befinden sich nun alle Dateien – sei es JavaScript, CSS oder Bilder – die die Website zur Darstellung vom Server laden muss. Also jeder einzelne Request. Der farbigen Zeitstrahl stellt in Millisekunden (ms) die benötigte Zeit dar, die für jede Datei aufgewendet wird. Dabei entsprechen die verschiedenen Farben den entsprechenden Status der Datei. Diese werden, ebefalls chronologisch, in einer eigenen Legende angegeben:
Webpagetest

Die Legende gibt eine Übersicht über alle verschiedenen Status

So kann man auf einen Blick bereits ablesen, an welcher Stelle eine Datei besonders lange geladen hat und welcher Status dafür verantworlich ist. Bunte, senkrechte Linien markieren darüber hinaus den Zeitpunkt von bestimmten Ereignissen. Wie z.B. den Punkt, an dem der Browser beginnt, die Website zu rendern oder wenn der Inhalt des DOM geladen wurde. Auch, wann das Dokument komplett fertig ist. 3xx Responses werden zudem gelb, 4xx Responses rot hinterlegt.

Details matter!

Findet man nun eine Datei, die besonders lange lädt – also einen besonders langen, bunten Zeitrahl aufweist – so kann man sich diese Datei mit einem Klick auf selbige im Detail ansehen:

Webpagetest

In der Detailansicht lassen sich genauere Infos über den entsprechenden Request finden

In unserem Beispiel ist dies nun ein JavaScript des Google Tag-Managers. Neben einigen Infos bzgl. dem Host und dessen IP, lässt sich ablesen, zu welchem Zeitpunkt der Request gestellt wurde (Request Start nach 7.036 s). Man erkennt, dass für den DNS Lookup mit 1020 ms am meisten Zeit aufgewendet wird. Die initiale Verbindung benötigt dann noch 948 ms.

Fazit

Das Wasserfall Diagramm hilft uns auf den ersten Blick zu erkennen, wo ein Request hängt und wo eine Datei besonders viel Ladezeit benötigt. Dies sind die Bereiche, die man bei einer Performance Optimierung zuerst angepackten sollte. Vor allem, wenn sich die Ladezeit dieser Requests auf einem konstanten Level befinden. „Zuerst anpacken“ werden wir auch in unserer nächsten Folge: Hier werden wir einen Blick auf erste Quickfixes (Obacht! Buzzword!) werfen. Wo kann also mit wenig Aufwand bereits eine effektive Optimierungen durchgeführt werden. Die perfekte Herangehensweise für faule Webentwickler und solche, die es werden wollen. Also liebe Kinder, schaltet auch das nächste Mal wieder ein, wenn es heißt: Wie verpasse ich meiner Website einen Ferrari-Motor? Die komplette Serie „Speedforce“ aka „Fast & Furious: Web Development“ gibt es übrigens hier!

Das könnte Dich auch interessieren

How to Bachelorarbeit

15.03.2022, der Tag der Anmeldung meiner Bachelorarbeit: Nervenzusammenbruch Numero Uno. Wie zur Hölle soll ich das schaffen? Ich hab doch kein Plan, wie das ...

git in and git more…

Code School hat ein paar interaktive Tutorials zu Git herausgebracht, alle samt kostenlos. Sehr gut um wieder rein zu kommen oder mehr darüber zu lernen: https...

JSON Requests in Python

Mit JSON Requests lässt sich einiges anstellen. Das wahrscheinlich interessanteste, nämlich die Abfrage von Daten und was dabei beachtet werden muss, soll in ...