Lighthouse: Website-Geschwindigkeit messen und Verbesserungen finden

Lighthouse ist ein automatisiertes Prüfungstool, das Probleme und mögliche Verbesserungen in der Leistung, Barrierefreiheit, bewährten Vorgehensweisen und Suchmaschinenoptimierung (SEO) einer Webseite identifiziert. Analysieren Sie das Laden einer Seite in Chrome DevTools, verfolgen Sie eine langsame Metrik zu den beteiligten Anfragen, Dateien oder Ausführungsaufgaben, ändern Sie eine Sache und messen Sie erneut unter denselben Bedingungen. Eine einzelne Punktzahl stellt nicht die Erfahrung jedes Besuchers dar und bestimmt nicht die Suchplatzierung einer Seite.

Lighthouse und PageSpeed Insights: Was ist der Unterschied?

Die offizielle Lighthouse-Übersicht beschreibt, wie Audits über Chrome DevTools, die Befehlszeile oder ein Node-Modul durchgeführt werden. Anfänger können mit dem in Chrome für Desktop enthaltenen Panel beginnen, ohne eine Erweiterung zu installieren. Dieser Weg ist auch nützlich für eine angemeldete Seite oder eine lokale Entwicklungsseite.

Die Dokumentation von PageSpeed Insights unterscheidet zwischen Labordaten und Felddaten. Labordaten sind eine Lighthouse-Diagnose, die unter bestimmten Bedingungen erstellt wird. Daten zur tatsächlichen Nutzererfahrung stammen aus dem Chrome User Experience Report (CrUX) und decken den vorherigen 28-tägigen Erfassungszeitraum ab. Wenn eine Seite zu wenige Stichproben hat, kann der Service Daten für die gesamte Origin (gleiches URL-Schema, gleicher Host und Port) oder keine echten Nutzerdaten anzeigen. Ein Labortergebnis bedeutet nicht, dass für diese spezielle Seite echte Besucherstatistiken verfügbar sind.

Für eine schnelle Überprüfung einer öffentlichen URL geben Sie sie in PageSpeed Insights ein, analysieren sie und wählen Sie die mobilen und Desktop-Ergebnisse separat aus. Für Seiten, die nur nach der Anmeldung sichtbar sind, oder lokale URLs, die extern nicht erreichbar sind, verwenden Sie stattdessen die lokalen DevTools. Senden Sie keine privaten URLs oder Zugriffstoken an einen externen Analyse-Service.

Die Messwerte eines Berichts beschreiben die Ziel-URL und die Ausführungsbedingungen. Eine Demonstration mit einer öffentlichen Beispiel-URL misst nicht die Website, die die Anleitung veröffentlicht, noch Ihre eigene Website. Halten Sie den Abschnitt über die Erfahrung realer Nutzer getrennt vom Lighthouse-Diagnoseabschnitt, wenn Sie einen Bericht lesen.

Wählen Sie zuerst die Seite und die Messbedingungen aus

  • Ziel: Geben Sie die URL an, die getestet werden soll, einschließlich repräsentativer Artikel, Listings oder Produktseiten und nicht nur der Startseite. Kombinieren Sie nicht verschiedene Vorlagen, als wären sie Vorher-Nachher-Ergebnisse für dieselbe Seite.
  • Status: Notieren Sie, ob dies ein erster oder wiederholter Besuch ist, den Anmeldestatus und wie Zustimmungsbanner behandelt werden. Für eine öffentliche Seite, die keine Anmeldung erfordert, kann ein separates Profil oder ein Inkognito-Fenster helfen, Auswirkungen von Erweiterungen zu reduzieren.
  • Umgebung: Notieren Sie die Chrome- und Lighthouse-Versionen, die Auswahl zwischen Mobilgerät oder Desktop, die Methode zur Drosselung von Netzwerk und CPU sowie die Messzeit. Vermeiden Sie es, gleichzeitig große Downloads oder andere aufwändige Arbeiten auszuführen.
  • Speicher: Die Option Speicher löschen (Clear storage) entfernt die Speicherdaten der Website, um einen ersten Besuch ungefähr nachzuahmen. Dies kann den Anmelde- und Zustimmungsstatus beeinflussen, daher sollten Sie es nicht beiläufig in einer Sitzung aktivieren, die wichtige Arbeiten enthält. Beim Überprüfen einer angemeldeten Seite wählen Sie Einstellungen, die den erforderlichen Zustand erhalten, und verwenden Sie diese konsequent bei späteren Vergleichen.

Die Überprüfung während der Anmeldung als Administrator kann andere Skripte, Symbolleisten und Cache-Richtlinien laden als die, die von einem anonymen Besucher verwendet werden. Messen Sie die öffentliche Seite separat, wenn die Frage gewöhnliche Leser betrifft. Wenn das Ziel eine Funktion für angemeldete Benutzer ist, zeichnen Sie diesen Zustand ausdrücklich auf.

Analysieren Sie das Laden einer Seite in den Chrome DevTools

  1. Öffnen Sie die Seite im Desktop-Chrome. Überprüfen Sie, ob die öffentliche Adresse korrekt ist, zum Beispiel, und dass die Seite nicht auf einen Fehlerbildschirm weitergeleitet wurde.
  2. Öffnen Sie die DevTools, zum Beispiel mit F12 oder Strg+Shift+I unter Windows. Wenn der Lighthouse-Tab verborgen ist, finden Sie ihn über das Tab-Überlaufmenü oder Mehr Werkzeuge im DevTools-Menü. Menünamen können sich je nach Browsersprache und Version unterscheiden.
  3. Für ein initiales Seitenlade-Audit wählen Sie Navigation unter Modus. Wählen Sie Mobile oder Desktop unter Gerät. Der Mobile-Modus ist ein Labortest mit ausgewählten Einschränkungen, nicht eine Wiedergabe der Leistung jedes realen Telefons.
  4. Wählen Sie Leistung unter Kategorien aus und fügen Sie bei Bedarf Barrierefreiheit, Best Practices oder SEO hinzu. Überprüfen Sie die Einstellungen zum Speicherlöschen und Drosseln und behalten Sie deren Werte während der Vergleiche bei.
  5. Wählen Sie Seite laden analysieren oder die entsprechende Starttaste in Ihrer Version. Die Seite wird neu geladen, speichern Sie daher vorher unvollständige Formulare oder andere nicht gespeicherte Arbeit. Vermeiden Sie es, während der Analyse mit der Seite zu interagieren, und warten Sie auf den Bericht.
  6. Überprüfen Sie die angeforderte URL, die endgültige URL, die Einstellungen und Versionen. Speichern Sie den Bericht als HTML oder JSON und wählen Sie das benötigte Format, wenn das Exportmenü diese Auswahl bietet. Berichte können interne Adressen oder Diagnoseinformationen enthalten, daher sollten Sie deren Inhalte vor der Weitergabe berücksichtigen.

Wählen Sie einen anderen Modus für Szenarien, die keine einfache Ladeprüfung sind. Die Lighthouse-Benutzerflussdokumentation unterscheidet Navigation für eine einzige Navigation, Timespan für einen Zeitraum, der Interaktionen enthalten kann, und Snapshot für den aktuellen Seitenzustand. Vergleichen Sie Timespan- oder Snapshot-Ergebnisse nicht so, als wären sie das vollständige Leistungsergebnis von Navigation. Ziehen Sie Snapshot in Betracht, wenn die Frage einen bestimmten Zustand betrifft, wie z. B. Barrierefreiheit, während ein Menü geöffnet ist.

Lesen Sie die Metriken und diagnostischen Hinweise, bevor Sie die Punktzahl betrachten

Die Erklärung der Leistungsbewertung beschreibt die Punktzahl als gewichteten Durchschnitt von transformierten Metrikwerten. Die Reduzierung der Anzahl diagnostischer Warnungen erhöht die Punktzahl nicht um denselben Betrag. Punktzahlen von 90–100 werden als gut angezeigt, 50–89 als verbesserungswürdig und 0–49 als schlecht. Diese Bereiche interpretieren die Punktzahl eines Durchlaufs; sie definieren nicht jede akzeptable Verzögerung für reale Benutzer.

Metrik Was sie misst Hinweise, die zuerst untersucht werden sollten
FCP: First Contentful Paint Zeit bis der erste Inhalt angezeigt wird. Erste Serverantwort und render-blockierende Styles oder Skripte.
LCP: Largest Contentful Paint Wenn der große Hauptinhalt im Ansichtsfenster angezeigt wird. Das im Bericht identifizierte Element und Verzögerungen beim Starten, Übertragen oder Anzeigen seiner Bildanforderung.
TBT: Total Blocking Time Die Summe der blockierenden Teile langer Aufgaben des Hauptthreads während des Ladens. Lange JavaScript-Ausführung, unnötige Startskripte und Drittanbieter-Code.
CLS: Cumulative Layout Shift Die Menge an unerwarteten Layout-Verschiebungen. Bilder oder Anzeigen ohne reservierten Platz und Elemente, die spät eingefügt werden.
Speed Index (Geschwindigkeitsindex) Wie schnell sichtbarer Inhalt angezeigt wird. Zeiträume verzögerter anfänglicher Anzeige, die zusammen mit der visuellen Aufzeichnung betrachtet werden.

Die TBT Dokumentation definiert eine lange Aufgabe als eine, die 50 Millisekunden überschreitet, wobei der Überschuss über 50 Millisekunden als Blockierungszeit gezählt wird. TBT ist nicht dasselbe Maß wie Interaction to Next Paint (INP), das die Reaktionsfähigkeit auf Benutzerinteraktionen betrifft. Überprüfen Sie die Core Web Vitals-Metriken echter Nutzer—LCP, INP und CLS—separat in den Feld-Daten.

Erweitern Sie die Erkenntnisse und Diagnosen des Berichts, um die betroffenen Elemente und Ressourcen zu finden. Wenn das LCP-Element ein Bild im anfänglichen Ansichtsbereich ist, beginnen Sie mit seiner Übertragungsgröße und der Anforderungszeit. Bei großen Layoutverschiebungen prüfen Sie, ob Platz für Bilder und Anzeigen reserviert ist. Ein wichtiges Bild im ersten Bildschirmbereich einfach verzögert zu laden oder jedes Skript auf die gleiche Weise zu verzögern, kann die notwendige Anzeige oder Funktionalität beeinträchtigen, daher sollten Sie zunächst die Ursache und Nutzung identifizieren.

Für eine tiefere Untersuchung fahren Sie mit Aufzeichnungen und Insights im Performance-Panel fort, wie in der Anleitung zu Chromes Lighthouse und Performance-Panel beschrieben. Hohe Accessibility- oder SEO-Werte garantieren nicht vollständige Barrierefreiheit oder hohe Suchrankings. Tastaturgebrauch und tatsächliche Inhaltsqualität müssen, neben anderen Aspekten außerhalb automatisierter Prüfungen, weiterhin überprüft werden.

Ändern Sie eine Sache und messen Sie erneut unter denselben Bedingungen

  1. Wählen Sie ein Problem mit erheblichem Nutzerimpact und einer spezifischen Ursache. Bei einem zu großen Bild im anfänglichen Viewport experimentieren Sie zum Beispiel zuerst mit einem Bild, das seiner angezeigten Größe entspricht.
  2. Bewahren Sie die Originaldateien, Einstellungen und den Bericht auf. Nehmen Sie Änderungen lokal oder in einer Testumgebung vor und überprüfen Sie, dass Caches nach der Bereitstellung die neuen Dateien ausliefern. Verbergen Sie keine notwendige Funktionalität und liefern Sie nicht nur für das Audit eine andere Seite aus, um eine höhere Punktzahl zu erzielen.
  3. Wiederholen Sie Messungen mit derselben URL, demselben Login-Status, Gerätemodus und Drosselungseinstellungen. Vergleichen Sie die Rohwerte sowie die Spanne und den Median der wiederholten Messungen, anstatt nur einen besten Wert zu betrachten. Wenn Sie beispielsweise fünf Läufe pro Bedingung wählen, verwenden Sie diese Anzahl sowohl vor als auch nach der Änderung.
  4. Überprüfen Sie, dass die Zielmetrik sich verbessert und dass Layout, Schaltflächen, Formulare und Tastaturinteraktionen weiterhin funktionieren. Wenn die Änderung nicht hilft oder die Funktionalität beeinträchtigt, stellen Sie die gespeicherten Dateien und Einstellungen wieder her und untersuchen Sie eine andere Ursache.

Der Leitfaden zur Messvariabilität erklärt, dass Änderungen im Netzwerk, an Geräten, Servern und Seiten die Werte beeinflussen können, ohne dass eine Codeänderung erfolgt. Auch Zustände von Anzeigen und Consent-Bannern sind Vergleichsbedingungen. Notieren Sie das Datum, die URL, die Tool-Versionen, Einstellungen, Metriken und Änderungen im Bericht und bewerten Sie die Real-User-Metriken, nachdem genügend Erfassungszeit und Proben zur Verfügung stehen.

Wenn die Analyse fehlschlägt oder die Ergebnisse erheblich abweichen

Wenn eine Seite nicht geladen wird, der Zugriff blockiert ist oder Weiterleitungen fehlschlagen, überprüfen Sie die endgültige URL und eine normale HTTP-Antwort, bevor Sie eine Bewertung interpretieren. Entfernen Sie keine Authentifizierung, um eine private Seite für einen externen Test zugänglich zu machen. Für lokale Messungen überprüfen Sie die Anmelde- und Speicherlöschungseinstellungen. Wenn Erweiterungen beteiligt sein könnten, wiederholen Sie dasselbe Ziel in einer Umgebung mit weniger Erweiterungseinfluss.

Ein Unterschied zwischen PageSpeed Insights und der Bewertung Ihres PCs ist nicht automatisch ein Fehler. Vergleichen Sie zuerst die Lighthouse-Versionen, Serverzugriffspfade, Geräte- und Drosselungseinstellungen sowie den Cookie-Zustand. Versuchen Sie nicht, mobile und Desktop-Bewertungen anzugleichen; vergleichen Sie Vorher-Nachher-Änderungen innerhalb jeder Bedingung und berücksichtigen Sie die Kennzahlen realer Besucher.