Performance-Boost (5): Mehr Chrome DevTools − Performance Insights & JavaScript Profiler
Dafür habe ich eine kleine Website auf Basis von Bootstrap erstellt, die bewusst viele Dinge im Hinblick auf die Performance falsch macht. Ihr könnt sie hier als .zip-Datei herunterladen.
Performance-Tab
Wenn ihr tiefer in eine Seite einsteigen möchtet, als es das Netzwerk-Modul und der Lighthouse-Test ermöglichen, könnt ihr auf das Performance-Modul zurückgreifen.
Die Ausführungen dazu halte ich kurz, da es mit dem Performance Insights-Modul noch ein weiteres Tool gibt, das sich aus meiner persönlichen Sicht meist besser eignet. (siehe nächster Abschnitt). So oder so: Spätestens jetzt solltet ihr die Funktion zur Trennung der DevTools vom aktuellen Browser-Tab kennen, weil es sonst sehr unübersichtlich wird. Ein zweiter Monitor macht die Arbeit außerdem noch mal angenehmer.
Um die Dev-Tools vom aktuellen Browserfenster zu lösen, öffnet ihr das Dev-Tools-Menü oben rechts (drei Punkte) und wechselt die Ansicht (siehe rechts).
In den Dev-Tools wechselt ihr nun auf den Punkt „Performance“, was dann in etwa so aussehen sollte:
Ihr habt nun die Möglichkeit eine längere Aufnahme zu starten − zum Beispiel, um die Navigation einer Seite aufzuzeichnen. Oder das initiale Laden. Damit sich der Profiler dabei nicht verschluckt, empfehle ich die Seite vorher auch schon einmal manuell aufzurufen.
Das Ergebnis sieht dann zum Beispiel so aus:
Es wird in recht detaillierter Form aufgezeichnet, welche Elemente wann erzeugt werden − inklusive Screenshots, falls der Haken oben gesetzt ist. Außerdem kann nachvollzogen werden, welche Skripte involviert sind und wann welche Events ausgelöst wurden − inklusive Web Vitals Messpunkten, falls der entsprechende Haken gesetzt wurde.
Geht ihr mit der Maus im Bereich „Timings“ (Mitte) zum Beispiel über den Eintrag zu LCP, wird auf der Website das LCP-Element (Largest Contentful Paint) hervorgehoben:
Das Performance-Modul kann natürlich noch viel mehr. Alle Funktionen zu erklären, würde diesen Blogartikel allerdings sprengen. Werft daher gerne einen Blick in die Doku.
Performance Insights-Tab
Wer das Ganze noch eine Nummer besser (oder zumindest übersichtlicher) haben will, kann das Performance Insights-Modul nutzen. Es handelt sich dabei aktuell noch um ein sogenanntes „Preview Feature“. Aus meiner Sicht kann es aber schon super genutzt werden.
Für die Chromium-Nutzer unter euch gibt es einen kleinen Wermutstropfen: Während alle anderen bisher vorgestellten Tools sowohl in Chrome, als auch in Chromium genutzt werden können, gibt es dieses Feature tatsächlich nur in Chrome. Ähnlich wie beim Performance-Modul müsst ihr es eventuell noch über die drei Punkte → More tools aktivieren. Es begrüßt euch dann eine Überfläche mit verschiedenen Einstellungsmöglichkeiten:
Zu Demonstrationszwecken erkläre ich euch, wie ihr einen Mitschnitt eines einfachen Seitenaufrufs ohne Throttling von einer Test-Seite erstellt. Das bedeutet, dass dieses Messergebnis nicht repräsentativ für einen Aufruf über ein Smartphone / Tablet oder über ein mobile Datenverbindung ist.
Damit das sauber funktioniert, solltet ihr den Browser-Tab mit der Website in jedem Fall geöffnet haben, da andernfalls das Rendering der Elemente nicht richtig gemessen werden kann. Die Messung bezieht sich nämlich auf den tatsächlichen Seitenaufruf, wozu dann zum Beispiel auch die Fenstergröße zählt. Deswegen empfiehlt sich hier die Nutzung eines zweiten Monitors, damit die Seite „normal“ aufgerufen werden kann und das Performance Insights Modul auf einem anderen (auch kleineren) Monitor läuft, ohne die Ansicht der Website zu verändern.
Sobald das alles vorbereitet ist, könnt ihr auf den „Measure page load“-Button drücken und die Aufnahme laufen lassen. Am Ende bekommt ihr ein Ergebnis, das zum Beispiel so aussehen kann:
Ihr erkennt auf den ersten Blick schon die Parallelen zur Ansicht im Performance-Modul. Allerdings ist der Informationsgehalt hier meistens höher, bzw. relevante Stellen einfacher zu erreichen.
Fokussiert euch erst einmal auf den rechten Bereich mit den „Insights“. Ihr müsst euch nämlich nicht durch die ganzen Graphen ackern, um relevante Elemente und Skripte zu finden, sondern bekommt direkt eine Kette von Events angezeigt, die für die Performance eurer Website relevant sind. Im konkreten Fall sind das einige Render blocking requests, ein Long Task und ein Layout Shift. Kurze Erklärung zwischendurch: Bei Render blocking requests handelt es sich um Ressourcen, die vom Browser geladen werden müssen, bevor die Seite wirklich ausgegeben werden kann. Meistens sind das CSS- oder JavaScript-Dateien.
Wenn ihr einen der Punkte anklickt, bekommt ihr Details zu dem betroffenen Element, zum Beispiel wie rechts zu sehen.
Ihr bekommt nicht nur die betroffene Ressource angezeigt (in diesem Fall die bootstrap.min.css), sondern sogar noch einen Hinweis, wie das Problem behoben werden kann: Diese CSS-Datei enthält offensichtlich Anweisungen, die zu den critical styles der Seite zählen. Um hier nicht vollständig von der Messung in die Optimierung einer Seite abzudriften, gibt es zu diesem Problem hier mehr Infos.
Abseits von Render Blocking Requests kann euch aber auch bei JavaScript geholfen werden. Dafür erfolgt eine (simple) Analyse der Long Tasks. Mit einem Klick auf den Eintrag werden euch auch hierfür weitere Details angezeigt (siehe links).
Auf der Beispielseite ist das die Funktion calculatePi − diese Funktion nutze ich einfach nur, um unnötige CPU-Last zu erzeugen. Der Code stammt im Wesentlichen von Stack Overflow.
Ich weiß beim besten Willen nicht mehr, warum ich mir diese Question mal in die Lesezeichen gepackt habe, aber für diese Testseite war sie goldrichtig. Die Funktion errechnet mit Hilfe eines Reihenwertes näherungsweise die Kreiszahl Pi. Damit die CPU richtig was zu tun hat, gehen wir über 75 Millionen Iterationen.
function calculatePI(){
let pi = 0;
let iterator = sequence();
let iterations = 75000000;
for(let i = 0; i < iterations; i++){
pi += 4 / iterator.next().value;
pi -= 4 / iterator.next().value;
}
function* sequence() {
let i = 1;
while(true){
yield i;
i += 2;
}
}
console.log('it is not a pie, it is:', pi);
return pi;
}
Das frisst ordentlich Zeit und simuliert aus meiner Sicht ganz gut ein gnadenlos überladenes JavaScript auf einer Website. Die Ausführungsdauer des Skripts schwankt übrigens in Abhängigkeit zur eingesetzten Hardware und dem verwendeten Browser stark. Von ca. 2,3 Sekunden (Core i5-1145G7 + Chrome) bis 15 Sekunden (Core i5-7300U + Firefox) habe ich schon alles gesehen.
Abseits dieses kleinen Ausflugs in die Welt unnötigen CPU-Ressourcenverbrauchs, zeigt mir das Performance-Insights-Modul auch meine Layout-Shifts an. In den Details dazu befindet sich ein Screenshot des betroffenen Bereichs und in manchen Fällen auch nähere Informationen zum Auslöser.
JavaScript-Profiler
Wem die Analyse aus den Performance-Insights im Hinblick auf JavaScript noch nicht genug ist, der kann jetzt noch den JavaScript-Profiler bemühen (eventuell müsst ihr dieses Modul noch über das 3-Punkte-Menü -> More Tools aktivieren). Die vorherigen Tools haben euch zwar schon recht eindeutig gezeigt, dass die calculatePi-Funktion Dreck am Stecken hat, aber was genau braucht da eigentlich so lange? Der JavaScript Profiler gibt Auskunft. Ähnlich wie beim Performance Insights-Modul müsst ihr hier eine Aufnahme starten:
Danach ruft ihr die zu analysierende Seite auf und beendet die Aufnahme, wenn die Seite vollständig geladen ist. Ihr werdet dann mit einer Auswertung begrüßt. Auch hier zeigt sich recht eindeutig, dass im Beispiel calculatePi das Problem ist:
Der wirklich coole Teil kommt, wenn ihr das betroffene Skript (rechte Spalte) anklickt. In diesem Fall die all.js, da dort die Funktion drin ist:
Bei diesem Skript ist natürlich schneller zu erkennen, wo der Performance-Schuh drückt, als es bei einem komplexen JavaScript einer echten Website der Fall wäre. Dennoch zeigt dieses Beispiel aus meiner Sicht ganz gut, wie schnell ihr mit dem JavaScript-Profiler problematische Funktionen finden könnt. Aus meiner Erfahrung heraus sind das übrigens häufig Funktionen, die auf der Website gar nicht benutzt werden oder deren Mehrwert nicht im Verhältnis zum Performance-Verlust stehen.
Fazit
Die DevTools von Chrome bieten sehr mächtige Funktionen, um die Performance einer Seite zu analysieren und Optimierungspotenzial aufzudecken. Ihr braucht dafür natürlich eine gewisse Einarbeitungszeit, wenn ihr sie effektiv nutzen möchtet.
Ich hoffe, dass ich euch den Einstieg in die Performance-Optimierung mit diesem und den vorherigen Blog-Artikeln etwas erleichtern konnte. Zudem sei an dieser Stelle noch einmal gesagt, dass natürlich auch andere Browser wie Firefox oder Safari vergleichbare Tools zur Verfügung stellen. Für eine umfangreiche Performance-Analyse ist es sinnvoll auch auf diese Tools zurückzugreifen, um eine Seite nicht nur im Vergleich von mobiler und Desktop-Ansicht, sondern auch auf unterschiedlichen Browsern zu testen. Denkt immer daran, dass die Websitebesucher von den unterschiedlichsten Geräten und Netzwerken auf eure Websites zugreifen. Wenn ihr allen die beste Performance liefern wollt, führt nichts daran vorbei, so viele Szenarien wie möglich zu untersuchen.
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.
