Neu in Lighthouse 6.0

Neue Messwerte, Aktualisierung der Leistungsbewertung, neue Prüfungen und mehr.

Connor Clark
Connor Clark

Heute veröffentlichen wir Lighthouse 6.0.

Lighthouse ist ein automatisiertes Tool zur Website-Prüfung, bietet Entwicklern Möglichkeiten und Diagnosen, mit denen sie die Nutzerfreundlichkeit ihrer Websites verbessern können. Sie ist in den Chrome-Entwicklertools, npm (als Node-Modul und Kommandozeile) oder als Browsererweiterung (in Chrome und Firefox). Das Herzstück vieler Google-Produkte einschließlich web.dev/measure und PageSpeed Statistiken.

Lighthouse 6.0 ist ab sofort für npm und in Chrome Canary-Version Bei anderen Google-Diensten, die Lighthouse nutzen, erhalten Sie das Update bis zum Monatsende. Sie wird in Chrome 84 (Mitte Juli) in der stabilen Version verfügbar sein.

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

Diese Version von Lighthouse bringt eine Vielzahl von Änderungen mit sich, die im Änderungsprotokoll für Version 6.0 aufgeführt sind. Wir werden die Highlights in diesem Artikel.

Neue Messwerte

Messwerte in Lighthouse 6.0.

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

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) ist ein Maß für die wahrgenommene Belastung. Nutzererfahrung. Sie markiert den Punkt während des Seitenaufbaus, wenn der primäre – oder „größte“ – Content geladen wurde und für den Nutzer sichtbar ist. LCP ist eine wichtige Ergänzung zu First Contentful Paint (FCP), den Beginn des Ladevorgangs erfasst. LCP ist ein Signal für Entwickelnde, damit ein Nutzer den Inhalt einer Seite tatsächlich sehen kann. Ein LCP-Wert unter 2,5 Sekunden als "Gut" betrachtet wird.

Weitere Informationen erhalten Sie in dieser ausführlichen Analyse von LCP von Paul Irish.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) ist ein Maß für die visuelle Stabilität. Es gibt an, wie stark sich der Inhalt einer Seite visuell verändert. Ein niedriger CLS-Wert ist ein Signal dafür, Entwickler, dass ihre Nutzer keine unangemessenen Inhaltsänderungen erleben ist ein CLS-Wert unter 0,10 als "Gut" betrachtet wird.

In einer Lab-Umgebung wird der CLS-Wert bis zum Ende des Seitenaufbaus gemessen. Im Bereich können Sie dagegen bis zur ersten Nutzerinteraktion oder unter Einbeziehung aller Nutzereingaben.

Weitere Informationen erhalten Sie in dieser detaillierten Analyse der CLS von Annie Sullivan.

Gesamtblockierungszeit (TBT)

Die Total Blocking Time (TBT) quantifiziert die Reaktionsfähigkeit der Last und misst die Zeitraum, in dem der Hauptthread so lange blockiert war, dass keine Reaktionsfähigkeit bei der Eingabe verhindert wurde. TBT misst die Gesamtzeit zwischen First Contentful Paint (FCP) und der Zeit bis zur Interaktivität (TTI) Er ist ein Begleitmesswert zu TTI und bietet eine differenziertere Quantifizierung der Hauptthreadaktivität. verhindern, dass Nutzer mit Ihrer Seite interagieren können.

Außerdem korreliert TBT gut mit dem Feldmesswert First Input Delay. (FID), ein Core Web Vitals-Messwert.

Aktualisierung der Leistungsbewertung

Die Leistungsbewertung in Lighthouse wird anhand einer eine gewichtete Mischung aus mehreren Messwerten, um die Geschwindigkeit einer Seite zusammenzufassen. Die Formel für die 6.0-Leistungsbewertung folgt.

Phase Name des Messwerts Metrisches Gewicht
Früh (15%) First Contentful Paint (FCP) 15 %
Mittel (40%) Geschwindigkeitsindex (SI) 15 %
Largest Contentful Paint (LCP) 25 %
Verspätet (15%) Zeit bis Interaktivität (TTI) 15 %
Hauptthread (25%) Gesamtblockierungszeit (TBT) 25 %
Vorhersehbarkeit (5%) Cumulative Layout Shift (CLS) 5 %

Es wurden zwar drei neue Messwerte hinzugefügt, aber drei alte entfernt: "First Meaningful Paint", „Erster CPU-Leerlauf“ und maximale potenzielle FID. Die Gewichtung der verbleibenden Messwerte wurde geändert zu Interaktivität des Hauptthreads und Vorhersehbarkeit des Layouts betonen.

Hier ist zum Vergleich die Bewertung von Version 5:

Phase Name des Messwerts Gewicht
Zu früh (23%) First Contentful Paint (FCP) 23 %
Mittel (34%) Geschwindigkeitsindex (SI) 27 %
First Meaningful Paint (FMP) 7 %
Abgeschlossen (46%) Zeit bis Interaktivität (TTI) 33 %
Erster CPU-Leerlauf (FCI) 13 %
Hauptthread Maximaler potenzieller FID 0 %

Änderungen der Lighthouse-Bewertung zwischen Version 5 und 6.

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 Antwort an den Nutzer, Feedback zur Variabilität der TTI-Daten sowie Uneinheitlichkeiten bei der Messwertoptimierung, die zu die User Experience verbessert. Die TTI ist immer noch ein nützliches Signal dafür, dass eine Seite aber mit TBT als Komplement – die Variabilität verringert. Wir hoffen, dass Entwickler mit dieser Bewertungsänderung effektiver dazu ermutigt werden, die Nutzerinteraktion und -bindung.
  • Die Gewichtung von FCP wurde von 23% auf 15 % reduziert. Wird nur gemessen, wenn das erste Pixel gemalt (FCP) kein vollständiges Bild. Wenn Sie messen, wann Nutzende in der Lage sind, um zu sehen, was LCP am wahrscheinlichsten ist, um den Ladezustand besser widerzuspiegeln.
  • Max Potential FID wurde eingestellt. Er ist nicht mehr im Bericht zu sehen, immer noch im JSON-Format verfügbar. Es wird jetzt empfohlen, die Interaktivität anhand von TBT zu quantifizieren anstelle von mpFID.
  • „First Meaningful Paint“ wurde eingestellt. Dieser Messwert variierte zu und hatte keinen realisierbaren Wert Standardisierung, da die Implementierung spezifisch für das Chrome-Rendering ist. Während finden einige Teams das FMP-Timing auf ihrer Website lohnenswert, wird der Messwert zusätzliche Verbesserungen.
  • Der erste CPU-Leerlauf wurde verworfen, da er sich nicht ausreichend vom TTI unterscheidet. TBT und TTI sind mittlerweile die wichtigsten Metriken für Interaktivität.
  • Die CLS-Gewichtung ist relativ gering, obwohl wir erwarten, sie in einer zukünftigen Hauptversion zu erhöhen.

Verschiebungen bei Punktzahlen

Wie wirken sich diese Änderungen auf den Wert echter Websites aus? Wir haben eine Analyse der Wertänderungen unter Verwendung von zwei Datasets: ein allgemeiner Satz von Websites und ein Gruppe statischer Websites von Eleventy. Zusammenfassend lässt sich sagen, dass ca. 20% der Websites eine deutlich höhere bei ~30% kaum und bei ~50% ein Rückgang um mindestens fünf Punkte.

Die Bewertungsänderungen lassen sich in drei Hauptkomponenten unterteilen:

  • Gewichtsänderungen des Punktestands
  • Fehlerkorrekturen bei zugrunde liegenden Messwertimplementierungen
  • Änderungen der individuellen Punktzahlkurve

Änderungen der Bewertung und die Einführung von drei neuen Messwerten machten den Großteil der Gesamtbewertung aus. Änderungen. Neue Messwerte, die die Entwickler noch optimieren müssen, haben in Version 6 eine erhebliche Gewichtung. die Leistungskennzahl. Während die durchschnittliche Leistungspunktzahl des Testkorpus in Version 5 bei etwa 50 lag, lagen die durchschnittlichen Punktzahlen bei den neuen Messwerten „Total Blocking Time“ und „Largest Contentful Paint“ bei etwa 30. Diese beiden Messwerte machen zusammen 50% der Gewichtung der Leistungsbewertung von Lighthouse Version 6 aus, sodass bei einem großen Prozentsatz der Websites ein Rückgang verzeichnet wird.

Fehlerkorrekturen bei der zugrunde liegenden Messwertberechnung können zu unterschiedlichen Bewertungen führen. Dies betrifft relativ wenige Websites, kann aber in bestimmten Situationen erhebliche Auswirkungen haben. Insgesamt haben etwa 8% der Websites aufgrund von Änderungen bei der Messwertimplementierung eine Verbesserung des Werts verzeichnen. Etwa 4 Prozent der Websites erzielten eine Bewertung. aufgrund von Änderungen bei der Messwertimplementierung. Rund 88% der Websites waren von diesen Korrekturen nicht betroffen.

Änderungen der individuellen Punktzahlkurven wirkten sich ebenfalls auf die Verschiebungen der Gesamtpunktzahl aus, wenn auch nur geringfügig. Mi. Sie stellen regelmäßig sicher, dass die Bewertungskurve mit den beobachteten Messwerten im HTTPArchive übereinstimmt. Dataset. Ausschließen von Websites, die von geringfügigen Änderungen bei der Implementierung betroffen sind Anpassungen an der Bewertungskurve für einzelne Messwerte verbesserten die Bewertungen von etwa 3 Prozent der Websites und sank die Punktzahl von etwa 4% der Websites. Ungefähr 93% der Websites waren von dieser Änderung nicht betroffen.

Punkterechner

Wir haben für Sie einen Bewertungsrechner veröffentlicht, geht es um die Leistungsbewertung. Der Rechner ermöglicht auch einen Vergleich zwischen Lighthouse Version 5 und 6 Punkte. Wenn Sie eine Prüfung mit Lighthouse 6.0 durchführen, enthält der Bericht einen Link zum Rechner. mit Ihren Ergebnissen.

<ph type="x-smartling-placeholder">
</ph> Lighthouse-Score-Rechner
Ein großes Dankeschön an Ana Tudor für die Verbesserung der Anzeige!

Neue Prüfungen

Nicht verwendetes JavaScript

Wir nutzen DevTools-Code, Abdeckung in einer neuen Prüfung: Nicht verwendet JavaScript

Diese Prüfung ist nicht vollständig neu: Sie wurde hinzugefügt in Mitte 2017, aber Aufgrund des Leistungs-Overheads war es standardmäßig deaktiviert, um die Lighthouse-Geschwindigkeit möglich. Die Erfassung dieser Abdeckungsdaten ist jetzt viel effizienter. standardmäßig aktiviert.

Prüfungen zur Barrierefreiheit

Lighthouse nutzt die leistungsstarke Axe-Core-Bibliothek, die Kategorie „Bedienungshilfen“. In Lighthouse 6.0 haben wir die folgenden Prüfungen hinzugefügt:

Maskierbares Symbol

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

Charset-Deklaration

Das meta charset -Element gibt an, welche Zeichencodierung verwendet werden soll. zum Interpretieren eines HTML-Dokuments. Wenn dieses Element fehlt oder spät im verwenden Browser eine Reihe von Heuristiken, um zu erkennen, welche Codierung verwendet werden sollte. Wenn ein falsch interpretiert und ein spätes Meta-Charset-Element gefunden wird, löst der Parser normalerweise die bisher geleistete Arbeit erläutert und von vorn begonnen hat, was zu einer schlechten Nutzererfahrung führt. Diese neue wird überprüft, ob die Seite über eine gültige Zeichencodierung verfügt und diese frühzeitig und im Voraus definiert wurde.

Lighthouse CI

Bei CDS letzten November haben wir Lighthouse CI vorgestellt, den Open-Source-Knoten Befehlszeile und Server, mit denen Lighthouse-Ergebnisse bei jedem Commit in Ihrer Continuous Integration verfolgt werden und wir haben seit der Alpha-Version viel getan. Lighthouse CI unterstützt jetzt für zahlreiche CI-Anbieter wie Travis, Circle, GitLab und GitHub Actions. Bereit zur Bereitstellung Docker-Images erstellen Das neue Design des Dashboards zeigt Trends für alle Kategorien und Messwerte auf. in Lighthouse für eine detaillierte Analyse.

Nutzen Sie Lighthouse CI noch heute für Ihr Projekt. Folgen Sie dazu unserer Startleitfaden.

Lighthouse CI
Lighthouse CI
Lighthouse CI

Chrome-Entwicklertools wurden umbenannt

Wir haben den Bereich Audits in Lighthouse umbenannt. Genug gesagt!

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

Um das Steuerfeld schnell anzuzeigen, klicken Sie auf die Befehlstaste Menü:

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

Mobile Emulation

Lighthouse verfolgt einen Mobile-First-Ansatz. Leistungsprobleme sind unter normalen aber die Entwickler testen unter diesen Bedingungen häufig keine Tests. Aus diesem Grund ist die Standardeinstellung Konfiguration in Lighthouse wendet die Mobilgeräte-Emulation an. Die Emulation besteht aus:

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

Von Anfang an hat Lighthouse das Nexus 5X als Referenzgerät verwendet. In den letzten Jahren haben die meisten Performance Engineers nutzen das Moto G4 zu Testzwecken. Lighthouse folgt diesem Beispiel und hat sein Referenzgerät auf das Moto G4 umgestellt. In der Praxis ist diese Änderung kaum merklich, Hier sind jedoch alle Änderungen, die auf einer Webseite erkannt werden:

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

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

Emulationsliste der Chrome-Entwicklertools mit Moto G4.

Browsererweiterung

Die Chrome-Erweiterung für Lighthouse um Lighthouse lokal zu betreiben. Leider war der Support nicht ganz einfach. Der Lighthouse--Bereich der Chrome-Entwicklertools (der Bericht in andere Steuerfelder integriert ist, konnten wir unseren Entwicklungsaufwand reduzieren, indem wir die .

Anstatt Lighthouse lokal auszuführen, nutzt die Erweiterung nun PageSpeed Insights API hinzu. Wir wissen, dass dadurch kein ausreichender Ersatz für einige unserer Nutzer. Dies sind die wichtigsten Unterschiede:

  • PageSpeed Insights kann nicht öffentliche Websites nicht prüfen, da die Ausführung über eine Remote- und nicht auf Ihrer lokalen Chrome-Instanz. Wenn Sie eine nicht öffentliche Website überprüfen müssen, verwenden Sie den Lighthouse-Bereich der Entwicklertools oder die Node CLI.
  • Für PageSpeed Insights kann nicht garantiert werden, dass die neueste Lighthouse-Version verwendet wird. Wenn Sie die neueste Version haben, verwenden Sie die Node CLI. Die Browsererweiterung erhält das Update ungefähr ein bis zwei Wochen nach der Veröffentlichung.
  • PageSpeed Insights ist ein Google-API. Ihre Verwendung stellt eine Annahme der Google API-Nutzungsbedingungen Dienst. Wenn Sie die Nutzungsbedingungen nicht akzeptieren möchten oder können, verwenden Sie den Lighthouse-Bereich in den Entwicklertools. oder die Node CLI abrufen.

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

Budgets

Mit Lighthouse 5.0 wurden Leistungsbudgets eingeführt, die das Hinzufügen von Grenzwerten für wie viel von jedem Ressourcentyp wie Skripts, Bilder oder CSS), die eine Seite bereitstellen kann.

Lighthouse 6.0-Version Unterstützung von Budgetmesswerten, sodass Sie jetzt Grenzwerte für bestimmte Messwerte wie FCP festlegen können. Derzeit sind Budgets nur verfügbar, mit der Node CLI und Lighthouse CI verbunden.

Quellen-Links

Einige der Probleme, die Lighthouse in Bezug auf eine Seite findet, lassen sich auf eine bestimmte Zeile zurückführen und der Bericht enthält die relevante Datei und Zeile. Um dies zu vereinfachen, in den Entwicklertools ansehen. Wenn ihr auf die im Bericht angegebenen Speicherorte klickt, werden die entsprechenden Dateien im Bereich Quellen.

<ph type="x-smartling-placeholder">
</ph> <ph type="x-smartling-placeholder">
. Die Entwicklertools zeigen die genaue Codezeile an, die das Problem verursacht.

Am Horizont

Lighthouse hat mit der Erfassung von Source Maps für neue Funktionen begonnen, darunter:

  • Doppelte Module in JavaScript-Bundles werden erkannt.
  • Erkennung von übermäßig vielen Polyfills oder Transformationen in Code, der an moderne Browser gesendet wird.
  • Die Prüfung „Unused JavaScript“ wurde erweitert, um einen Detaillierungsgrad auf Modulebene zu ermöglichen.
  • Strukturkartenvisualisierungen, die die Module hervorheben, für die Maßnahmen erforderlich sind
  • Hier wird der ursprüngliche Quellcode für Berichtelemente mit einem Quellort angezeigt.
<ph type="x-smartling-placeholder">
</ph> Nicht verwendetes JavaScript, das Module aus Quellzuordnungen anzeigt.
Die Prüfung „Unused JavaScript“ mithilfe von Source Maps, um nicht verwendeten Code in bestimmten gebündelten Modulen anzuzeigen

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

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

Vielen Dank!

Vielen Dank, dass Sie Lighthouse verwenden und uns Feedback geben. Dein Feedback hilft uns, Lighthouse zu verbessern und wir hoffen, dass es mit Lighthouse 6.0 einfacher ist, die Leistung Websites.

Was können Sie jetzt tun?

  • Öffnen Sie Chrome Canary und probieren Sie den Bereich Lighthouse aus.
  • Verwenden Sie die Knoten-Befehlszeile: npm install -g lighthouse && lighthouse https://yoursite.com --view.
  • Lighthouse CI ausführen mit für Ihr Projekt.
  • Lesen Sie die Dokumentation zum Lighthouse-Audit.
  • Viel Spaß dabei, das Web zu verbessern!

Wir lieben das Web und arbeiten gern mit der Entwickler-Community zusammen, um Tools zu entwickeln, das Web zu verbessern. Lighthouse ist ein Open-Source-Projekt und Beitragende, die bei allen möglichen Problemen helfen, von Tippfehlern über Refaktorierung der Dokumentation bis hin zu brandneuen Prüfungen. Möchtest du etwas beitragen? Sehen Sie sich das Lighthouse GitHub-Repository an.