PageSpeed Insights erklärt: Was jeder Wert bedeutet und wie du ihn verbesserst
PageSpeed Insights erklärt
PageSpeed Insights erklärt: Werte, Metriken und Lösungen | We.Inc
Was jeder Wert in PageSpeed Insights bedeutet: Felddaten und Labordaten, Grenzwerte für LCP, INP, CLS, FCP und TTFB, die Gewichtung des Scores und Code, der rote Ergebnisse behebt.
PageSpeed Insights zeigt zwei Berichte. Der obere enthält Felddaten echter Chrome-Besucher der letzten 28 Tage, bewertet am 75. Perzentil. Der untere ist ein Lighthouse-Labortest mit einem Score von 0 bis 100: 90 oder mehr ist gut, 50 bis 89 verbesserungswürdig, unter 50 schlecht. Behebe zuerst die Feldmetriken.
Grenzwerte der Feldmetriken in PageSpeed Insights
Metrik
Gut
Verbesserungswürdig
Schlecht
LCP (Largest Contentful Paint)
2.5 s oder weniger
2.5 bis 4 s
über 4 s
INP (Interaction to Next Paint)
200 ms oder weniger
200 bis 500 ms
über 500 ms
CLS (Cumulative Layout Shift)
0.1 oder weniger
0.1 bis 0.25
über 0.25
FCP (First Contentful Paint)
1.8 s oder weniger
1.8 bis 3 s
über 3 s
TTFB (experimentell)
0.8 s oder weniger
0.8 bis 1.8 s
über 1.8 s
Die meisten starren auf den großen runden Score, doch diese Zahl stammt aus einem einzigen simulierten Besuch auf einem gedrosselten Smartphone. Dieser Leitfaden trennt die beiden Hälften des Berichts, lässt dich deine eigenen Werte mit den offiziellen Grenzwerten vergleichen und ordnet jeder roten Metrik die Änderung zu, die sie meist verbessert.
Prüfe deine URL auf pagespeed.web.dev und sieh dir zuerst den Block mit den Felddaten an. Steht dort, dass nicht genug Daten vorliegen, gibt es nur den Labortest.
Trage deine Werte für LCP, INP, CLS, FCP und TTFB unten in die Bewertung ein, um zu sehen, in welchen Bereich jeder fällt.
Öffne den Abschnitt mit den Lösungen für die schlechteste Metrik und übernimm die passende Codeänderung.
Warte auf neue Felddaten. Der Bericht echter Nutzer umfasst gleitende 28 Tage, daher zeigen sich Verbesserungen schrittweise und nicht schon am nächsten Morgen.
Der mobile Labortest läuft auf einem emulierten Mittelklasse-Smartphone mit langsamem Netz. Ein niedrigerer mobiler Score als auf dem Desktop ist daher normal.
Laborwerte schwanken zwischen Durchläufen um ein paar Punkte. Führe den Test dreimal aus und schau dir das mittlere Ergebnis an, bevor du entscheidest, dass sich etwas geändert hat.
Der Labortest kann INP nicht messen, weil niemand etwas anklickt. Total Blocking Time ist der Ersatz, daher deutet eine hohe TBT meist auf einen schlechten INP hin.
Drittanbieter-Tags wie Chat-Widgets, Heatmaps und Werbeskripte kosten oft mehr als dein eigener Code. Prüfe die Liste der Drittanbieter-Anfragen, bevor du deine App umschreibst.
Häufige Fragen
Warum unterscheiden sich meine Felddaten so stark vom Laborwert?
Sie messen verschiedene Dinge. Felddaten zeigen, was echte Chrome-Nutzer auf ihren eigenen Geräten und Netzen über 28 Tage erlebt haben. Der Laborwert ist ein einziger simulierter Ladevorgang mit fester Drosselung. Eine Seite kann im Labor 60 erreichen und die Core Web Vitals im Feld trotzdem bestehen, oder umgekehrt.
Beeinflusst der Lighthouse-Score das Google-Ranking?
Google beschreibt die Core Web Vitals als Messgrößen der realen Nutzererfahrung, die mit dem übereinstimmen, was seine zentralen Ranking-Systeme belohnen. Die Search-Dokumentation nennt den Laborwert von 0 bis 100 nicht als Ranking-Faktor. Betrachte diesen Wert daher als Diagnosewerkzeug, um Probleme zu finden.
Was ist TTFB und welcher Wert ist gut?
Time to First Byte ist die Zeit, die der Browser wartet, bis das erste Byte des HTML ankommt, einschließlich Weiterleitungen, DNS, Verbindungsaufbau und Serverarbeit. PageSpeed Insights wertet 800 ms oder weniger als gut. Die häufigste Lösung ist, HTML am Edge eines CDN zu cachen.
Wie wird der Lighthouse-Performance-Score berechnet?
Ab Lighthouse 10 ist er eine gewichtete Mischung aus fünf Labormetriken: Total Blocking Time 30 Prozent, LCP 25 Prozent, CLS 25 Prozent, FCP 10 Prozent und Speed Index 10 Prozent. Jede Metrik wird zunächst anhand einer Kurve in einen Teilwert von 0 bis 100 umgerechnet.
Warum heißt es, dass es für meine Website keine Felddaten gibt?
Der Chrome User Experience Report veröffentlicht Daten nur für Seiten und Origins mit genügend berücksichtigten Besuchen. Neue Websites oder solche mit wenig Traffic haben oft keine. Verlass dich dann auf den Labortest und dein eigenes Monitoring, bis der Traffic wächst.
Lies den Bericht von oben nach unten
Der erste Block beantwortet, ob echte Besucher eine gute Erfahrung hatten. Er zeigt für jede Metrik den Wert am 75. Perzentil, das heißt, drei von vier Besuchen waren mindestens so schnell. Ziel ist, alle drei Core Web Vitals (LCP, INP und CLS) zu bestehen.
Der zweite Block ist ein einzelner Lighthouse-Durchlauf. In seinen Diagnosen und Empfehlungen findest du heraus, warum eine Feldmetrik langsam ist, denn der Labor-Trace listet die tatsächlich beteiligten Dateien, Bilder und Skripte auf.
Ein durchgerechnetes Vorher und Nachher
Nimm eine typische Startseite eines kleinen Unternehmens mit einem bildschirmbreiten Hero-Foto, das per Lazy Loading geladen wird, einer Webschrift ohne Fallback-Strategie und drei Marketing-Tags im head. In diesem Beispiel beginnt der Download des LCP-Bildes erst, wenn das Skript fertig ist, also landet LCP im schlechten Bereich.
Wenn du loading=lazy beim Hero entfernst, fetchpriority=high ergänzt, das Foto als AVIF oder WebP in der angezeigten Größe auslieferst und die Tags erst laden lässt, wenn die Seite interaktiv ist, packst du jeden Teil des LCP an. Genau diese Änderungen zeigt der Code unten; deine eigenen Werte hängen von deiner Seite ab.
Wo jede Metrik meist schiefgeht
LCP teilt sich in vier Teile: Time to First Byte, Ladeverzögerung der Ressource, Ladedauer der Ressource und Renderverzögerung des Elements. Finde zuerst den größten Teil und behebe genau diesen.
Bei INP geht es um lange JavaScript-Aufgaben, die laufen, während jemand tippt oder schreibt. CLS entsteht durch Dinge, die nach dem ersten Rendern ihre Größe ändern: Bilder ohne Abmessungen, spät eingeblendete Banner und Schriften, die beim Austausch eine andere Breite haben.
Wie der Laborwert gewichtet wird
Ab Lighthouse 10 werden fünf Labormetriken kombiniert. Total Blocking Time hat das größte Gewicht, daher schadet schweres JavaScript dem Score mehr als alles andere.
Gewichtung des Lighthouse-Performance-Scores
Labormetrik
Gewichtung
Zugehörige Feldmetrik
Total Blocking Time
INP
Largest Contentful Paint
LCP
Cumulative Layout Shift
CLS
First Contentful Paint
FCP
Speed Index
Keine direkt
Häufige Audits und ihre Lösung
Was dir ein rotes Audit sagt
Audit oder Symptom
Warum es rot ist
Übliche Lösung
Das Bild für den Largest Contentful Paint wurde per Lazy Loading geladen
Der Browser wartet auf das Layout, bevor er das Hero-Bild abruft
loading=lazy beim Hero entfernen und fetchpriority=high ergänzen
Ressourcen beseitigen, die das Rendering blockieren
CSS oder synchrone Skripte im head verzögern das erste Rendern
Kritisches CSS inline einbinden, Skripte mit defer laden
Bilder richtig dimensionieren
Bilder sind größer als ihre angezeigte Größe
srcset und sizes verwenden, in Anzeigebreite exportieren
Bilder in modernen Formaten bereitstellen
JPEG oder PNG, wo AVIF oder WebP kleiner wäre
Konvertieren und mit picture oder einem Bild-CDN ausliefern
Nicht verwendetes JavaScript reduzieren
Code für Funktionen, die es auf dieser Seite nicht gibt
Bundles pro Route aufteilen, ungenutzte Bibliotheken entfernen
Auswirkungen von Drittanbieter-Code reduzieren
Tags blockieren den Main Thread
Tags nach einer Interaktion oder im Leerlauf laden
Bildelemente haben keine explizite Breite und Höhe
Es wird kein Platz reserviert, daher springt der Inhalt
width und height oder aspect-ratio setzen
Sicherstellen, dass der Text beim Laden der Webschrift sichtbar bleibt
Text ist verborgen, während die Schrift lädt
font-display: swap verwenden und die Hauptschrift vorladen
Die erste Serverantwort hat lange gedauert
Langsame TTFB durch nicht gecachtes HTML
HTML am Edge cachen, Weiterleitungen reduzieren
Code-Snippets zur Lösung
Hero-Bild, das zuerst lädt
Kein Lazy Loading beim wahrscheinlichen LCP-Element, hohe Abrufpriorität, moderne Formate und echte Abmessungen, damit nichts verrutscht.
Schrift, die keinen Text verbirgt
Lade die eine Schriftdatei vor, die im sichtbaren Bereich verwendet wird, und lass den Text bis zu ihrer Ankunft in einer Ersatzschrift erscheinen.
Drittanbieter-Tag, das erst lädt, wenn die Seite zur Ruhe kommt
Fügt ein Marketing-Skript ein, sobald der Browser im Leerlauf ist, damit es nicht mit dem ersten Rendern oder dem ersten Tippen konkurriert.
Platz für spät geladene Inhalte reservieren
Eine Einbettung oder ein Werbeplatz mit festem Seitenverhältnis verhindert, dass der Inhalt darunter beim Laden springt.
Geschwindigkeits-Checkliste
Arbeite diese Punkte der Reihe nach ab
Schritt
Prüfung
Felddaten: Welche von LCP, INP und CLS fällt am 75. Perzentil durch?
LCP-Element: Ist es ein Bild, und wird es per Lazy Loading geladen oder spät entdeckt?
TTFB: Ist das HTML gecacht, und gibt es Weiterleitungen davor?
JavaScript: Wie hoch ist die Total Blocking Time und welche Skripte verursachen sie?
Layout: Haben Bilder, Einbettungen und Banner reservierten Platz?
Schriften: Ist font-display gesetzt und wird die Hauptdatei vorgeladen?
Gut
Verbesserungswürdig
Schlecht
Bewerte deine Werte
Gib die Werte aus deinem Bericht ein, um zu sehen, ob jeder gut, verbesserungswürdig oder schlecht ist.