High Performance

Google Lighthouse ist ein sehr nützliches Werkzeug, mit dem wir unter anderem unterschiedliche Facetten der Ladezeit von Webseiten messen können. Das Developer Tool ist in den Chrome-Browser integriert. Jede:r Webseitenbetreiber:in kann damit überprüfen, wie Google die Seite bewertet und an welchen Stellen es Verbesserungspotential gibt.

Für die richtige Interpretation der Messergebnisse gibt es allerdings ein paar Dinge zu beachten. “Es ist wichtig zu wissen, dass Google Lighthouse eine gedrosselte Internet- und CPU-Leistung simuliert”, so Lukas. “Das liegt daran, dass Google alle Seiten für die mobile Nutzung optimieren will. Webseiten sollen auch bei geringer Bandbreite reibungslos funktionieren und die bestmögliche User Experience bieten”, erklärt Lukas weiter und konstatiert: “Eine gute Performance trotz schwacher Internetleitung wird mit einem hohen Ranking belohnt.”

Diese simulierte Drosselung durch Google führt dazu, dass Schwankungen in den Ergebnissen des Google Lighthouse Audits auftauchen können. Lukas empfiehlt: “Jede Messung ist ein bisschen anders. Man sollte daher mehrere Messungen machen, um einen verlässlichen Mittelwert zu erhalten.” Außerdem rät er, das Caching auszustellen (“clear storage”) und immer im Inkognito-Tab zu messen, um ein möglichst aussagekräftiges Ergebnis zu erzielen. Auf diese Weise vermeidet man, dass Plugins das Ergebnis beeinflussen.

Um die Leistung bzw. Performance einer Webseite zu messen, wertet Google Lighthouse folgende Metriken aus:

First Contentful Paint (FCP)

Dieser Wert gibt Aufschluss darüber, wie schnell der Server antwortet: Wann ist der allererste Inhalt auf der Seite zu sehen? Ein Wert zwischen 0 und 2 Sekunden liegt hier im grünen Bereich. 

Speed Index (SI):

Der Speed Index verrät, wie schnell Inhalte während des Ladevorgangs sichtbar werden. Der Wert setzt sich aus dem FCP, dem LCP und der TTI zusammen und sollte zwischen 0 und 3,4 Sekunden liegen. 

Largest Contentful Paint (LCP) 

Der LCP ist Teil der Google Core Web Vitals. Er gibt an, wie schnell das “Hero-Element” (das größte Element auf dem initialen Viewport) der Seite lädt. Dabei wertet Google den beim Seitenaufruf sichtbaren Teil der Seite aus. Der LCP sollte unter 2,5 Sekunden liegen, um von Google als „gut“ bewertet zu werden.

Time To Interactive (TTI) 

Diese Kennzahl zeigt an, wann die Webseite komplett verfügbar für Eingaben der Benutzer:innen ist. Konkret wird gemessen, zu welchem Zeitpunkt die Seite innerhalb von 50 Millisekunden auf Benutzereingaben antwortet. Ein Wert von bis zu 3,8 Sekunden liegt bei Google Lighthouse im grünen Bereich.

Total Blocking Time (TBT)

Die TBT sagt aus, wie lange die Anwender:innen nicht mit der Seite interagieren können, während diese lädt. Diese Zeit sollte unter 300 Millisekunden liegen. Die Metrik ist am ehesten mit dem First Input Delay (FID) der Core Web Vitals vergleichbar.

Cumulative Layout Shift (CLS)

Auch der CLS ist Teil der Google Core Web Vitals. Er quantifiziert das Ausmaß unerwarteter Layout-Verschiebungen. Das passiert z.B., wenn Werbebanner oder andere Elemente nachgeladen werden und die Seite in Sekundenschnelle zu einer anderen Stelle springt. Auch hier betrachtet Google, genau wie beim LCP, nur den aktuellen Viewport. Um hier einen gute Bewertung im Google Lighthouse Audit zu erreichen, sollte der Wert nicht größer als 0,1 sein. Das entspricht einer Layout-Verschiebung von 10 Prozent.

Auch das Tool Google PageSpeed Insights misst und bewertet die Performance von Webseiten und verwendet dabei für die Labor-Daten die Google Lighthouse Engine. Wer sowohl mit Google Lighthouse in den Chrome Dev Tools als auch mit den PageSpeed Insights arbeitet, wird sich vielleicht wundern: Häufig unterscheiden sich die Ergebnisse im Hinblick auf die Seitenladegeschwindigkeit.

“Wie bereits angesprochen, werden Metriken je nach Lighthouse-Version unterschiedlich gewichtet oder gemessen. Leider entspricht die Version von Lighthouse, die PageSpeed Insights verwendet, oft nicht der Version, wie sie in den Chrome Developer Tools implementiert ist. So kann es zu Abweichungen in den Ergebnissen kommen”, erklärt Lukas. 

Die verwendeten Versionen lassen sich im jeweiligen Tool im Kleingedruckten nachlesen:

“Zum anderen muss einem bewusst werden, was für Daten man sich in PageSpeed Insights anschaut. Der obere Teil mit den Core Web Vitals bezieht sich auf Felddaten. Das sind reale, empirische Nutzerdaten aus dem Chrome UX Report”, erläutert Lukas. Er fährt fort: “Der Block darunter zeigt die Labordaten und diese basieren auf den Google Lighthouse Performance Audits. Die Bedingungen werden bei der Messung, wie oben erklärt, simuliert. Das Audit stellt deshalb nur theoretische Werte dar.”

Google Lighthouse: Simulierte Labordaten Google PageSpeed Insights: Felddaten (= reale Nutzererfahrungen)

Was bedeutet das konkret für die Praxis? Auf welche Daten sollen sich Seitenbetreiber:innen stützen, die ihre Performance verbessern wollen?  Lukas’ Empfehlung: “Das Wichtigste ist, dass die Felddaten, also die realen Nutzererfahrungen, gut sind. Je besser die Lab-Daten (also die Messung unter schlechtesten Bedingungen) schon vorbereitet sind, desto besser sind auch die Feldwerte. Generell muss man die Zahlen aber immer ganzheitlich beleuchten, um sie richtig interpretieren zu können. Haben Sie beispielsweise eine junge, mobile Zielgruppe? Oder ist die Zielgruppe z.B. eine Behörde, die die Seite über den Desktop mit stabiler Internetverbindung nutzt?”

Die unterschiedlichen Messmethoden von Google Lighthouse und den PageSpeed Insights machen sich in der Praxis besonders bei den Messwerten für Layout Shifts bemerkbar. Lukas erklärt den Grund: “Die PageSpeed Insights messen die Seiten so, wie die User:innen sie nutzen. Diese kommen auf die Landingpage, scrollen runter, klicken auf einen weiterführenden Link usw. Google Lighthouse hingegen misst nur die aktuell ausgewählte Seite ohne richtige Interaktionen. Für klassische Websites macht das kaum einen Unterschied, da mit jedem Seitenaufruf die Seite komplett neu gerendert wird. Anders sieht das aber bei PWA oder SPA aus.” 

PWA und SPA verhalten sich beim Navigieren zwischen den verschiedenen Seiten anders als klassische Websites: Es finden keine echten Seitenaufrufe statt, sondern es wird z.B. nur der Inhalt neu gerendert und die URL angepasst. Header und Footer bleiben gleich. Dementsprechend kann eine PWA unterschiedlich reagieren, je nachdem, ob es der erste Seitenaufruf oder nur eine Interaktion mit der App ist. Das führt dazu, dass die Messergebnisse mit Google Lighthouse gegenüber den Felddaten an Aussagekraft verlieren bzw. abweichen.

“In der Version Lighthouse 9 hat Google für diese Problem eine Lösung gefunden ‒ die vorhin schon einmal kurz angesprochenen ‘User Flows’”, erklärt Lukas. “Mit diesem neuen Feature lassen sich Interaktionen mit der Seite aufzeichnen und analysieren.”  Dabei geht man folgendermaßen vor:

Aufzeichnung starten Mit der App interagieren, je nachdem, was man testen will Aufzeichnung beenden

Lighthouse misst dabei die Performance für die aktuelle Seite und zusätzlich für die aufgezeichneten Interaktionen. User Flows stehen allerdings momentan noch nicht für die Chrome Developer Tools zur Verfügung, sondern nur für die programmatische Verwendung von Google Lighthouse. Allerdings gibt es bereits eine abgespeckte Version, die nur eine Performance-Aufzeichnung unter dem Tab “Recorder” macht.