Lesen Sie PageSpeed Insights in drei Schritten: Umfang und problematische Feldmetrik bestimmen, den aktuellen Labortest prüfen und eine passende Ursache untersuchen. Feldbewertung und Lighthouse-Punktzahl beantworten verschiedene Fragen. Ein grüner Kreis hebt ein Problem im anderen Abschnitt nicht auf.
Beginnen Sie mit einer repräsentativen öffentlichen URL. Kontrollieren Sie das Weiterleitungsziel und wählen Sie Mobilgerät oder Desktop. Speichern Sie die Bedingungen vor Änderungen, damit der nächste Test dieselbe Seite und Strategie betrifft.
Kontrollieren Sie zunächst Seite und Testbedingungen
Ein erfolgreicher Test kann die falsche Erfahrung messen. Prüfen Sie Weiterleitungen, Inhalt, Zugriffsbeschränkungen, Botschutz und Fehlermeldungen. Eine schnelle Sicherheitsprüfung beweist kein schnell ladendes Dokument.
Verwenden Sie unterschiedliche Vorlagen statt nur der Startseite. Artikel, Kategorien, Produkte und Suche können andere Ressourcen nutzen. Beginnen Sie mit einem bekannten Problem und prüfen Sie weitere Beispiele vor Abschluss einer gemeinsamen Korrektur.
Notieren Sie Datum, Strategie und endgültige URL sowie Lighthouse-Version und Umgebung. Bezeichnungen ändern sich mit Releases. Orientieren Sie sich am Zweck eines Abschnitts statt an veralteten Screenshots.
Googles PageSpeed-Insights-Übersicht erklärt Feld und Labor. Der Bericht ist ein Einstieg in die Diagnose, keine pauschale Anweisung zur Umsetzung jedes Hinweises.
Lesen Sie echte Besucherdaten vor der Laborpunktzahl
CrUX beschreibt geeignete reale Chrome-Besuche der vorherigen 28 Tage und wird täglich aktualisiert. Prüfen Sie, ob das Feldpanel die URL oder die gesamte Origin zeigt.
Die Origin kombiniert Schema, Hostname und Port. Sie kann verschiedene Seitentypen enthalten und beweist keine identische Verteilung des getesteten Artikels. Bewahren Sie die Umfangskennzeichnung in Screenshots und Berichten auf.
LCP betrifft Laden, INP Interaktionsreaktion und CLS visuelle Stabilität. Gut sind am p75 höchstens 2,5 Sekunden LCP, 200 Millisekunden INP und 0,1 CLS. CLS ist einheitenlos. Addieren oder mitteln Sie keine unterschiedlichen Einheiten.
Bei ausreichenden Daten für alle drei müssen alle gut sein. PSI erlaubt eine Bewertung anhand von LCP und CLS, wenn INP nicht genügend Daten besitzt. Fehlt ausreichend LCP oder CLS, ist keine Bewertung möglich. Ein fehlender INP ist nicht null und kein gemessener guter Wert.
Verstehen Sie Verteilungsbalken und Zusatzmetriken
Die Balken zeigen Anteile guter, verbesserungsbedürftiger und schlechter Erfahrungen. Sie sind kein Anteil bestandener Ressourcenprüfungen. p75 ist ein Perzentil der Besuche, nicht ihr Mittelwert.
Eine hypothetische Seite mit gutem p75 kann einen deutlichen langsamen Randbereich haben. Untersuchen Sie dafür gegebenenfalls Regionen, Geräte und Vorlagen im eigenen Monitoring. Der öffentliche Balken nennt die Ursache nicht.
FCP und TTFB helfen zusätzlich bei Ladeanalysen, sind aber keine weiteren Core Web Vitals. Ein später erster Byteempfang kann Folgeschritte verzögern, rechtfertigt jedoch nicht automatisch einen größeren Server. Prüfen Sie Weiterleitungen, Verbindungen, Anwendung und Cache.
Erhalten Sie beim Übertragen Einheiten. Verwechselte Sekunden und Millisekunden erzeugen vermeintliche Katastrophen. Ergänzen Sie bei CLS kein „ms“.
Betrachten Sie Mobilgeräte und Desktop separat
Die Geräteauswahl ändert Laborstrategie und Feld-Formfaktor. Echte Mobilgeräte entsprechen nicht dem simulierten Profil, beide können jedoch Probleme gegenüber einem leistungsfähigen Desktop zeigen. Mitteln Sie ihre Punktzahlen nicht zu einer künstlichen Gesamtnote.
Auch das Layout ändert sich: anderes Hauptbild, höhere Kopfzeile, verstecktes Menü oder andere Komponenten. Bestimmen Sie bei abweichendem LCP jeweils das größte Element, bevor Sie eine Bild- oder Serverkorrektur wählen.
Prüfen Sie wichtige Abläufe in beiden Ansichten. Ein responsives Layout kann trotzdem ein langsames Menü oder eine springende Anzeige haben. Responsives CSS und durch INP gemessene Reaktionsfähigkeit sind nicht dasselbe.
Die Core-Web-Vitals-Einführung erläutert den Nutzerbezug. Getrennte Ausgangswerte verhindern, dass eine Verbesserung eine andere Verschlechterung verdeckt.
Behandeln Sie Lighthouse als Laborzusammenfassung
Lighthouse analysiert die URL unter konfigurierten Bedingungen. Seine Leistungspunktzahl reicht von 0 bis 100: ab 90 gut, 50 bis 89 verbesserungsbedürftig, unter 50 schlecht. Das sind keine Feldmetriken-Grenzwerte.
Der Gesamtwert kombiniert gewichtete Metrikwerte. Diagnosen erklären mögliche Ursachen; ein behobener Hinweis bringt keine feste Punktzahl. Vergleichen Sie Version, Einzelzeiten und Bedingungen neben dem Kreis.
Kleine Zeitänderungen können sichtbar auf die Punktzahl wirken, während eine nützliche Reparatur denselben gerundeten Wert behält. Prüfen Sie die konsistente Änderung des betroffenen Meilensteins und die korrekte Funktion.
Barrierefreiheit, Best Practices und SEO enthalten andere begrenzte Prüfungen. Eine hohe SEO-Note verspricht kein Ranking; eine automatische Zugänglichkeitsprüfung ersetzt keine vollständige Untersuchung. Erläutern Sie diesen Umfang gegenüber Auftraggebern.
Ordnen Sie Labormetriken passenden Untersuchungen zu
Ein Navigationslauf erfasst Laden und währenddessen beobachteten CLS. Spätere Verschiebungen können fehlen. Die reale INP-Verteilung liefert er nicht; dafür braucht es Besucherdaten beziehungsweise geeignete Interaktionstests.
Diese Tabelle hilft bei der Zuordnung, ohne Metriken auszutauschen.
| Wert | Hilft bei der Untersuchung | Beweist nicht |
|---|---|---|
| LCP | Lieferung und Rendering des größten Inhalts | Schnelle spätere Interaktionen |
| CLS | Beobachtete unerwartete Bewegung | Dauerhafte Stabilität nach Testende |
| FCP | Sichtbarkeit des ersten Inhalts | Fertigen Hauptinhalt |
| TBT | Hauptthread-Blockierung während der Ladephase | Tatsächlichen Feld-INP |
| Speed Index | Fortschritt visueller Vollständigkeit | Eigenständigen Core-Web-Vitals-Erfolg |
Bei hohem TBT untersuchen Sie lange Aufgaben und Skripte. Bei schlechtem Feld-INP reproduzieren Sie Eingaben, Navigation und Auswahländerungen. TBT ist ein Hinweis, darf aber nicht als INP beschriftet werden.
Bei abweichendem CLS verlängern Sie die Aufzeichnung und testen spätes Laden. Die Erklärung zu Feld- und Labordaten hilft, bevor Sie einen Bericht als falsch bewerten.
Priorisieren Sie Diagnosen nach erklärbarer Wirkung
Öffnen Sie passende Insights und Diagnosen. Trotz wechselnder Namen bleiben die Fragen gleich: Was verzögert Entdeckung, Übertragung und Rendering, blockiert den Hauptthread oder verändert das Layout?
Verfolgen Sie bei LCP das Element im Wasserfalldiagramm. Ein großes Bild kann spät entdeckt werden, wegen anderer Prioritäten warten oder vor seiner möglichen Darstellung fertig geladen sein. Beheben Sie die dominante Phase statt allein Dateigröße zu reduzieren.
Bei renderblockierenden Ressourcen müssen Sie anfangs benötigte Stile und Skripte unterscheiden. Alles aufzuschieben kann ungestylten Inhalt oder defekte Abhängigkeiten erzeugen. Die Anleitung zu renderblockierenden Ressourcen erklärt die Entscheidung.
Geschätzte Einsparungen gelten für das Modell des Tests, nicht garantiert für alle Besucher. Überlappende Hinweise können denselben Engpass betreffen. Addieren Sie sie nicht zu einem versprochenen Gesamtgewinn. Setzen Sie eine begründete Änderung um und messen Sie erneut.
Machen Sie aus dem Befund eine reproduzierbare Aufgabe
Ein brauchbares Ticket nennt Seite, Gerät, Metrik, Beleg und Komponentenänderung. Fügen Sie die relevante Anfrage oder das Skript hinzu statt nur „grün machen“ zum gesamten Bericht. Eine Funktionsprüfung verhindert Optimierung durch Entfernung notwendiger Funktionen.
Ein Bildticket könnte etwa verlangen, das Hauptbild bereits in HTML auffindbar zu machen und die responsive Auswahl zu prüfen. Abnahmekriterien wären LCP und richtige Darstellung bei mehreren Breiten. Das ist ein Arbeitsbeispiel, keine Diagnose Ihrer Seite.
Priorisieren Sie gemeinsame Bausteine bei belegter Ursache. Ein verbreitetes Header-Skript kann wichtiger sein als eine einzelne Dekoration; ähnliche Farben belegen jedoch keinen gemeinsamen Fehler. Halten Sie für Eingriffe in Rendering und Anwendung einen Rückweg bereit.
Unterscheiden Sie Ursachen fehlender Daten
Neue, selten beobachtete oder nicht öffentlich auffindbare URLs können ohne Felddaten bleiben. Origin-Kontext füllt den fehlenden URL-Datensatz nicht. Geschützte Anwendungen brauchen andere Messwege.
Auch API-Änderungen, Konfiguration oder Dienstfehler können Felddaten fehlen lassen. Trennen Sie „kein CrUX-Datensatz“, „Anfrage fehlgeschlagen“ und „Integration liefert keine Felddaten“. Diese Zustände verdienen kein identisches rotes Fehlersymbol.
Nutzen Sie weiterhin passende Labortests und gegebenenfalls datenschutzgerecht geplantes RUM. Erfinden Sie weder ein Perzentil aus einem Lauf noch einen Erfolg aus einem fehlenden Wert.
Verwenden Sie die API mit expliziter Strategie
Die PSI-v5-API liefert programmatische Lighthouse-Analysen. Dieser Shellbefehl fordert die Performance-Kategorie einer beispielhaften öffentlichen URL an und speichert JSON. Er benötigt curl; Zugang, Quoten und Projektkonfiguration gelten weiterhin.
curl --fail-with-body --get \
'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
--data-urlencode 'url=https://example.com/' \
--data-urlencode 'strategy=mobile' \
--data-urlencode 'category=performance' \
--output pagespeed-mobile.jsonKonfigurieren Sie für automatisierte Nutzung Schlüssel und Quoten nach Googles Anleitung. Veröffentlichen Sie keine uneingeschränkten Zugangsdaten im Browsercode. Prüfen Sie HTTP und JSON-Fehler vor lighthouseResult; speichern Sie Zeitpunkt, endgültige URL, Version und Einstellungen.
Google kündigt an, CrUX-Daten künftig aus dieser API zu entfernen, und empfiehlt CrUX API oder CrUX History API. Planen Sie nicht mit dauerhaft verfügbaren loadingExperience- und originLoadingExperience-Feldern. Trennen Sie Labor- und Feldabrufe und behandeln Sie fehlende Felder ausdrücklich.
Eine API-Antwort begründet keine Berechtigung zur Prüfung privater URLs. Vermeiden Sie Tokens und personenbezogene Daten in übermittelten Adressen. Öffentliche Dienste brauchen serverseitige Zielprüfung und Missbrauchsschutz.
Testen Sie nach sinnvollen Änderungen erneut
Wiederholen Sie vergleichbare Läufe nach gezielten Eingriffen und behalten Sie Einzelwerte. Prüfen Sie betroffene Funktionen zusätzlich zur Navigation. Ständige Wiederholung ohne Änderungen zeigt hauptsächlich Schwankung und erzeugt keine neuen Feldbesuche.
Beobachten Sie neue eigene Messwerte und die öffentliche Entwicklung, während das 28-Tage-Fenster neue Besuche aufnimmt. Dokumentieren Sie Releases und Änderungen der Zielgruppe. Konsistenz über repräsentative Szenarien ist wichtiger als ein besonders günstiger Einzeltest.
Nutzen Sie den aktivierten PageSpeed-Analysator und anschließend die Anleitungen zur Ladegeschwindigkeit. Beenden Sie die Prüfung mit einer messbaren Aufgabe, Zuständigkeit und Wiederholungsbedingung statt einer unerklärten Warnungsliste.
