Was ist neu bei Google Lighthouse 8.0 – FAQ

Was ist neu/anders in der Version 8.0?

Zunächst kann es nützlich sein, die Mathematik hinter den Metrikwerten und der Leistungsbewertung von Lighthouse zu verstehen.

In Lighthouse v8.0 wurden die Score-Kurven für FCP- und TBT-Messungen aktualisiert und beide etwas strenger bewertet. CLS wurde auf eine neue Fensterdefinition aktualisiert. Darüber hinaus wurde der gewichtete Durchschnitt des Performance-Scores neu ausbalanciert, wobei CLS und TBT mehr Gewicht als zuvor eingeräumt und die Gewichtung von FCP, SI und TTI leicht verringert wurde.

Aus einer Analyse des neuesten Web-Crawlings von HTTP Archive geht das Lighthouse-Projekt davon aus, dass die Leistungsbewertung für die meisten Websites in Version 8.0 gleich bleibt oder sich verbessert.

• ~20 % der Websites können einen Rückgang von bis zu 5 Punkten verzeichnen, wahrscheinlich jedoch weniger
• ~20 % der Websites werden kaum erkennbare Veränderungen feststellen
• ~30% der Websites sollten eine moderate Verbesserung um einige Punkte sehen
• ~30% könnten eine signifikante Verbesserung von 5 Punkten oder mehr sehen

Die größten Einbußen bei den Scores sind auf die strengere TBT-Bewertung und die etwas höhere Gewichtung der Metrik zurückzuführen. Die größten Verbesserungen bei den Scores sind auch auf TBT-Änderungen im Longtail und die Fensterung von CLS sowie auf die höheren Gewichtungen beider Metriken zurückzuführen.

Was sind die genauen Änderungen der Punktzahlgewichtung?

Änderungen nach Metrik

Metrik	v6 Gewichtung	v8 Gewichtung	Δ
First Contentful Paint (FCP)	15	10	-5
Speed Index (SI)	15	10	-5
Largest Contentful Paint (LCP)	25	25	0
Time To Interactive (TTI)	15	10	-5
Total Blocking Time (TBT)	25	30	5
Cumulative Layout Shift (CLS)	5	15	10

Änderungen nach Phase

Phase	Metrik	v6 Gewichtung	v8 Gewichtung	Δ
Früh	First Contentful Paint (FCP)	15	10	-5
Mitte	Speed Index (SI)	40	35	-5
	Largest Contentful Paint (LCP)
Interaktivität	Time To Interactive (TTI)	40	40	0
	Total Blocking Time (TBT)
Vorhersagbarkeit	Cumulative Layout Shift (CLS)	5	15	10

Warum ist das Gewicht von CLS gestiegen?

Bei der Einführung in Lighthouse v6 war die Metrik noch in den Anfängen. Seitdem wurden viele Verbesserungen und Bugfixes an der CLS-Metrik vorgenommen. Angesichts der Reife und der etablierten Platzierung in Core Web Vitals erhöht sich die Gewichtung nun von 5 % auf 15 %.

Warum werden die Core Web Vitals-Metriken in der Leistungsbewertung unterschiedlich gewichtet?

Die Core Web Vitals sind unabhängige Signale im Ranking-Update für die Seitenerfahrung. Lighthouse gewichtet jede Lab-Äquivalent-Kennzahl basierend auf dem, was Meinung des Lighthouse-Projektes nach die besten Anreize zur Verbesserung der allgemeinen Seitenerfahrung für Benutzer schafft.

LCP, CLS und TBT sind hervorragende Metriken und deshalb die drei am höchsten gewichteten Metriken in der Leistungsbewertung.

Wie ist die Lighthouse-Leistungsbewertung in Bezug auf Core Web Vitals zu bewerten?

Core Web Vitals beziehen sich auf einen bestimmten Satz wichtiger Benutzererfahrungsmetriken, deren Bestehensschwellenwerte und das Perzentil, an dem sie gemessen werden. Im Allgemeinen liegt der Hauptfokus von CWV auf Felddaten.

Der Lighthouse-Score ist ein Mittel, um den Grad der verfügbaren Möglichkeiten zu verstehen, um kritische Elemente der Benutzererfahrung zu verbessern. Je niedriger die Punktzahl, desto wahrscheinlicher hat der Benutzer Probleme mit der Ladeleistung, Reaktionsfähigkeit oder Inhaltsstabilität.

Die laborbasierten Daten von Lighthouse überschneiden sich in einigen wichtigen Punkten mit Core Web Vitals. Lighthouse verfügt über zwei der drei Kernfunktionen (LCP und CLS) mit genau den gleichen Schwellenwerten für das Bestehen. In einem Lighthouse-Audit gibt es keine Benutzereingabe, daher kann die FID nicht berechnet werden. Stattdessen existiert TBT, das Sie als Proxy-Metrik für FID betrachten können, und obwohl sie zwei verschiedene Dinge messen, sind beide Signale über die Interaktivität einer Seite.

CWV und Lighthouse haben also Gemeinsamkeiten, sind aber unterschiedlich. Wie kann trotz der Unterschiede auf beides geachtet werden?

Letztendlich ist ein kombinierter Ansatz am effektivsten. Verwende die Felddaten für einen langfristigen Überblick über die Erfahrung Deiner Benutzer und verwende die Labordaten, um Ihren Weg zur bestmöglichen Erfahrung für Deine Benutzer zu iterieren. CrUX-Daten fassen die letzten 28 Tage zusammen, daher wird es einige Zeit dauern, um sicher zu bestimmen, dass jede Änderung definitive Auswirkungen hat.

Die Lighthouse-Analyse ermöglicht es, in einer Umgebung zu debuggen und zu optimieren, die mit einer sofortigen Feedbackschleife wiederholbar ist. Darüber hinaus können Labor-basierte Tools wesentlich mehr Details liefern als Feldinstrumentierung, da sie nicht auf webbasierte API und ursprungsübergreifende Beschränkungen beschränkt sind.

Es wird nicht erwartet, dass die genauen Zahlen Deiner Labor- und Feldmesswerte übereinstimmen, aber jede wesentliche Verbesserung Deiner Labormesswerte sollte nach der Bereitstellung im Feld sichtbar sein. Je höher die Lighthouse-Punktzahl, desto weniger überlässt Du die Werte dem Zufall auf dem Feld.

Welche blinden Flecken aus dem Feld können Labortools ausleuchten?

Felddaten analysieren alle erfolgreichen Seitenladevorgänge. Wenn jedoch fehlgeschlagene und abgebrochene Ladevorgänge ausgeschlossen werden oder die Berichterstellung durch Erweiterungen blockiert wird, können die gesammelten Felddaten darunter leiden. Nutzer mit besseren Erfahrungen nutzen Deine Website häufiger. Deshalb liegt dem Lighthouse-Projekt in erster Linie die Leistung am Herzen. Laborergebnisse zeigen Dir die Qualität der Erfahrung für diese Benutzer, dass Felddaten möglicherweise vollständig fehlen.

Lighthouse Mobile Reports emulieren eine langsame 4G-Verbindung auf einem Mid-Tier-Android-Gerät. Obwohl Felddaten möglicherweise nicht darauf hindeuten, dass diese Bedingungen für Deine Website besonders häufig sind, hilft die Analyse der Leistung Deiner Website unter diesen härteren Bedingungen, die Zielgruppe Deiner Website zu erweitern. Lighthouse identifiziert die schlimmsten Erfahrungen. Erfahrungen, die Du im Feld nicht sehen kannst, weil sie so schlecht waren, dass der Benutzer nie zurückkam (oder überhaupt wartete).

Wie immer ist es die empfohlene Vorgehensweise, sowohl Labor- als auch Felddaten zu verwenden, um die Benutzererfahrung zu verstehen und zu optimieren. Hier kannst du mehr über die Feld- & Labordaten lesen.

Wie sollte ich vorgehen, um CLS anders zu optimieren, nachdem es aktualisiert wurde?

Die Windowing-Anpassung wird wahrscheinlich keinen großen Einfluss auf die Labormessung haben, aber stattdessen einen großen Einfluss auf das Feld CLS für langlebige Seiten.

Lighthouse 8 führt eine weitere Anpassung der CLS-Definition ein: einschließlich der Beiträge zur Layoutverschiebung von Hilfsrahmen. Dies bringt die Implementierung in Einklang damit, wie CrUX das Feld CLS berechnet. Dies hat zur Folge, dass iFrames (einschließlich solcher, die Du möglicherweise nicht kontrollierst) Layoutverschiebungen hinzufügen, die sich letztendlich auf Deinen CLS-Score auswirken. Beachte, dass die Subframe-Beiträge nach dem Teil des iFrames im Ansichtsfenster gewichtet werden.

Warum stimmen die Zahlen für TBT und FID nicht überein, wenn TBT eine Proxy-Metrik für FID ist?

Die Gemeinsamkeit zwischen TBT (in einer Laborumgebung gesammelt) und FID (in einem Feldkontext gesammelt) besteht darin, dass sie die Auswirkungen langer Aufgaben im Hauptthread auf die Eingabereaktionszeit messen. Darüber hinaus sind sie ganz unterschiedlich. FID erfasst die Verzögerung bei der Verarbeitung des ersten Eingabeereignisses der Seite, wenn diese Eingabe erfolgt ist. TBT erfasst grob, wie gefährlich die Länge aller Aufgaben des Hauptthreads ist.

Es ist gut möglich, eine Seite zu haben, die bei FID gut abschneidet, aber bei TBT schlecht. Und es ist etwas schwieriger, aber möglich, bei TBT gut abzuschneiden, aber bei FID* schlecht. Du solltest also nicht erwarten, dass Deine TBT- und FID-Messungen stark korrelieren. Eine groß angelegte Analyse ergab, dass ihr Spearman-ρ bei etwa 0,40 liegt, was auf eine Verbindung hindeutet, aber nicht so stark, wie viele es bevorzugen würden.

Aus der Perspektive des Lighthouse-Projektes ist der aktuelle Schwellenwert für das Bestehen von FID ziemlich nachsichtig, aber noch wichtiger ist, dass das Perzentil des Datensatzes für FID (75. Perzentil) nicht ausreicht, um Probleme zu erkennen. Das 95. Perzentil ist ein viel stärkerer Indikator für problematische Interaktionen für diese Metrik. Wir empfehlen benutzerorientierten Teams sich auf das 95. Perzentil aller Eingabeverzögerungen (nicht nur die erste) in ihren Felddaten zu konzentrieren, um Probleme zu identifizieren und zu beheben, die nur in 5 % der Fälle auftreten.

*Außerdem: Die Chrome 91 FID-Änderung für Doppeltippen zum Zoomen behebt viele Fälle mit hohem FID / niedrigem TBT und kann in Ihren Feldmetriken beobachtet werden, wobei sich höhere Perzentile leicht verbessern. Die meisten verbleibenden Fälle mit hohem FID / niedrigem TBT sind wahrscheinlich auf falsche Meta-Viewport-Tags zurückzuführen, die Lighthouse markiert. Die Bereitstellung eines mobilfreundlichen Ansichtsfensters, die Reduzierung des Hauptthread-Blockings von JS und die Reduzierung Ihres TBT sind die beste Verteidigung gegen schlechte FID im Feld.

Was hat die Änderungen an der Leistungsbewertung insgesamt motiviert?

Wie bei allen Lighthouse-Score-Updates werden Änderungen vorgenommen, um die neuesten Erkenntnisse zur ganzheitlichen und genauen Messung der Qualität der Benutzererfahrung zu berücksichtigen und die Aufmerksamkeit auf die wichtigsten Prioritäten zu lenken.

Schweres JavaScript und lange Aufgaben sind ein Problem für das Web, das sich verschlimmert. Field FID ist derzeit zu nachsichtig und bietet keine ausreichenden Anreize für Maßnahmen, um das Problem anzugehen. Lighthouse hat seine Interaktivitätskennzahlen in der Vergangenheit mit 40-55 % der Leistungsbewertung gewichtet, und da Interaktivität der Schlüssel zur Benutzererfahrung ist, behält Lighthouse 8.0 eine Gewichtung von 40 % (TBT und TTI zusammen) bei.

Die Score-Kurve von FCP wurde so angepasst, dass sie mit dem aktuellen de facto “guten” Schwellenwert übereinstimmt, und wird daher etwas strenger punkten.

Die Kurve für TBT wurde strenger gemacht, um der idealen Score-Kurve näherzukommen. TBT hatte (und hat) eine mildere Kurve, als es die bisherige Methodik es vorschreibt, aber die neue Kurve ist linearer, was bedeutet, dass es einen größeren Bereich gibt, in dem Verbesserungen der Metrik mit Verbesserungen der Punktzahl belohnt werden. Wenn Deine Seite derzeit bei TBT schlecht abschneidet, reagiert die neue Kurve besser auf Änderungen, wenn sich die Seitenleistung schrittweise verbessert.

Das Gewicht von FCP sinkt leicht von 15 % auf 10 %, da es ziemlich spielbar ist und auch teilweise vom Speed ​​Index erfasst wird.

Was ist die Geschichte von TTI?

TTI spielt eine nützliche Rolle, da es der größte gemeldete Metrikwert ist (oft >10 Sekunden) und hilft, Wahrnehmungen zu verankern.

Das Team von Lighthouse sieht TBT als eine stärkere Kennzahl zur Bewertung des Zustands des Haupt-Threads und seiner Auswirkungen auf die Interaktivität, außerdem weist sie eine geringere Variabilität auf. TTI dient als nette Ergänzung, die die Kosten langer Aufgaben, oft von schwerem JavaScript, erfasst. Die Projektmitglieder gehen jedoch davon aus, das Gewicht von TTI weiter zu reduzieren und es wahrscheinlich in einer zukünftigen großen Lighthouse-Version zu entfernen.

Wie wird der Lighthouse Performance Score berechnet? Worauf basiert es?

Der Lighthouse-Performance-Score wird aus einem gewichteten, gemischten Satz von Leistungsmetriken berechnet. Du kannst die aktuellen und vorherigen Lighthouse-Score-Bestandteile (welche Metriken zusammengeführt und gewichtet werden) im Score-Rechner sehen und hier mehr über die Lighthouse Berechnungsdetails erfahren.

Wie kann ich meine Website unter Lighthouse v8.0 testen?

Folgende Möglichkeiten gibt es:

• Ab Chrome v93
• Auf https://web.dev/measure/
• Im PageSpeed Insights Test

Was wurde noch an Lighthouse v8.0 geändert?

Den ausführlichen Changelog findest du auf Github.