Performance-Boost (4): Ladedauer und -reihenfolge mit Chrome DevTools analysieren

Mit Lighthouse haben wir uns schon eines der DevTools angeschaut. Zur Erinnerung: die DevTools kann man mittels F12 oder Strg + Shift + i öffnen. Bevor wir tiefer in die Tools einsteigen, möchte ich noch auf eine paar allgemeine Einstellungsmöglichkeiten eingehen. Als erstes sei die Positionierung genannt, die ich relativ frei wählen kann. Dafür gehe ich auf das Menü mit den vertikalen drei Punkten oben rechts. Ganz oben kann ich unter "Dock side" einstellen, ob die DevTools als eigenes Fenster oder links/unten/rechts im aktuellen Tab angeordnet werden sollen:  

Ich persönlich arbeite meistens mit der dritten Einstellung, womit die DevTools unten im aktuellen Browsertab angezeigt werden. Falls ich eine Webseite in der Vollansicht anschauen möchte, bietet es sich an, die DevTools über die erste Einstellung ganz vom Browserfenster zu entkoppeln, um beispielsweise auf zwei Monitoren zu arbeiten. Doch Vorsicht: Die entkoppelten DevTools sind immer noch an den Browser-Tab gebunden, aus dem heraus ich sie initial gestartet habe. Die Aufrufe von neuen Browser-Tabs werden nicht verarbeitet.
 

Als nächstes ist es wichtig zu wissen, dass sich die einzelnen Funktionen der DevTools in einer eigenen Tab-Ansicht befinden. Dabei werden standardmäßig nicht alle Funktionen aufgeführt. Du kannst Sie über das Menü mittels More tools hinzufügen. Sie erscheinen dann jeweils als neuer Tab: 

Übrigens: Falls die DevTools bei dir einen weißen Hintergrund haben und du dich fragst, warum in den Screenshots alles so dunkel ausschaut: Ich bin ein großer Fan des Dark-Modes, den ich auch auf meinen Betriebssystemen standardmäßig nutze. Dies wird von Chrome erkannt, kann aber auch individuell aktiviert werden. Öffne das Einstellungsmenü über das Zahnrad (ebenfalls oben rechts) und ändere die Theme-Einstellung, falls dir eine andere Ansicht lieber ist.

Nachdem wir nun schon ein paar grundlegende Einstellungen kennen, ist es Zeit, einen Blick auf das erste Tool zu werden. Bei der Performance-Analyse kommt man in der Regel nicht darum herum, sich die Ressourcen anzuschauen, die in den Aufbau einer Webseite involviert sind. Dabei kann es zum Beispiel sinnvoll sein, sich die Ladedauer und Reihenfolge in Form eines Wasserfall-Diagramms anzeigen zu lassen. Hierbei hilft uns das Network-Tool mit dem sich der Anteil des Netzwerks am Seitenaufrufs protokollieren lässt.
 

Ich empfehle dabei folgendes Vorgehen:
 

1.) Öffne einen Inkognito-Tab (Strg + Shift + N)

2.) Öffne die Entwickler Tools (F12) und gehe auf den Network-Tab

3.) Aktiviere die Schaltflächen Preserve Log und Disable Cache oben links:

Die Preserve Log-Einstellung dient dazu, den Netzwerkverkehr jedes nachfolgenden Aufrufs mitzuschneiden. Das ist sinnvoll, um bspw. Redirects sehen zu können, die beim Aufruf einer Seite zuerst gemacht werden (http → https, non-www zu www etc.). Allerdings sollte man im Hinterkopf behalten, dass man das Log nach einem Seitenaufruf ggf. leeren sollte. Andernfalls wird es schwierig, die einzelnen Aufrufe voneinander zu trennen. Wenn es zu unübersichtlich wird, kann man die Liste auch jederzeit leeren, indem man auf das ( \ )-Symbol drückt.

Mittels Disable Cache sorgen wir zudem dafür, dass der Browsercache nicht genutzt wird - egal, wie oft wir eine Seite aufrufen. Damit simulieren wir den Erstaufruf einer Seite durch einen neuen Seitenbesucher, der noch nie auf meiner Seite war. Navigiere ich mit dieser Einstellung auf einer Seite, werden die Messwerte daher in der Regel schlechter sein, als es bei echten Webseitenbesuchern der Fall ist, da dort der Browsercache aktiv ist. Der erste Aufruf - beispielsweise der Startseite - liefert aber realistischere Werte, als mit aktivem Cache.

Das Network-Modul bietet uns darüber hinaus noch weitere Einstellungsmöglichkeiten, die bei der Untersuchung einer Seite hilfreich sein können. Ich kann zum Beispiel die Netzwerkgeschwindigkeit künstlich beschränken. Dafür aktiviere ich das Throttling: 

Ich kann hier entweder aus den vorgefertigten Presets ein Profil auswählen oder mir selbst über Add eines erstellen. Da die Testseite, die ich im folgenden als Beispiel heranziehen werde, auf meinem Notebook liegt und auch dort von einem Webserver ausgeliefert wird, simuliere ich jetzt einmal über das Throttling näherungsweise eine 50 Mbit DSL-Verbindung. Andernfalls würden die Messwerte sehr realtitätsfern sein, da bei mir alles von lokal geladen wird: 

Solch gedrosselte Einstellungen eignen sich besonders für Tests, bei denen man eine schlechte Internetverbindung simulieren will. Das verwendet Lightouse übrigens auch, wenn man einen Tests mit der Einstellung mobil statt Desktop macht. In dem Fall kommen natürlich bedeutend langsamere Verbindungen zum tragen, die ich über "Fast 3G" und "Slow 3G" in den Einstellungen auswählen könnte.

Achtung:
Die Einstellungen bleiben auch für andere Browser-Tabs des gleichen Modus erhalten! Daher empfiehlt es sich auch hier, immer mit einem Inkognito-Tab zu arbeiten, damit das normale Surfen nicht leidet. Damit man sich nicht allzu lange wundert, wird ein aktives Throttling in den DevTools mit einem gelben Ausrufezeichen im Network-Tab kundgetan.

Nachdem wir nun die wichtigsten Einstellungsmöglichkeiten kennen, können wir die Seite aufrufen, die wir untersuchen möchten. Das Networkmodul zeigt uns anschließend live, wann die einzelnen Ressourcen geladen werden und wie lange das jeweils gedauert hat:

Wir sehen hier verschiedene Informationen, die uns eine kleine Einschätzung zur Performance ermöglichen.  Ganz unten in der Leiste sehen wir eine Zusammenfassung der Ressourcen. In unserem Beispiel sind es 11 Requests, die der Browser angefordert/bekommen hat, die zusammen eine Größe von 3.7 MB haben. Die Größe der einzelnen Ressourcen sehen wir in der Spalte Size. Auffällig sind hier zum Beispiel zwei Bilder mit je 1.7 MB. 

Hier wird übrigens sowohl die übertragene Datenmenge als auch die tatsächliche Größe der Dateien angezeigt. Bei aktiviertem Browsercache kann man dadurch sehen, wie viel man an Datenvolumen einspart. Bei den Dateien aus dem Browsercache steht in der Size-Spalte dann (memory cache). Auch die Einsparung durch eine GZIP-Komprimierung lässt sich hier erkennen.

Bis das DOMContentLoaded-Event ausgelöst wird, vergehen 4.95 Sekunden. Dabei handelt es sich um die Zeit, die vergeht, bis der Browser das HTML-Dokument vollständig geladen und verarbeitet hat (ohne CSS etc.). Es ist in unserem Beispiel identisch mit dem Load-Event, das ausgelöst wird, wenn auch alle Bilder etc. verarbeitet wurden. Dass beide Events hier identisch sind, ist meiner Testseite geschuldet, die voller blockierender Scripte ist (Details dazu gibt es in meinem nächsten Artikel ). In der echten Welt wird das Load-Event in der Regel später ausgelöst.

Erkennbar ist hier, dass der Verbindungsaufbau (Initial connection) mit 118ms zu Buche schlägt. Davon entfallen 109ms auf die SSL-Verbindung. Die SSL-Verbindung muss in einer Browsersession nur einmalig zwischen Client und Server ausgehandelt werden, weshalb sie bei erneuten Aufrufen nicht mehr ins Gewicht fallen würde. Beim Wert Waiting for server response handelt es sich dann im wesentlichen um die TTFB. Der Großteil davon beläuft sich häufig auf die Verarbeitung serverseitiger Prozesse, wie die Seitengenerierung per PHP, aber auch netzwerkseitige Faktoren zählen dazu (näheres dazu hier). 

Die DNS-Auflösung (DNS Lookup) hat hier keinen hohen Wert, da die Seite zu diesem Zeitpunkt schon einmal aufgerufen wurde und daher ein Eintrag im lokalen DNS-Cache war.

Anhand all dieser Werte kann man eine erste Einschätzung dazu treffen, warum eine Seite langsam sein könnte. Auf meiner Beispielseite schlägt die TTFB mit 2,2 Sekunden ordentlich zu. Bei einer Webseite kann dies zum Beispiel darauf hindeuten, dass das Caching nicht richtig eingerichtet ist. Ein paar Ansätze um das zu Analysieren habe ich unter anderem in meinem Blog-Artikel zum Adminpanel von TYPO3 beschrieben. Auf meiner Testseite ist es übrigens nur ein usleep(2200000), mit dem ich die Seitenauslieferung bewusst um 2,2 Sekunden verzögere.

Darüber hinaus kann ich aber auch direkt sehen, ob zum Beispiel große Datenmengen geladen werden, die es zu optimieren gilt. Auch hier macht meine Testseite übrigens einen klassischen Fehler und lädt sehr große Bilder (big.jpg und big2.jpg mit jeweils 1.7 MB). Falls die Bilder nicht offensichtlich in einer falschen Größe ausgeliefert werden, lohnt sich ein Blick auf den Blogbeitrag zum Thema Image Optimizer. Auf meiner Testseite habe ich es mir übrigens einfach gemacht und Bilder mit einer Größe von 12.000 x 10.000 Pixeln eingebunden. Das sollte man natürlich unter allen Umständen vermeiden, da solche Auflösungen selbst für 8K-Monitore nicht notwendig sind.  

Als kleines Goodie möchte ich in diesem Artikel noch ein eher verstecktes Tool zeigen. Wer keine genauere Analyse der Core Web Vitals braucht (vgl. letzter Blog-Artikel) und einfach schnell mal die Zahlen sehen will, wird auch hier von Chrome nicht enttäuscht. Dafür kann man in den DevTools die Rendering-Einstellungen benutzen. Hier gibt es zum Beispiel die Möglichkeit, ein Overlay für die Core Web Vitals zu aktivieren. Man kann die Oberfläche entweder über die More Tools-Schaltfläche öffnen (s.o.) oder über Strg + Shift + P das Rendering-Command starten. Darin aktivieren wir dann die Core Web Vitals:

Die Messwerte werden immer dann aktualisiert, wenn man im Browser auf Seiten navigiert. Das Overlay ist leider an der oberen rechte Ecke fixiert und kann daher auch Teile einer Webseite (wie ein Menü) überdecken, die man dann nicht mehr benutzen kann. Dennoch eignet es sich aus meiner Sicht gut für einen schnellen Überblick darüber, wie gut oder schlecht die Performance einer Seite ist und woran das vielleicht liegen mag. 

Mit dem Network-Tool haben wir in diesem Artikel schon ein mächtiges Tool kennengelernt, mit dem wir uns einen relativ schnellen Überblick über die Performance einer Seite verschaffen können. Außerdem haben wir damit die Möglichkeit, eine Seite auch mit schlechteren Internetverbindungen zu testen. Im nächsten Artikel werfen wir einen genaueren Blick auf meine Testseite, in der ich viele klassische Aspekte eingebaut habe, die eine Webseite langsam machen. Mit Hilfe weiterer DevTools werden wir herausfinden, welche das sind. 

Tipp!

Die kürzesten Ladezeiten erreichst du mit hoch performantem Hosting. Willst du top Pagespeed für jedes deiner Projekte? Dann check den Agentur-Server und erhalte maximale Performance für jedes deiner Projekte - ab dem kleinsten Tarif.