Neu in Lighthouse 6.0

Neue Messwerte, Aktualisierung des Leistungsbewertungs-Scores, neue Prüfungen und mehr.

Heute veröffentlichen wir Lighthouse 6.0.

Lighthouse ist ein automatisiertes Website-Audit-Tool, das Entwicklern Verbesserungsmöglichkeiten und Diagnosen zur Optimierung der Nutzerfreundlichkeit ihrer Websites bietet. Sie ist in den Chrome-Entwicklertools, in npm (als Node-Modul und als Befehlszeile) oder als Browsererweiterung (in Chrome und Firefox) verfügbar. Sie wird in vielen Google-Diensten eingesetzt, darunter PageSpeed Insights.

Lighthouse 6.0 ist ab sofort über npm und in Chrome Canary verfügbar. Andere Google-Dienste, die Lighthouse nutzen, erhalten das Update bis Ende des Monats. Sie wird Mitte Juli in Chrome 84 (stabile Version) eingeführt.

Verwenden Sie die folgenden Befehle, um die Lighthouse Node-CLI auszuprobieren: bash npm install -g lighthouse lighthouse https://www.example.com --view

Diese Version von Lighthouse enthält eine große Anzahl von Änderungen, die im Änderungslog für Version 6.0 aufgeführt sind. In diesem Artikel gehen wir auf die wichtigsten Punkte ein.

• Neue Messwerte
• Update: Leistungsbewertung
• Neue Audits
• Lighthouse CI
• Der Bereich „Chrome-Entwicklertools“ wurde umbenannt
• Mobile Emulation
• Browsererweiterung
• Budgets
• Links zu Quellenstandorten
• Demnächst
• Viele Grüße

Neue Messwerte

Mit Lighthouse 6.0 werden drei neue Messwerte in den Bericht aufgenommen. Zwei dieser neuen Messwerte – Largest Contentful Paint (LCP) und Cumulative Layout Shift (CLS) – sind Lab-Implementierungen der Core Web Vitals.

Largest Contentful Paint (LCP)

Der Largest Contentful Paint (LCP) ist ein Messwert für die wahrgenommene Ladezeit. Er kennzeichnet den Punkt während des Seitenaufbaus, an dem der Hauptinhalt (oder der „größte“ Inhalt) geladen wurde und für den Nutzer sichtbar ist. LCP ist eine wichtige Ergänzung zu First Contentful Paint (FCP), das nur den Anfang des Ladevorgangs erfasst. LCP gibt Entwicklern Aufschluss darüber, wie schnell Nutzer den Inhalt einer Seite sehen können. Ein LCP-Wert unter 2,5 Sekunden gilt als „gut“.

Weitere Informationen finden Sie in diesem ausführlichen Video zu LCP von Paul Irish.

Cumulative Layout Shift (CLS)

Der Cumulative Layout Shift (CLS) ist ein Messwert für die visuelle Stabilität. Er gibt an, wie stark sich die Inhalte einer Seite optisch verschieben. Ein niedriger CLS-Wert ist ein Signal für Entwickler, dass ihre Nutzer keine unnötigen Inhaltsverschiebungen erleben.Ein CLS-Wert unter 0,10 gilt als „gut“.

Der CLS wird in einer Lab-Umgebung bis zum Ende des Seitenaufbaus gemessen. Im Feld können Sie die CLS bis zur ersten Nutzerinteraktion oder einschließlich aller Nutzereingaben messen.

Weitere Informationen finden Sie in diesem Detaillierten Leitfaden zu CLS von Annie Sullivan.

Gesamte Blockierzeit (Total Blocking Time, TBT)

Die Gesamte Blockierzeit (Total Blocking Time, TBT) gibt die Reaktionsfähigkeit bei der Belastung an. Dabei wird die Gesamtzeit gemessen, in der der Haupt-Thread lange genug blockiert war, um die Reaktionsfähigkeit bei Eingaben zu verhindern. Die Gesamtblockierzeit gibt die Zeitspanne zwischen First Contentful Paint (FCP) und Zeit bis Interaktivität (Time to Interactive, TTI) an. Dieser Messwert ist ein Begleitmesswert für den TTI und ermöglicht eine differenziertere Quantifizierung der Aktivität des Hauptthreads, die die Interaktion eines Nutzers mit Ihrer Seite verhindert.

Außerdem korreliert TBT gut mit dem Messwert First Input Delay (FID), einem Core Web Vital.

Aktualisierung des Leistungsfaktors

Die Leistungsbewertung in Lighthouse wird aus einer gewichteten Kombination mehrerer Messwerte berechnet, um die Geschwindigkeit einer Seite zusammenzufassen. Die Formel für den Leistungsfaktor 6.0 lautet:

Phase	Name des Messwerts	Metrisches Gewicht
Früh (15%)	First Contentful Paint (FCP)	15 %
Mittel (40%)	Speed Index (SI)	15 %
	Largest Contentful Paint (LCP)	25 %
Spät (15%)	Zeit bis Interaktivität (TTI)	15 %
Hauptthread (25%)	Gesamte Blockierzeit (Total Blocking Time, TBT)	25 %
Planbarkeit (5%)	Cumulative Layout Shift (CLS)	5 %

Es wurden drei neue Messwerte hinzugefügt, aber drei alte entfernt: „Erste aussagekräftige Paint“, „Erste CPU-Inaktivität“ und „Maximale potenzielle FID“. Die Gewichte der verbleibenden Messwerte wurden geändert, um die Interaktivität des Hauptthreads und die Layoutvorhersagbarkeit hervorzuheben.

Zum Vergleich: Das ist die Bewertung für Version 5:

Phase	Name des Messwerts	Gewicht
Früh (23%)	First Contentful Paint (FCP)	23 %
Mittel (34%)	Speed Index (SI)	27 %
	First Meaningful Paint (FMP)	7 %
Fertig (46%)	Zeit bis Interaktivität (Time to Interactive, TTI)	33 %
	Erster CPU-Leerlauf (FCI)	13 %
Hauptthread	Maximale potenzielle erste Eingabelatenz	0 %

Einige wichtige Änderungen bei der Bewertung zwischen Lighthouse-Version 5 und 6:

• Der Wert für die TTI wurde von 33% auf 15%gesenkt. Dies war eine direkte Reaktion auf Nutzerfeedback zur TTI-Variabilität sowie auf Inkonsistenzen bei der Optimierung von Messwerten, die zu Verbesserungen bei der Nutzerfreundlichkeit führen. Die TTI ist weiterhin ein nützliches Signal dafür, ob eine Seite vollständig interaktiv ist. Mit der TBT als Ergänzung wird jedoch die Variabilität reduziert. Wir hoffen, dass Entwickler durch diese Änderung der Bewertung noch stärker dazu angeregt werden, ihre Apps für die Nutzerinteraktivität zu optimieren.
• Der Wert für „Funktionale Anforderungen“ wurde von 23% auf 15 % reduziert. Die Messung nur zum Zeitpunkt des ersten gerenderten Pixels (First Contentful Paint, FCP) gab uns kein vollständiges Bild. Wenn Sie die Ladezeit mit der Messung kombinieren, wann Nutzer die Inhalte sehen, die sie am wahrscheinlichsten interessieren (LCP), wird das Ladeerlebnis besser abgebildet.
• Die Messwerte „Maximale potenzielle erste Eingabelatenz“ wurden eingestellt. Sie wird nicht mehr im Bericht angezeigt, ist aber weiterhin im JSON-Format verfügbar. Wir empfehlen jetzt, anstelle von mpFID den TBT zu verwenden, um die Interaktivität zu quantifizieren.
• Der Messwert „Inhalte weitgehend gezeichnet“ wurde eingestellt. Dieser Messwert war zu variabel und konnte nicht standardisiert werden, da die Implementierung auf die internen Chrome-Rendering-Funktionen zugeschnitten ist. Einige Teams finden das FMP-Timing auf ihrer Website zwar sinnvoll, der Messwert wird aber nicht weiter optimiert.
• Der Messwert „Erster CPU-Leerlauf“ wurde eingestellt, da er sich nicht deutlich genug vom TTI unterscheidet. TBT und TTI sind die wichtigsten Messwerte für Interaktivität.
• Das Gewicht von CLS ist relativ niedrig, wird aber in einer zukünftigen Hauptversion voraussichtlich erhöht.

Änderungen der Bewertungen

Wie wirken sich diese Änderungen auf die Bewertungen echter Websites aus? Wir haben eine Analyse der Bewertungsänderungen mit zwei Datensätzen veröffentlicht: einem allgemeinen Satz von Websites und einem Satz von statischen Websites, die mit Eleventy erstellt wurden. Zusammenfassend lässt sich sagen, dass bei etwa 20% der Websites die Bewertung deutlich gestiegen ist, bei etwa 30% kaum eine Veränderung zu verzeichnen ist und bei etwa 50% ein Rückgang von mindestens fünf Punkten zu verzeichnen ist.

Die Änderungen der Bewertung können in drei Hauptkomponenten unterteilt werden:

• Gewichtung von Bewertungen ändern
• Fehlerkorrekturen bei den zugrunde liegenden Messwertimplementierungen
• Änderungen an der individuellen Bewertungskurve

Die meisten Änderungen am Gesamtergebnis sind auf Änderungen der Gewichtung und die Einführung von drei neuen Messwerten zurückzuführen. Neue Messwerte, die Entwickler noch nicht optimiert haben, tragen in Version 6 einen erheblichen Teil zum Leistungsbewertungsfaktor bei. Während die durchschnittliche Leistung des Testkorpus in Version 5 bei etwa 50 lag, betrugen die durchschnittlichen Werte für die neuen Messwerte „Gesamte Blockierungszeit“ und „Largest Contentful Paint“ etwa 30. Zusammen machen diese beiden Messwerte 50% der Gewichtung in der Leistungsbewertung von Lighthouse Version 6 aus. Daher ist es nicht verwunderlich, dass bei einem großen Prozentsatz der Websites die Leistung gesunken ist.

Fehlerkorrekturen an der zugrunde liegenden Messwertberechnung können zu unterschiedlichen Bewertungen führen. Das betrifft relativ wenige Websites, kann aber in bestimmten Situationen erhebliche Auswirkungen haben. Insgesamt haben sich die Bewertungen für etwa 8% der Websites aufgrund von Änderungen bei der Implementierung von Messwerten verbessert. Bei etwa 4% der Websites ist die Bewertung aufgrund von Änderungen bei der Implementierung von Messwerten gesunken. Etwa 88% der Websites waren von diesen Fehlerkorrekturen nicht betroffen.

Auch Änderungen an einzelnen Bewertungskurven haben sich, wenn auch nur geringfügig, auf die Gesamtbewertung ausgewirkt. Wir prüfen regelmäßig, ob die Bewertungskurve mit den beobachteten Messwerten im HTTPArchive-Dataset übereinstimmt. Wenn wir Websites ausschließen, die von größeren Implementierungsänderungen betroffen waren, haben geringfügige Anpassungen an der Bewertungskurve für einzelne Messwerte die Bewertungen von etwa 3% der Websites verbessert und die Bewertungen von etwa 4% der Websites verschlechtert. Etwa 93% der Websites waren von dieser Änderung nicht betroffen.

Bewertungsrechner

Wir haben einen Berechnungstool veröffentlicht, mit dem Sie die Leistungsbewertung besser nachvollziehen können. Außerdem können Sie damit die Bewertungen von Lighthouse-Version 5 und 6 vergleichen. Wenn Sie eine Analyse mit Lighthouse 6.0 ausführen, enthält der Bericht einen Link zum Rechner, in dem Ihre Ergebnisse enthalten sind.

Neue Audits

Nicht verwendetes JavaScript

Wir nutzen die Codeabdeckung in den DevTools in einer neuen Prüfung: Nicht verwendetes JavaScript.

Diese Prüfung ist nicht ganz neu: Sie wurde Mitte 2017 hinzugefügt, aber aufgrund des Leistungsaufwands standardmäßig deaktiviert, um Lighthouse so schnell wie möglich zu halten. Die Erhebung dieser Abdeckungsdaten ist jetzt viel effizienter, sodass wir sie standardmäßig aktivieren können.

Barrierefreiheitsprüfungen

Lighthouse verwendet die hervorragende axe-core-Bibliothek für die Kategorie „Barrierefreiheit“. In Lighthouse 6.0 wurden die folgenden Prüfungen hinzugefügt:

• aria-hidden-body
• aria-hidden-focus
• aria-input-field-name
• aria-toggle-field-name
• form-field-multiple-labels
• heading-order
• duplicate-id-active
• duplicate-id-aria

Maskierbares Symbol

Maskierbare Symbole sind ein neues Symbolformat, mit dem Symbole für Ihre PWA auf allen Arten von Geräten gut aussehen. Damit Ihre PWA möglichst gut aussieht, haben wir eine neue Prüfung eingeführt, mit der Sie feststellen können, ob Ihre manifest.json dieses neue Format unterstützt.

Charset-Deklaration

Das Meta-Element „charset“ gibt an, welche Zeichencodierung zum Interpretieren eines HTML-Dokuments verwendet werden soll. Wenn dieses Element fehlt oder erst spät im Dokument deklariert wird, verwenden Browser eine Reihe von Heuristiken, um zu erraten, welche Codierung verwendet werden soll. Wenn ein Browser eine falsche Vermutung anstellt und ein spätes Meta-Zeichensatzelement gefunden wird, verwirft der Parser in der Regel die gesamte bisherige Arbeit und beginnt von vorn. Das führt zu einer schlechten Nutzererfahrung. Bei dieser neuen Prüfung wird überprüft, ob die Seite eine gültige Zeichencodierung hat und diese frühzeitig und vorab definiert wurde.

Lighthouse CI

Letzten November auf der CDS haben wir Lighthouse CI angekündigt, die Open-Source-Node-Befehlszeile und den Server, die Lighthouse-Ergebnisse für jeden Commit in Ihrer Continuous-Integration-Pipeline erfassen. Seit der Alphaversion haben wir große Fortschritte gemacht. Lighthouse CI unterstützt jetzt zahlreiche CI-Anbieter, darunter Travis, Circle, GitLab und GitHub Actions. Dank der Docker-Images, die sofort bereitgestellt werden können, ist die Einrichtung ganz einfach. Durch das umfassende Dashboard-Redesign lassen sich jetzt Trends in allen Kategorien und Messwerten in Lighthouse für eine detaillierte Analyse abrufen.

Mit unserem Einstiegsleitfaden können Sie Lighthouse CI noch heute in Ihrem Projekt verwenden.

Der Bereich „Chrome-Entwicklertools“ wurde umbenannt

Wir haben den Bereich Audits in Lighthouse umbenannt. Mehr muss man dazu nicht sagen.

Je nach Größe des DevTools-Fensters befindet sich das Steuerfeld wahrscheinlich hinter der Schaltfläche ». Sie können den Tab ziehen, um die Reihenfolge zu ändern.

So öffnen Sie schnell den Bereich mit dem Befehlsmenü:

1. Drücken Sie „Strg + Umschalttaste + J“ (oder „Befehlstaste + Optionstaste + J“ auf einem Mac), um die Entwicklertools zu öffnen.
2. Drücken Sie Control+Shift+P (oder Command+Shift+P auf einem Mac), um das Menü Befehl zu öffnen.
3. Geben Sie „Lighthouse“ ein.
4. Drücken Sie Enter.

Mobilemulation

Lighthouse folgt dem Mobile-first-Ansatz. Leistungsprobleme sind unter typischen mobilen Bedingungen deutlicher, aber Entwickler führen oft keine Tests unter diesen Bedingungen durch. Daher wird in der Standardkonfiguration in Lighthouse die Mobilemulation angewendet. Die Emulation besteht aus:

• Simulierte langsame Netzwerk- und CPU-Bedingungen (über eine Simulations-Engine namens Lantern)
• Gerätebildschirmemulation (wie in den Chrome-Entwicklertools)

Seit Beginn wird in Lighthouse das Nexus 5X als Referenzgerät verwendet. In den letzten Jahren haben die meisten Leistungsingenieure das Moto G4 zu Testzwecken verwendet. Jetzt folgt Lighthouse diesem Beispiel und hat das Referenzgerät auf das Moto G4 umgestellt. In der Praxis ist diese Änderung kaum wahrnehmbar. Hier sind alle Änderungen, die von einer Webseite erkannt werden können:

• Die Bildschirmgröße wurde von 412 x 660 Pixel auf 360 x 640 Pixel geändert.
• Der User-Agent-String wird leicht geändert. Der Geräteteil, der zuvor Nexus 5 Build/MRA58N war, lautet jetzt Moto G (4).

Ab Chrome 81 ist das Moto G4 auch in der Liste der Geräteemulation in den Chrome-Entwicklertools verfügbar.

Browsererweiterung

Die Chrome-Erweiterung für Lighthouse war eine praktische Möglichkeit, Lighthouse lokal auszuführen. Leider war es schwierig, den Support zu kontaktieren. Da das Lighthouse-Steuerfeld in den Chrome DevTools eine bessere Nutzererfahrung bietet (der Bericht wird in andere Steuerfelder eingebunden), konnten wir den Entwicklungsaufwand reduzieren, indem wir die Chrome-Erweiterung vereinfachten.

Anstatt Lighthouse lokal auszuführen, verwendet die Erweiterung jetzt die PageSpeed Insights API. Uns ist bewusst, dass dies für einige Nutzer nicht ausreichend ist. Die wichtigsten Unterschiede:

• PageSpeed Insights kann keine nicht öffentlichen Websites prüfen, da es über einen Remote-Server und nicht über Ihre lokale Chrome-Instanz ausgeführt wird. Wenn Sie eine nicht öffentliche Website prüfen möchten, verwenden Sie das Lighthouse-Steuerfeld in den DevTools oder die Node-Befehlszeile.
• Es ist nicht garantiert, dass in PageSpeed Insights die neueste Lighthouse-Version verwendet wird. Wenn Sie die neueste Version verwenden möchten, verwenden Sie die Node-Befehlszeile. Die Browsererweiterung wird etwa 1–2 Wochen nach der Veröffentlichung aktualisiert.
• PageSpeed Insights ist eine Google API. Wenn Sie sie verwenden, stimmen Sie den Nutzungsbedingungen für Google APIs zu. Wenn Sie die Nutzungsbedingungen nicht akzeptieren möchten oder können, verwenden Sie das Lighthouse-Steuerfeld in den DevTools oder die Node-Befehlszeile.

Die gute Nachricht ist, dass wir uns durch die Vereinfachung der Produktgeschichte auf andere technische Probleme konzentrieren konnten. Deshalb haben wir die Lighthouse-Firefox-Erweiterung veröffentlicht.

Budgets

In Lighthouse 5.0 wurden Leistungsbudgets eingeführt, mit denen Sie Grenzwerte für die Auslieferungsmenge von Ressourcentypen wie Scripts, Bildern oder CSS-Code festlegen können.

Lighthouse 6.0 unterstützt jetzt Budgetmesswerte. Sie können also jetzt Grenzwerte für bestimmte Messwerte wie den FCP festlegen. Derzeit sind Budgets nur für die Node-Befehlszeile und Lighthouse CI verfügbar.

Links zum Quellort

Einige der von Lighthouse auf einer Seite gefundenen Probleme können auf eine bestimmte Zeile im Quellcode zurückgeführt werden. Im Bericht werden die genaue Datei und die relevante Zeile angegeben. Damit Sie die Daten in den DevTools leichter untersuchen können, werden die entsprechenden Dateien im Bereich Quellen geöffnet, wenn Sie auf die im Bericht angegebenen Speicherorte klicken.

Auf dem Programm

Lighthouse testet derzeit die Erhebung von Quellkarten, um neue Funktionen zu ermöglichen, z. B.:

• In JavaScript-Bundles doppelt vorhandene Module werden erkannt.
• Erkennen übermäßiger Polyfills oder Transformationen in Code, der an moderne Browser gesendet wird.
• Die Prüfung auf nicht verwendetes JavaScript wurde um eine Detaillierung auf Modulebene erweitert.
• Treemap-Visualisierungen, in denen die Module hervorgehoben werden, bei denen Maßnahmen erforderlich sind.
• Der ursprüngliche Quellcode für Berichtselemente mit einem „Quellspeicherort“ wird angezeigt.

Diese Funktionen werden in einer zukünftigen Version von Lighthouse standardmäßig aktiviert. Derzeit können Sie die experimentellen Prüfungen von Lighthouse mit dem folgenden Befehlszeilen-Flag aufrufen:

lighthouse https://web.dev --view --preset experimental

Vielen Dank!

Vielen Dank, dass Sie Lighthouse verwenden und uns Feedback geben. Ihr Feedback hilft uns, Lighthouse zu verbessern. Wir hoffen, dass Sie mit Lighthouse 6.0 die Leistung Ihrer Websites noch einfacher verbessern können.

Was können Sie jetzt tun?

• Öffnen Sie Chrome Canary und testen Sie das Lighthouse-Steuerfeld.
• Verwenden Sie die Node-Befehlszeile: npm install -g lighthouse && lighthouse https://yoursite.com --view.
• Lighthouse CI für Ihr Projekt einrichten
• Lesen Sie die Dokumentation zur Lighthouse-Analyse.
• Viel Spaß beim Verbessern des Webs!

Wir lieben das Web und arbeiten gerne mit der Entwickler-Community zusammen, um Tools zu entwickeln, die das Web verbessern. Lighthouse ist ein Open-Source-Projekt. Wir möchten uns ganz herzlich bei allen Mitwirkenden bedanken, die uns bei der Behebung von Tippfehlern, der Umstrukturierung der Dokumentation und der Entwicklung neuer Prüfungen unterstützt haben. Möchten Sie einen Beitrag leisten? Sehen Sie sich das Lighthouse-GitHub-Repository an.