Neu in Lighthouse 6.0

Neue Messwerte, aktualisierte Leistungsbewertung, neue Prüfungen und mehr.

Connor Clark

Heute veröffentlichen wir Lighthouse 6.0.

Lighthouse ist ein automatisiertes Tool zur Prüfung von Websites, das Entwicklern Möglichkeiten und Diagnosen zur Verfügung stellt, mit denen sie die Nutzerfreundlichkeit ihrer Websites verbessern können. Der Dienst ist in den Chrome-Entwicklertools, in npm (als Knotenmodul und Befehlszeile) oder als Browsererweiterung (in Chrome und Firefox) verfügbar. Es wird für viele Google-Dienste wie web.dev/measure und PageSpeed Insights eingesetzt.

Lighthouse 6.0 ist sofort für 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 der stabilen Chrome-Version 84 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 zahlreiche Änderungen, die im Änderungsprotokoll 6.0 aufgeführt sind. Die wichtigsten Punkte finden Sie in diesem Artikel.

• Neue Messwerte
• Update: Leistungsbewertung
• Neue Prüfungen
• Lighthouse CI
• Umbenannter Bereich für Chrome-Entwicklertools
• Mobile Emulation
• Browsererweiterung
• Budgets
• Links zu Quellstandorten
• am Horizont
• Vielen Dank

Neue Messwerte

In Lighthouse 6.0 wurden drei neue Messwerte für den Bericht eingeführt. Zwei dieser neuen Messwerte – Largest Contentful Paint (LCP) und Cumulative Layout Shift (CLS) – sind Lab-Implementierungen von Core Web Vitals.

Largest Contentful Paint (LCP)

Der Largest Contentful Paint (LCP) ist ein Maß für die wahrgenommene Ladeerfahrung. Sie kennzeichnet den Punkt beim Seitenaufbau, an dem der primäre oder „größte“ Inhalt geladen wurde und für den Nutzer sichtbar ist. LCP ist eine wichtige Ergänzung zu First Contentful Paint (FCP), mit dem nur der Anfang des Ladevorgangs erfasst wird. Der LCP zeigt Entwicklern, wie schnell ein Nutzer den Inhalt einer Seite tatsächlich sehen kann. Ein LCP-Wert unter 2,5 Sekunden wird als „Gut“ betrachtet.

Weitere Informationen erhalten Sie in dieser detaillierten Analyse zum LCP von Paul Irish.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) ist ein Maß für die visuelle Stabilität. Sie gibt an, wie sehr sich der Inhalt einer Seite visuell verändert. Ein niedriger CLS-Wert ist ein Hinweis für Entwickler, dass es bei ihren Nutzern keine unzulässigen Inhaltsänderungen gibt.Ein CLS-Wert unter 0,10 wird als „Gut“ betrachtet.

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

Weitere Informationen erhalten Sie in dieser ausführlichen CLS-Präsentation von Annie Sullivan.

Total Blocking Time (TBT)

Die Total Blocking Time (TBT) quantifiziert die Reaktionszeit beim Laden. Sie misst die Gesamtzeit, in der der Hauptthread lange genug blockiert wurde, um eine Reaktionsfähigkeit von Eingaben zu verhindern. TBT misst die Gesamtzeit zwischen dem First Contentful Paint (FCP) und der Zeit bis zur Interaktivität (Time to Interactive, TTI). Dieser Messwert gehört zu TTI und bietet eine differenziertere Quantifizierung der Hauptthreadaktivität, sodass Nutzer nicht mehr mit Ihrer Seite interagieren können.

Darüber hinaus korreliert TBT gut mit dem Feldmesswert First Input Delay (FID), der ein Core Web Vital ist.

Aktualisierung des Leistungswerts

Die Leistungsbewertung in Lighthouse wird aus einer gewichteten Mischung mehrerer Messwerte berechnet, um die Geschwindigkeit einer Seite zusammenzufassen. Es folgt die Formel für den Leistungswert von 6.0.

Phase	Name des Messwerts	Messwertgewichtung
Früher (15%)	First Contentful Paint (FCP)	15 %
Mittel (40%)	Geschwindigkeitsindex (SI)	15 %
	Largest Contentful Paint (LCP)	25 %
Zu spät (15%)	Zeit bis Interaktivität (Zeit bis Interaktivität)	15 %
Hauptthread (25%)	Total Blocking Time (TBT)	25 %
Vorhersehbarkeit (5%)	Cumulative Layout Shift (CLS)	5 %

Es wurden drei neue Messwerte hinzugefügt, aber drei alte Messwerte wurden entfernt: „First Meaningful Paint“, „First CPU Idle“ und „Max Potential FID“. Die Gewichtungen der verbleibenden Messwerte wurden geändert, um die Interaktivität des Hauptthreads und die Planbarkeit des Layouts hervorzuheben.

Hier ist zum Vergleich die Bewertung von Version 5:

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

Hier einige Highlights der Bewertungsänderungen zwischen den Lighthouse-Versionen 5 und 6:

• Die Gewichtung von TTI wurde von 33% auf 15%reduziert. Dies war eine direkte Reaktion auf Nutzerfeedback zur TTI-Variabilität sowie auf Inkonsistenzen bei Messwertoptimierungen, die zu einer Verbesserung der Nutzererfahrung führten. TTI ist immer noch ein nützliches Signal für den Fall, dass eine Seite vollständig interaktiv ist. Mit TBT als Ergänzung wird die Variabilität reduziert. Durch diese Änderung der Punktzahl hoffen wir, dass Entwickler effektiver dazu ermutigt werden können, die Nutzerinteraktivität zu optimieren.
• Die Gewichtung von FCP wurde von 23% auf 15 % reduziert. Nur wenn das erste Pixel gemalt wird (FCP), ergab sich kein vollständiges Bild. Die Kombination mit LCP und Messung, bei der Nutzer sehen können, was ihnen höchstwahrscheinlich wichtig ist, spiegelt die Ladegeschwindigkeit besser wider.
• Der Wert Max. potenzielle FID wurde eingestellt. Sie wird nicht mehr im Bericht angezeigt, ist aber weiterhin in der JSON-Datei verfügbar. Es wird empfohlen, die Interaktivität anhand von TBT anstelle von mpFID zu quantifizieren.
• „First Meaningful Paint“ wurde eingestellt. Dieser Messwert war zu stark variiert und konnte nicht standardisiert werden, da die Implementierung spezifisch für das Rendering von Chrome ist. Auch wenn sich das FMP-Timing auf ihrer Website für einige Teams lohnt, wird der Messwert nicht weiter verbessert.
• Der erste CPU-Leerlauf wurde eingestellt, da er sich nicht ausreichend von TTI unterscheidet. TBT und TTI sind jetzt die wichtigsten Messwerte für Interaktivität.
• Die CLS-Gewichtung ist relativ gering, wir erwarten jedoch, sie in einer zukünftigen Hauptversion zu erhöhen.

Änderungen bei Punktzahlen

Wie wirken sich diese Änderungen auf die Bewertungen echter Websites aus? Wir haben eine Analyse der Punktzahländerungen mit zwei Datasets veröffentlicht: einer allgemeinen Reihe von Websites und einer Reihe von statischen Websites, die mit Eleventy erstellt wurden. Zusammenfassend lässt sich sagen, dass ca. 20% der Websites deutlich höhere Bewertungen erzielen, bei ca. 30% kaum Änderungen auftreten und bei ca. 50% sinkt die Punktzahl um mindestens fünf Punkte.

Die Bewertungsänderungen lassen sich in drei Hauptkomponenten unterteilen:

• Gewichtsänderungen bewerten
• Fehlerkorrekturen bei zugrunde liegenden Messwertimplementierungen
• Änderungen der Bewertungskurve

Die Änderungen der Gewichtung der Punktzahl und die Einführung von drei neuen Messwerten führten zu einem Großteil der Änderungen der Gesamtpunktzahl. Neue Messwerte, die von Entwicklern noch optimiert werden müssen, haben bei der Leistungsbewertung von Version 6 eine große Bedeutung. Während die durchschnittliche Leistungsbewertung des Testkorpus in Version 5 bei etwa 50 lag, lag die durchschnittliche Punktzahl für die neuen Messwerte „Total Blocking Time“ und „Largest Contentful Paint“ bei 30. Zusammen machen diese beiden Messwerte 50% der Gewichtung der Lighthouse-Version 6 aus, daher gab es für einen Großteil der Websites Rückgänge.

Fehlerkorrekturen an der zugrunde liegenden Messwertberechnung können zu unterschiedlichen Punktzahlen führen. Dies betrifft relativ wenige Websites, kann aber in bestimmten Situationen erhebliche Auswirkungen haben. Insgesamt verzeichneten etwa 8% der Websites eine Verbesserung der Bewertung aufgrund von Änderungen an der Messwertimplementierung und etwa 4% der Websites eine Verringerung der Bewertung aufgrund von Änderungen bei der Implementierung von Messwerten. Etwa 88% der Websites waren von diesen Korrekturen nicht betroffen.

Änderungen der einzelnen Bewertungskurven wirkten sich ebenfalls auf die Verschiebungen der Gesamtpunktzahl aus, wenn auch nur sehr geringfügig. Wir prüfen regelmäßig, ob die Punktzahlkurve mit den beobachteten Messwerten im HTTPArchive-Dataset übereinstimmt. Mit Ausnahme der Websites, die von größeren Implementierungsänderungen betroffen waren, verbesserten sich geringfügige Anpassungen der Bewertungskurve für einzelne Messwerte die Bewertungen von etwa 3% der Websites und verringerten sie um etwa 4 %. Etwa 93% der Websites waren von dieser Änderung nicht betroffen.

Punkterechner

Wir haben einen Scoring-Rechner veröffentlicht, mit dem Sie die Leistungsbewertung untersuchen können. Mit dem Rechner können Sie außerdem die Punktzahlen von Lighthouse Version 5 und Version 6 vergleichen. Wenn Sie ein Audit mit Lighthouse 6.0 durchführen, enthält der Bericht einen Link zum Rechner mit Ihren Ergebnissen.

Ein großes Dankeschön an Ana Tudor für das Upgrade der Messgerät!

Neue Prüfungen

Nicht verwendetes JavaScript

Wir nutzen die Codeabdeckung der Entwicklertools in einer neuen Prüfung: Unused JavaScript.

Diese Prüfung ist nicht ganz neu: Sie wurde Mitte 2017 hinzugefügt. Aufgrund des Leistungsaufwands wurde sie jedoch standardmäßig deaktiviert, damit Lighthouse so schnell wie möglich bleibt. Das Erfassen dieser Abdeckungsdaten ist jetzt wesentlich effizienter und kann daher standardmäßig aktiviert werden.

Prüfung der Barrierefreiheit

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

• aria-hidden-body
• aria-ausgeblendeter-fokus
• aria-input-field-name
• aria-toggle-field-name
• form-field-multiple-labels
• heading-order
• Duplicate-id-active
• Duplicate-id-aria

Maskierbares Symbol

Maskierbare Symbole ist ein neues Symbolformat, mit dem Symbole für Ihre PWA auf allen Arten von Geräten gut aussehen. Damit deine PWA so gut wie möglich aussieht, haben wir eine neue Prüfung eingeführt, um zu prüfen, ob deine Datei „manifest.json“ dieses neue Format unterstützt.

Charset-Deklaration

Mit dem Meta-Zeichensatzelement wird angegeben, welche Zeichencodierung zum Interpretieren eines HTML-Dokuments verwendet werden soll. Wenn dieses Element fehlt oder spät im Dokument deklariert wird, verwenden Browser eine Reihe von Heuristiken, um zu schätzen, welche Codierung verwendet werden soll. Wenn ein Browser falsch rät und ein spätes Meta-Zeichensatzelement gefunden wird, verwirft der Parser in der Regel die gesamte bisher geleistete Arbeit und beginnt von vorn, was zu einer schlechten Nutzererfahrung führt. Bei dieser neuen Prüfung wird bestätigt, dass die Seite eine gültige Zeichencodierung hat und frühzeitig und im Voraus definiert wurde.

Lighthouse CI

Letzten November haben wir auf der CDS Lighthouse CI vorgestellt, die Open-Source-Knoten-Befehlszeile und -Server, die Lighthouse-Ergebnisse bei jedem Commit in Ihrer Continuous-Integration-Pipeline verfolgt. Seit der Alpha-Version haben wir einen langen Weg zurückgelegt. Lighthouse CI unterstützt jetzt zahlreiche CI-Anbieter, einschließlich Travis, Circle, GitLab und GitHub Actions. Sofort einsatzbereite Docker-Images machen die Einrichtung zum Kinderspiel und ein umfassendes, neu gestaltetes Dashboard zeigt Trends in allen Kategorien und Messwerten in Lighthouse für eine detaillierte Analyse auf.

Beginnen Sie noch heute mit der Nutzung von Lighthouse CI für Ihr Projekt. Folgen Sie dazu unserem Startleitfaden.

Umbenannter Bereich für Chrome-Entwicklertools

Der Bereich Audits wurde in Lighthouse umbenannt. Genug gesagt!

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

So blenden Sie den Bereich über das Befehlsmenü schnell ein:

1. Drücken Sie Strg + Umschalttaste + J (oder Befehlstaste + Option + J auf dem 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. Beginnen Sie mit der Eingabe von „Leuchtturm“.
4. Drücken Sie Enter.

Mobile Emulation

Lighthouse richtet sich nach dem Mobile-First-Ansatz. Leistungsprobleme sind unter typischen Bedingungen für Mobilgeräte offensichtlicher, aber Entwickler führen unter diesen Bedingungen häufig keine Tests durch. Aus diesem Grund wird bei der Standardkonfiguration in Lighthouse die Mobile Emulation angewendet. Die Emulation umfasst Folgendes:

• Simulierte langsame Netzwerk- und CPU-Bedingungen (über eine Simulations-Engine namens Lantern).
• Bildschirmemulation des Geräts (wie in den Chrome-Entwicklertools verfügbar)

Von Anfang an wurde das Nexus 5X von Lighthouse als Referenzgerät genutzt. In den letzten Jahren haben die meisten Performance Engineers das Moto G4 zu Testzwecken verwendet. Jetzt folgt Lighthouse diesem Beispiel und hat sein Referenzgerät in Moto G4 geändert. In der Praxis ist diese Änderung nicht besonders auffällig, aber hier sind alle Änderungen, die von einer Webseite erkannt werden:

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

Ab Chrome 81 ist Moto G4 auch in der Chrome-Entwicklertools-Emulationsliste verfügbar.

Browsererweiterung

Die Chrome-Erweiterung für Lighthouse ist eine bequeme Möglichkeit, Lighthouse lokal auszuführen. Leider war der Support kompliziert. Wir waren der Meinung, dass der Lighthouse-Bereich der Chrome-Entwicklertools nutzerfreundlicher ist (der Bericht lässt sich in andere Bereiche integrieren), sodass wir unseren technischen Aufwand reduzieren könnten, indem wir die Chrome-Erweiterung vereinfachten.

Anstelle der lokalen Ausführung von Lighthouse verwendet die Erweiterung jetzt die PageSpeed Insights API. Uns ist bewusst, dass dies für einige unserer Nutzer kein ausreichender Ersatz ist. Dies sind die wichtigsten Unterschiede:

• Mit PageSpeed Insights können nicht öffentliche Websites nicht überprüft werden, da sie über einen Remote-Server und nicht über Ihre lokale Chrome-Instanz ausgeführt werden. Wenn Sie eine nicht öffentliche Website prüfen müssen, verwenden Sie das Lighthouse-Steuerfeld der Entwicklertools oder die Node-Befehlszeile.
• Es kann nicht garantiert werden, dass PageSpeed Insights die neueste Lighthouse-Version verwendet. Wenn Sie den neuesten Release verwenden möchten, verwenden Sie die Node-Befehlszeile. Die Browsererweiterung erhält das Update etwa 1 bis 2 Wochen nach der Veröffentlichung.
• PageSpeed Insights ist eine Google API. Ihre Nutzung bedeutet, dass Sie die Google API-Nutzungsbedingungen akzeptieren. Wenn Sie die Nutzungsbedingungen nicht akzeptieren möchten oder können, verwenden Sie in den Entwicklertools das Steuerfeld Lighthouse oder die Node-Befehlszeile.

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

Budgets

Mit Lighthouse 5.0 wurden Leistungsbudgets eingeführt, die das Hinzufügen von Grenzwerten für den Umfang jedes Ressourcentyps (z. B. Skripts, Bilder oder CSS) unterstützt haben, der eine Seite bereitstellen kann.

Lighthouse 6.0 bietet Unterstützung für Budgetmesswerte, sodass Sie jetzt Schwellenwerte für bestimmte Messwerte wie FCP festlegen können. Derzeit sind Budgets nur für die Node CLI und Lighthouse CI verfügbar.

Links zu Quellorten

Einige der Probleme, die Lighthouse bei einer Seite findet, können auf eine bestimmte Quellcodezeile zurückgeführt werden. Der Bericht enthält dann die genaue Datei und Zeile, die relevant sind. Wenn Sie auf die im Bericht angegebenen Speicherorte klicken, werden die entsprechenden Dateien im Bereich Quellen geöffnet. Dies vereinfacht die Untersuchung in den Entwicklertools.

Die Entwicklertools zeigen die genaue Codezeile an, die das Problem verursacht.

Am Horizont

Lighthouse hat damit begonnen, mit der Erfassung von Quellkarten zu experimentieren, um neue Funktionen zu unterstützen. Dazu gehören:

• Doppelte Module in JavaScript-Bundles werden erkannt.
• Erkennung übermäßig vieler Polyfills oder Transformationen in Code, der an moderne Browser gesendet wird.
• Erweiterung der Prüfung für nicht verwendete JavaScript-Elemente für einen Detaillierungsgrad auf Modulebene.
• Strukturkartenvisualisierungen, in denen die Module hervorgehoben sind, die bearbeitet werden müssen.
• Anzeige des ursprünglichen Quellcodes für Berichtselemente mit einem „Quellort“

Die Prüfung von nicht verwendetem JavaScript mithilfe von Quellzuordnungen, um nicht verwendeten Code in bestimmten gebündelten Modulen zu zeigen.

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

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, und wir hoffen, dass Sie mit Lighthouse 6.0 die Leistung Ihrer Websites einfacher verbessern können.

Was können Sie jetzt tun?

• Öffnen Sie Chrome Canary und testen Sie das Steuerfeld Lighthouse.
• Verwenden Sie die Node-Befehlszeile: npm install -g lighthouse && lighthouse https://yoursite.com --view.
• Lassen Sie Lighthouse CI mit Ihrem Projekt ausführen.
• Lesen Sie die Lighthouse-Audit-Dokumentation.
• Viel Spaß bei der Verbesserung des Webs!

Das Web ist uns sehr wichtig und wir lieben es, mit der Entwickler-Community zusammenzuarbeiten, um Tools zur Verbesserung des Webs zu entwickeln. Lighthouse ist ein Open-Source-Projekt. Vielen Dank an alle Mitwirkenden, die uns bei allen wichtigen Dingen – von Tippfehlern über die Refaktorierung der Dokumentation bis hin zu komplett neuen Audits – helfen. Möchtest du einen Beitrag leisten? Am Lighthouse-GitHub-Repository vorbeischauen