Ein Page-Speed-Ergebnis lesen
Ein Page-Speed-Ergebnis zeigt mehr als Scores. Unter den Score-Anzeigen finden Sie Panels, die erklären, warum die Seite schnell oder langsam war: welches Element der Largest Contentful Paint war, was sich verschoben hat, welche Skripte die CPU beschäftigt haben und in welcher Reihenfolge jede Anfrage geladen wurde. Diese Anleitung geht jedes Panel durch und sagt, was Sie mit dem Gesehenen tun können.
Ein Panel erscheint nur, wenn der Lauf Daten dafür hat. Ein Lauf ohne Daten zu Layoutverschiebungen hat zum Beispiel keine Karte Verschobene Elemente.
Wiedergabe des Seitenaufbaus
Neben den Score-Anzeigen steht der letzte Screenshot der Seite in einem kleinen Player. Klicken Sie darauf, um den Seitenaufbau abzuspielen. So sehen Sie, wann Inhalte erscheinen. Das Vergrößern-Symbol (Vollständigen Screenshot anzeigen) öffnet den letzten Screenshot in voller Größe.
Nutzen Sie das als schnellen Check, bevor Sie Zahlen lesen. Bleibt die Seite lange leer oder taucht ein Banner spät auf und schiebt den Inhalt nach unten, sehen Sie es hier.
Performance-Diagnose
Der Bereich Performance-Diagnose liest den Lighthouse-Trace dieses Laufs und zeigt, was ihn ausgebremst hat. Er hat bis zu vier Karten.
Largest-Contentful-Paint-Element
Diese Karte nennt das Element, das der Largest Contentful Paint (LCP) war, und zeigt seinen HTML-Ausschnitt. Außerdem schneidet sie den Screenshot der Seite um das Element zu und zeichnet einen Rahmen darum. Der Wert neben dem Titel ist die LCP-Zeit.
Unter LCP-Aufschlüsselung wird die LCP-Zeit in vier Phasen aufgeteilt, jede mit ihrer Zeit und ihrem Anteil:
| Phase | Was sie umfasst | Wenn sie den größten Anteil hat |
|---|---|---|
| Time to First Byte | Bis das erste Byte des HTML ankommt | Den Server beschleunigen: Caching, ein CDN, weniger Weiterleitungen |
| Verzögerung bis zum Laden der Ressource | Vom ersten Byte, bis der Browser die LCP-Ressource lädt, etwa das Hero-Bild | Die Ressource früh auffindbar machen: ins HTML setzen, vorladen, nicht per Lazy Loading laden |
| Ladezeit der Ressource | Das Herunterladen der LCP-Ressource | Sie verkleinern: Bild komprimieren, ein modernes Format nutzen, die passende Größe ausliefern |
| Verzögerung beim Rendern des Elements | Von der fertig geladenen Ressource, bis das Element gezeichnet ist | Render-blockierendes CSS und JavaScript sowie lange Main-Thread-Tasks reduzieren |
Ein Textelement muss keine Ressource herunterladen, daher liegt der Großteil seiner Zeit in der ersten und der letzten Phase. Mehr zur Metrik unter Largest Contentful Paint (LCP).
Verschobene Elemente
Die fünf Elemente, die am meisten zum Cumulative Layout Shift (CLS) beigetragen haben, das größte zuerst. Jede Zeile zeigt das Element, seinen CSS-Selektor und seinen Shift-Wert. Der Wert folgt den Core-Web-Vitals-Schwellen: unter 0,1 ist gut, ab 0,1 verbesserungswürdig, ab 0,25 schlecht. Hat sich nichts bewegt, steht auf der Karte Keine Layoutverschiebungen erfasst.
Typische Lösungen: Geben Sie Bildern, Videos, Anzeigen und Einbettungen eine Breite und Höhe oder einen reservierten Platz. Fügen Sie keine Banner oder andere Inhalte über dem ein, was schon auf dem Bildschirm steht.
CPU-Zeit pro Skript
Die fünf Skripte mit der meisten CPU-Zeit im Main Thread, mit ihrem Host und einem Balken zum Vergleich. Sonstiges (nicht zuordenbar) ist Arbeit, die Lighthouse keinem einzelnen Skript zuordnen kann.
Arbeit im Main Thread treibt die Total Blocking Time. Steht ein Drittanbieter-Host oben, prüfen Sie, ob diese Seite das Skript überhaupt braucht, oder laden Sie es später. Ist es Ihr eigenes Bundle, teilen Sie es auf und laden Sie Code, den die erste Ansicht nicht braucht, verzögert.
Seitengewicht
Die gesamte übertragene Größe und die Zahl der Anfragen. Darunter teilen ein Balken und eine Liste das Gewicht nach Ressourcentyp auf (Dokument, Skript, CSS, Bild, Schrift, Medien, Sonstiges), jeweils mit Größe, Anfragen und Anteil. Die letzte Zeile zeigt, wie viel von Drittanbietern kam, zum Beispiel "Drittanbieter: 1.2 MB in 40 Anfragen (35 % des Gewichts)".
Bilder und Skripte haben meist den größten Anteil. Um einen Alert zu bekommen, wenn die Seite wächst, setzen Sie ein Budget auf Page Weight (KB) oder Requests. Siehe Performance-Budgets.
Anfrage-Wasserfall
Der Anfrage-Wasserfall listet jede Anfrage der Seite in der Reihenfolge, in der sie gestartet sind. Die Zeile unter dem Titel nennt die Zahl der Anfragen und die übertragene Größe.
Die Zeiten stammen vom echten, ungedrosselten Laden. Sie können kürzer sein als die gedrosselten Labor-Metriken in den Anzeigen. Nutzen Sie den Wasserfall für die Reihenfolge der Anfragen und dafür, was worauf gewartet hat, nicht für absolute Zeiten.
Was Sie sehen:
- Filmstreifen: Screenshots der Seite während des Ladens, auf derselben Zeitachse wie der Wasserfall. Das erste Bild zum oder nach dem First Contentful Paint trägt den Tag FCP, das erste zum oder nach dem Largest Contentful Paint den Tag LCP. Fahren Sie mit der Maus über ein Bild, um seinen Zeitpunkt als Linie über den Wasserfall zu legen.
- Typ-Filter: ein Chip für Alle und einer für jeden Ressourcentyp der Seite, mit Anzahl. Klicken Sie auf einen Chip, um nur diesen Typ zu sehen.
- Markierungen: senkrechte Linien für First Contentful Paint, Largest Contentful Paint und Load-Ereignis. Die Legende nennt ihre Zeiten.
- Zeilen: Jede Anfrage zeigt Dateiname, Host, Browser-Priorität (Am höchsten bis Am niedrigsten), den Statuscode, wenn er nicht 200 ist, und die übertragene Größe. Der blasse Teil des Balkens ist Wartezeit vor dem Start der Anfrage, der kräftige Teil die Anfrage selbst. Fahren Sie über den Balken, um Start- und Endzeit zu sehen.
- Blockiert das Rendern: Die Anfrage hat das erste Zeichnen aufgehalten, zum Beispiel ein Stylesheet oder ein synchrones Skript im Head.
- Preload: Die Seite hat die Anfrage mit einem
rel="preload"-Link früh angefordert. - Nicht geladen: Die Anfrage wurde nie fertig. Sie stand in der Liste Anfragen blockieren des Tests oder ist im Netzwerk gescheitert.
Die Liste beginnt mit den ersten 30 Anfragen. Klicken Sie unter der Liste auf Alle N Anfragen anzeigen, um den Rest zu sehen, und auf Weniger anzeigen, um sie wieder einzuklappen.
So nutzen Sie ihn:
- Sehen Sie sich an, was vor der FCP-Markierung lädt. Jede Anfrage mit Blockiert das Rendern dort verzögert das erste Zeichnen. Binden Sie das kritische CSS inline ein und geben Sie Skripten, die nicht blockieren müssen,
deferoderasync. - Suchen Sie die LCP-Ressource, oft ein Bild. Startet sie spät, nach einer Kette aus CSS und Skripten, laden Sie sie vor. Trägt sie dann den Tag Preload, prüfen Sie, ob sie jetzt weit oben startet.
- Filtern Sie auf Skript, um zu sehen, wie viele Skripte laden und von welchen Hosts.
- Eine lange Strecke ohne neue Anfragen bedeutet oft, dass der Main Thread beschäftigt ist. Vergleichen Sie mit CPU-Zeit pro Skript.
Server-Antwortzeit (TTFB)
Die Metrik-Karten des Ergebnisses enthalten Server-Antwortzeit (TTFB): die Zeit, bis der Server begonnen hat, das HTML-Hauptdokument zu senden. Wie die anderen Karten zeigt sie den Wert Aktuell und den Median. Gut sind 0,8 Sekunden oder weniger, über 1,8 Sekunden ist schlecht. Bei den Verlaufsdiagrammen gibt es ebenfalls ein Diagramm Server-Antwortzeit (TTFB), und es enthält auch ältere Läufe.
Eine langsame TTFB verzögert jede andere Metrik, denn nichts kann starten, bevor das HTML ankommt. Prüfen Sie serverseitiges Caching, langsame Datenbankabfragen, ein CDN vor der Website und Weiterleitungen.
Im PDF-Bericht
Der druckbare Bericht enthält die Performance-Diagnose und den Anfrage-Wasserfall. Im PDF listet der Wasserfall jede Anfrage, nicht nur die ersten 30, und lässt die Filter-Chips und Schaltflächen weg. Siehe Gebrandete PDF-Berichte.