SEO: Performance optimieren mit Google Lighthouse

Google Lighthouse Performance SEO

Wie rankt eine Website auf Google besonders hoch? Eine Frage, mit der wir uns bei dmf täglich beschäftigen. Eines unserer wichtigsten Tools, um das Suchmaschinenranking zu messen und zu optimieren, ist Google Lighthouse. In unserem wöchentlichen Academy Meeting* hat Lukas (Frontend- und PWA-Entwickler) nun seine Erfahrungen mit den Google Lighthouse Performance Metriken mit dem ganzen Team geteilt. Seine Tipps sind so wertvoll, dass wir sie auch Ihnen nicht vorenthalten wollen.

Lukas ist seit 2016 im dmf-Team. Als Senior Frontend Developer realisiert er nicht nur erfolgreiche Onlineshops für unsere Kund:innen, sondern entwickelt darüber hinaus maßgeblich unser Produkt PWA hubble commerce.

Was muss man grundsätzlich bei der Messung mit Google Lighthouse beachten?

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.

Wie misst Google Lighthouse die Performance einer Seite?

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.

Google Lighthouse Performance Audit
Quelle: Ergotopia

Wie werden die einzelnen Performance-Metriken gewichtet?

Das Ergebnis des Google Lighthouse Audits im Bereich Performance ist ein gewichteter Durchschnitt dieser sechs Metriken. Stärker gewichtete Metriken haben also eine größere Auswirkung auf die Gesamtbewertung.

“Seit dem Erscheinen der Lighthouse Version 8 am 02.06.2021 legt Google noch größeren Wert auf die Core Web Vitals”, erläutert Lukas. So ist beispielsweise die Gewichtung der Cumulative Layout Shifts (CLS) von 5 auf 15 Prozent gestiegen. Die Total Blocking Time (TBT) und der Largest Contentful Paint (LCP) haben mit 30 und 25 Prozent den größten Einfluss auf das Ergebnis. Alle anderen Werte werden mit 10 Prozent gewichtet.

“Bei Lighthouse 9 gibt es ein neues Feature, mit dem sich das Messen noch einmal etwas geändert hat ‒ die sogenannten User Flows”, erklärt Lukas. Diese seien insbesondere für die Performance-Verbesserung von PWAs interessant. Darauf gehen wir später genauer ein.

Wie lassen sich die einzelnen Werte verbessern?

Google Lighthouse macht in den “Performance Audit Empfehlungen” Vorschläge, wie die Leistung der gemessenen Seite verbessert werden kann. “Ich halte diese Empfehlungen allerdings für sehr allgemein und wenig aussagekräftig. Ein viel hilfreicheres Tool ist die Performance Audit Diagnose”, so Lukas. Diese zeige genau an, welche spezifischen Dateien für Verzögerungen in der Ladezeit sorgen. Darüber hinaus helfe auch der Network-Tab dabei, Probleme zu diagnostizieren und zu beheben.

Folgende Maßnahmen können Seitenbetreiber:innen treffen, um die einzelnen Werte zu verbessern:

FCP 

Wenn der FCP einen hohen Wert aufweist, müssen Seitenbetreiber:innen die Antwortzeit des Servers verkürzen (Caching). Darüber hinaus sollten sie prüfen, ob Render-blocking Resources (z.B. Fonts, nicht genutztes CSS) die Ladezeit verlangsamen, und diese eliminieren.

LCP

Um die LCP-Metrik zu optimieren, muss man zunächst dafür sorgen, dass Google das richtige Element als Hauptinhalt der Seite erkennt. “Häufig hält Google fälschlicherweise den Cookie-Hinweis für den LCP, wenn dieser das größte Element der Seite darstellt”, erläutert Lukas. “Eine Möglichkeit ist, den Cookie-Banner kleiner zu skalieren als den Hauptinhalt. Hier sollten Onlinehändler:innen mit Cookie-Consent-Drittanbietern eine passende Lösung finden.”

Lukas empfiehlt außerdem: “Wenn der LCP ein Asset, also z.B. ein Bild, ist, kann man einen preload-Tag setzen. Das erhöht die Priorität des Assets beim Laden.”

TTI / TBT

Wenn die Werte für die TTI oder die TTB zu hoch sind, sollten Seitenbetreiber:innen zunächst “aufräumen”:

  • Drittanbieter Code sichten und aufräumen
  • JS aufräumen, nicht benutzten Code löschen

Darüber hinaus können sie folgende Maßnahmen ergreifen:

  • JS via Webpack splitten (Chunks) 
  • Chunks via dynamic Imports & Events nachladen

CLS

Um die CLS-Metrik zu verbessern, können Seitenbetreiber:innen beim Lazy Loading von Bildern mit Platzhaltern und Ladeanimationen arbeiten. Mehr hilfreiche Tipps, wie man Layout Shifts vermeidet, erfahren Sie in diesem Blog-Beitrag..

Warum erhalte ich bei der Performance-Messung mit Google Lighthouse andere Ergebnisse als mit PageSpeed Insights?

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:

Lighthouse in den aktuellen Chrome Dev Tools

Lighthouse von PageSpeed Insights

“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?”

Sonderfall: Google Lighthouse und PWA

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.  

Fazit

Google Lighthouse kann ein sehr nützliches Tool sein, um die Performance einer Seite und damit das Suchmaschinen-Ranking zu optimieren. Wichtig ist allerdings das Wissen darüber, wie die Ergebnisse zu interpretieren sind und an welchen Stellschrauben man drehen muss.

Lukas’ Tipp für eine gute Performance: “Generell kann man sagen: Je schlanker eine Webseite ist, desto besser performt sie auch. Eine Seite, die maximal 300 oder 400 KB groß ist, kann keine schlechte Seitenladezeit haben. Um eine gute Performance zu erreichen, muss man dafür sorgen, dass nur die Daten geladen werden, die gerade gebraucht werden und die im aktuellen Viewport sichtbar sind.”

*In der dmf Academy treffen sich unsere verschiedenen Themen-Expert:innen wöchentlich, um Entwicklungen am Markt einzuordnen und Lösungen zu finden. Schließlich wollen wir als Online-Shop-Spezialist:innen unseren Kund:innen immer die aktuell beste Lösung anbieten. Mal sehen, welches spannende Thema als nächstes auf die Agenda unserer Academy kommt. Wir halten Sie auf dem Laufenden.