PageSpeed Insights (PSI)

TL;DR — PageSpeed Insights (PSI) ist ein kostenloses Google-Tool, das eine Seite auf zwei verschiedene Arten bewertet: wie echte Besucher sie tatsächlich erlebt haben (Felddaten) und wie ein einzelner simulierter Testlauf verlief (der 0–100-Lab-Score). Die 0–100-Zahl ist diejenige, über die sich alle Gedanken machen – und sie ist nicht das, was Google für das Ranking verwendet. Also geraten Sie nicht in Panik wegen eines roten Scores.

Was PageSpeed Insights ist

PageSpeed Insights befindet sich unter pagespeed.web.dev. Es ist kostenlos, erfordert keine Anmeldung und funktioniert mit jeder öffentlichen URL – einschließlich der Ihrer Wettbewerber. Sie fügen eine URL ein, und es testet sowohl mobil als auch Desktop (mobil ist die Standard-Registerkarte, und mobile Scores sind fast immer niedriger).

Die zwei Dinge, die PSI Ihnen zeigt

Das ist der Teil, der alle verwirrt, also halte ich es einfach. PSI zeigt zwei separate Berichte für dieselbe Seite:

1. Felddaten – was echte Menschen erlebt haben. Diese stammen aus dem Chrome UX Report (CrUX), der echte Chrome-Nutzer umfasst, die Ihre Seite in den letzten 28 Tagen besucht haben. Es ist der Abschnitt mit der Bezeichnung “Discover what your real users are experiencing.” (Übersetzung) „So erleben echte Nutzer Ihre Website.“ Hier erhalten Sie die Core Web Vitals Assessment – eine einfache Bewertung mit Bestanden oder Nicht bestanden.
2. Lab-Daten – ein simulierter Test. PSI führt außerdem Google Lighthouse einmal aus, auf einem simulierten Telefon und Netzwerk, und gibt den 0–100-Performance-Score sowie eine Liste mit vorgeschlagenen Korrekturen aus.

Das Eine, das Sie sich merken sollten

Der 0–100-Score ist kein Ranking-Faktor. Google rankt nach den Feld-Core-Web- Vitals – Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift, gemessen an echten Nutzern. Der 0–100-Lab-Score ist eine separate Zahl aus einem separaten System. Sie können einen Score von 72 erreichen und die Core Web Vitals trotzdem bestehen.

Ein paar weitere Dinge, die Menschen verwirren:

• Der Score ändert sich bei jedem Lauf. Es ist ein simulierter Test, also springt die Zahl umher. Führen Sie ihn ein paar Mal aus und interpretieren Sie eine Schwankung von 3–5 Punkten nicht über.
• Sie brauchen keine 100. Fast niemand erreicht 100. Zielen Sie darauf ab, die Core Web Vitals zu bestehen, nicht eine perfekte Zahl zu erreichen.
• Ein guter Score garantiert keine schnelle Seite für echte Nutzer, und ein “schlechter” Score bedeutet nicht, dass echte Nutzer leiden.

Ehrlich gesagt, es sei denn, Ihre Website ist wirklich langsam, ist das nicht der Ort, an dem ich beginnen würde. Möchten Sie die vollständige Aufschlüsselung – Feld vs. Lab, die p75-Schwellenwerte, die Daten-Fallbacks und wie PSI sich von Lighthouse und Search Console unterscheidet? Wechseln Sie zur Registerkarte Erweitert.

TL;DR — PSI (pagespeed.web.dev) meldet zwei unabhängige Analysen einer URL: Felddaten aus dem Chrome UX Report – echte Nutzer über einen rollierenden Zeitraum von 28 Tagen, anhand derer die Core Web Vitals Assessment mit Bestanden oder Nicht bestanden beim 75. Perzentil bestimmt wird – und Lab-Daten, ein einzelner Lighthouse-Lauf, der den 0–100-Performance-Score plus Diagnosen ergibt. Der 0–100-Score sind Lab-Daten und ist nicht ein Ranking-Faktor; für das Ranking werden die Feld-Core-Web-Vitals (LCP/INP/CLS) verwendet. Felddaten benötigen genügend CrUX-Stichproben (auf URL-Ebene, mit Rückfall auf Ursprungsebene, sonst “Keine Daten”). Der Lab-Score ist auch von Lauf zu Lauf variabel – führen Sie ihn ein paar Mal aus. PSI ist die Web-UI; Lighthouse ist die Engine; der Bericht der Search Console ist eine weitere CrUX-Ansicht.

PSI ist zwei Tools in einem Mantel

Das Wichtigste, das Sie über PageSpeed Insights verstehen müssen, ist, dass es nicht eine Analyse ist – es sind zwei, die in einer Oberfläche angezeigt werden. web.dev formuliert es klar: “PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page.” (Übersetzung) „PSI ist ein Tool, das Felddaten aus CrUX und Lab-Daten aus Lighthouse für eine einzelne Seite meldet.” Diese beiden Hälften stammen aus verschiedenen Systemen, messen verschiedene Dinge und sind aus verschiedenen Gründen wichtig. Wenn Sie beide vermischen, wird fast jede PSI- Frage verwirrend; wenn Sie beide getrennt halten, ergibt alles Sinn.

Felddaten: Was echte Nutzer erlebt haben

Der obere Abschnitt — “Discover what your real users are experiencing” (Übersetzung) „So erleben echte Nutzer Ihre Website“ — wird vom Chrome UX Report (CrUX) unterstützt. web.dev beschreibt die CrUX-API als Bereitstellung von “low-latency access to aggregated real-user experience data at page and origin granularity” (Übersetzung) „Zugriff mit geringer Latenz auf aggregierte Echtnutzerdaten auf Seiten- und Ursprungsebene“ als “28-day rolling average.” (Übersetzung) „gleitender 28-Tage-Durchschnitt“. PSI wird täglich aktualisiert; der BigQuery-CrUX- Datensatz wird monatlich veröffentlicht.

Einige Mechanismen, die wichtig sind:

• Die Core Web Vitals Bewertung ist bei p75 bestanden/nicht bestanden. Laut Chromes Dokumentation: “to pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals. Otherwise, the assessment appears as ‘failed’.” (Übersetzung) „Zum Bestehen muss das Perzentil bei allen drei Core Web Vitals als ‚gut‘ eingestuft sein. Andernfalls erscheint die Bewertung als ‚nicht bestanden‘.“ Die drei sind Largest Contentful Paint (gut < 2,5 s), Interaction to Next Paint (gut < 200ms) und Cumulative Layout Shift (gut < 0,1). PSI zeigt auch FCP und TTFB als “Weitere Metriken” — informativ, aber nicht Teil des Urteils.
• Es gibt eine dokumentierte Ausnahme, und sie betrifft nur INP. Wenn eine Seite nicht genügend CrUX-Stichproben hat, um INP speziell zu melden, sagt der aktuelle PSI-Leitfaden, dass sie dennoch Bestanden/Nicht bestanden aus guten LCP- und CLS-p75-Werten allein bewerten kann. Es gibt keine entsprechende Ausnahme für LCP oder CLS — wenn eine dieser Metriken diejenige ist, für die nicht genügend Daten vorliegen, interpretieren Sie das nicht als Bestanden; unzureichende Daten sind kein dokumentierter Freibrief für irgendeine Metrik außer INP.
• p75 bedeutet das 75. Perzentil. Der angezeigte Wert ist die Erfahrung, die 75 % der Seitenaufrufe schneller waren. web.dev wählte das 75. Perzentil, damit die Zahl “resistant to outliers” (Übersetzung) „robust gegenüber Ausreißern“ ist — ein strengeres Ziel als ein Median.
• INP ersetzte FID im März 2024. Wenn Sie sich alte Screenshots oder alte Leitfäden ansehen (einschließlich meiner eigenen älteren Ahrefs-Artikel über PageSpeed Insights und Core Web Vitals), zeigen diese möglicherweise noch FID; die Bewertung verwendet jetzt INP.
• URL → Ursprung → “Keine Daten”-Fallback. Wenn nicht genügend CrUX-Daten für die spezifische URL vorhanden sind, fällt PSI auf Ursprungsebene-Daten zurück (aggregiert über die gesamte Website). Wenn überhaupt keine CrUX-Daten vorhanden sind, sehen Sie “Keine Daten,” aber Lighthouse läuft trotzdem. Wie web.dev anmerkt, “CrUX data is only available when sites meet certain eligibility criteria” (Übersetzung) „CrUX-Daten sind nur verfügbar, wenn Websites bestimmte Teilnahmevoraussetzungen erfüllen“ und “PSI is only available for public URLs.” (Übersetzung) „PSI ist nur für öffentliche URLs verfügbar.“ Seiten mit geringem Traffic und brandneue Seiten haben häufig keine URL-Ebene-Felddaten.

Lesen Sie das Umfang-Label, bevor Sie das Ergebnis schreiben. URL-Ebene-CrUX beschreibt die berechtigte Feldstichprobe, die dieser URL zugeordnet ist. Der Fallback auf Ursprungsebene ist ein nützliches Website-weites Signal, kann aber die getestete Seite allein nicht diagnostizieren. “Keine Daten” bedeutet, dass die Feldstichprobe nicht verfügbar oder unzureichend ist — nicht, dass die Seite bestanden, nicht bestanden oder keinen Traffic erhalten hat. Das Lighthouse-Ergebnis unten kann diesen kontrollierten Laborlauf weiterhin diagnostizieren, füllt aber nicht die fehlende Felddatenlücke.

Labordaten: Der 0–100 Lighthouse-Score

Der untere Abschnitt ist eine einzelne Lighthouse-Ausführung auf einem simulierten Gerät und Netzwerk, die den Performance-Score und eine Liste von Chancen und Diagnosen erzeugt. Googles Einteilung: “A score of 90 or above is considered good. 50 to 89 is a score that needs improvement, and below 50 is considered poor.” (Übersetzung) „Ein Score von 90 oder mehr gilt als gut. 50 bis 89 gelten als verbesserungswürdig, und ein Wert unter 50 als schlecht.“

Was Sie über den Laborlauf wissen sollten:

• Es ist simuliert, und der mobile Lauf ist bewusst langsam. Mobile emuliert ein Mittelklasse-Telefon mit einer gedrosselten Verbindung; Desktop verwendet ein schnelleres emuliertes Profil. Deshalb ist Ihr mobiler Score fast immer niedriger als der Desktop-Score – und deshalb sehen echte Nutzerdaten (Field Data) oft besser aus, als die Labordiagnosen vermuten lassen.
• Der Score ist variabel. Jeder Lauf ist ein frischer, serverseitiger Lighthouse-Audit – die Seite, das Google-Rechenzentrum, die Netzwerkbedingungen und sogar die Chrome-/Lighthouse-Version können die Zahl zwischen den Läufen verändern. Ich empfehle, den Test mehrmals (3–5) auszuführen und sich den Bereich anzusehen, anstatt einen einzelnen Lauf als unumstößlich zu betrachten. Ein paar Punkte Schwankung sind Rauschen.
• Wenn Sie Läufe vergleichen, speichern Sie mehr als nur den Score. Die API-Antwort enthält einen Zeitstempel, die angeforderte und endgültige URL, den Formfaktor, die emulierte Umgebung, die Lighthouse-Version und etwaige Warnungen – bewahren Sie diese zusammen mit jedem Score auf. Zwei „72er“ sind nicht vergleichbar, wenn einer auf einer anderen Lighthouse-Version lief oder eine Weiterleitung traf, die der andere nicht hatte. Mitteln Sie keine unbeschrifteten Scores; versehen Sie jeden Lauf mit einem Label oder verzichten Sie auf den Vergleich.
• Lighthouse-Versionen entwickeln sich unabhängig von der PSI-API. PSI blieb bei API v5, aber die darunterliegende Lighthouse-Engine veröffentlicht weiterhin neue Releases (das neueste, das in den Google-Release-Notes zum Zeitpunkt dieser Überprüfung erwähnt wird, ist Lighthouse 13.0, datiert auf 2025-10-20) – Audit-Felder, Gewichtungen und Bewertungsstufen können sich mit der Engine-Version ändern, auch wenn sich der API-Vertrag nicht ändert.
• „Geschätzte Einsparungen“ sind nicht additiv. Die Sekunden, die neben jeder Diagnose angezeigt werden, gehen davon aus, dass diese Optimierung isoliert vorgenommen wird. Probleme interagieren; reale Gewinne sind fast immer geringer als die Summe der einzelnen Schätzungen. Behandeln Sie diese Angaben als richtungsweisend, nicht als Budget, das Sie aufsummieren können.
• Die Metrik-Gewichtungen ändern sich mit den Lighthouse-Versionen. Der Performance-Score ist eine gewichtete Mischung aus Labor-Metriken (Ladezeit-Metriken, Total Blocking Time und CLS haben das größte Gewicht), aber die genauen Gewichtungen verschieben sich zwischen Lighthouse-Releases – prüfen Sie den aktuellen Scoring-Rechner, anstatt einer festen Aufteilung zu vertrauen.

Der Mythos, der den meisten Schaden anrichtet: „Der Score ist ein Ranking-Faktor“

Das ist er nicht. Der Performance-Score von 0–100 ist eine Lighthouse-Laborkennzahl, und ich habe keine aktuelle offizielle Google-Suche-Quelle gefunden, die diesen Score selbst als Ranking-Eingabe dokumentiert oder eine Score-Änderung mit einer Ranking-Änderung verknüpft. Googles Dokumentation zur Seitenerfahrung verweist stattdessen auf Field Core Web Vitals – CrUX-basierte Echtnutzerdaten, dieselbe Art von Daten, die der Field-Bereich von PSI bei p75 anzeigt. (Eine Einschränkung, die präzise sein sollte: Die öffentliche Field-Anzeige von PSI ist eine Berichtsoberfläche mit eigenen Berechtigungs- und Fallback-Regeln; Google hat die genauen internen Pipelines, die das Ranking speisen, nicht veröffentlicht, also behandeln Sie „Field-Daten“ als dieselbe Art von Signal, anstatt eine bytegenaue Identität mit dem anzunehmen, was PSI Ihnen zeigt.) Eine Seite kann im Labor bei 72 liegen und die Core Web Vitals Assessment dennoch bestehen, weil ihre Echtnutzerdaten gut sind – verschiedene Zahlen aus verschiedenen Systemen. Der korollare Mythos – „ein guter Labor-Score entspricht einer guten Echtnutzererfahrung“ – scheitert aus demselben Grund: Laborbedingungen sind nicht die Bedingungen Ihrer Besucher. Wenn Field- und Labordaten divergieren, sind Field-Daten für SEO relevanter.

Und selbst die Field Core Web Vitals sind ein relativ kleiner Ranking-Eingang. Googles eigene Leute haben sie heruntergespielt – Gary Illyes hat Seitenerfahrung eher als Tiebreaker denn als großes Signal bezeichnet. Meine ehrliche Position hat sich nicht geändert: Ich glaube nicht, dass Core Web Vitals viel Einfluss auf SEO haben, und außer eine Website ist extrem langsam, werde ich ihre Behebung im Allgemeinen nicht über Inhalte und Links priorisieren. Beheben Sie entsprechende Probleme für Nutzer und für den wirklich langsamen Fall – nicht aus Panik über eine rote Zahl.

So lesen Sie einen PSI-Bericht tatsächlich

1. Lesen Sie zuerst die Felddaten. Bestehen sie die Core Web Vitals Bewertung mit Bestanden oder Nicht bestanden? Das ist das für SEO relevante Urteil. Wenn dort „Keine Daten“ steht, gibt es noch nicht genügend CrUX-Traffic – Sie arbeiten nur mit Labordaten.
2. Prüfen Sie Mobil und Desktop getrennt. Mobil ist der Standard und in der Regel die schwächere Variante; es ist auch das, was am meisten zählt, da Google mobil zuerst indexiert.
3. Nutzen Sie dann die Labordiagnosen, um die Ursache zu finden. Labordaten sind Ihre schnelle Feedback-Schleife, um das Kernproblem zu finden und zu beheben – renderblockierende Ressourcen, überdimensionierte Bilder, Quellen für Layout-Verschiebungen, lange Aufgaben.
4. Beheben, dann warten. Felddaten sind ein rollierendes 28-Tage-Fenster, daher kann eine heute veröffentlichte Korrektur bis zu 28 Tage dauern, bis sie vollständig in der Core Web Vitals Bewertung erscheint. Nutzen Sie Labordaten, um die Korrektur sofort zu bestätigen; nutzen Sie Felddaten, um zu bestätigen, dass sie tatsächlich echte Nutzer beeinflusst hat.
5. Vergleichen Sie mit Wettbewerbern. Da PSI auf jeder öffentlichen URL funktioniert, können Sie die Seiten eines Wettbewerbers ausführen und deren Feld-Core-Web-Vitals mit Ihren vergleichen – ein Anwendungsfall, den die meisten Anleitungen nie erwähnen.

PSI im Vergleich zu den Tools, mit denen es verwechselt wird

• PSI vs. Lighthouse. Lighthouse ist die Engine; PSI ist eine Web-UI, die Lighthouse ausführt und CrUX-Felddaten darüberlegt. Wenn Sie Lighthouse selbst ausführen (in Chrome DevTools oder der CLI), erhalten Sie das Labor-Audit, aber auf Ihrem Rechner und Netzwerk, ohne Felddaten.
• PSI vs. Core Web Vitals Bericht der Search Console. Beide basieren auf CrUX, daher spiegeln beide echte Nutzer wider. Der Unterschied: Die Search Console gruppiert ähnliche URLs und berichtet in großem Maßstab über Ihre gesamte Property, während PSI pro URL (oder mit Fallback auf Ursprungsebene) arbeitet. Wenn GSC und PSI unterschiedlich erscheinen, liegt es meist an der Gruppierung.
• PSI vs. Chrome DevTools / WebPageTest / DebugBear / Ahrefs Site Audit. Diese bieten mehr Konfiguration (benutzerdefinierte Geräte, Standorte, Drosselung) und in einigen Fällen Echtzeit-Nutzerüberwachung. Die Stärke von PSI ist, dass es kostenlos, ohne Einrichtung und an Googles eigenen CrUX-Datensatz gebunden ist.

Die PSI-API (für Massentests)

Sie müssen nicht die Web-UI URL für URL verwenden. Die PageSpeed Insights API (Basis https://www.googleapis.com/pagespeedonline/v5) liefert dieselben Daten programmatisch. Wichtige Parameter: url (erforderlich), strategy (mobile oder desktop) und category (performance, accessibility, best-practices, seo). Die Antwort ist genauso aufgeteilt wie die UI: loadingExperience (URL-Ebene Felddaten), originLoadingExperience (Felddaten auf Ursprungsebene) und lighthouseResult (das Labor-Audit). So testen Sie eine Reihe von URLs nach Zeitplan, anstatt sie manuell durchzuklicken.

Bauen Sie keine dauerhafte Felddaten-Automatisierung auf dieser API auf. Googles eigene API-Dokumentation beginnt jetzt mit einem Hinweis, dass geplant ist, CrUX-Echtzeitdaten aus der PSI-API zu entfernen, und verweist Automatisierer auf die dedizierte CrUX-API oder CrUX History API. Verwenden Sie die PSI-API weiterhin für das Lighthouse-Labor-Audit – dieser Teil ist nicht betroffen – aber wenn Sie geplante Felddatenabrufe planen, bauen Sie auf einer CrUX-spezifischen API auf, nicht auf loadingExperience/originLoadingExperience in der PSI-Antwort.

Wo dies in der Web-Performance einzuordnen ist

PSI ist ein Messwerkzeug, nicht das Ziel. Die Metriken, die es anzeigt – Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift – sind die Core Web Vitals, und der Hub für diese (Schwellenwerte, was jede bedeutet und wie man sie verbessert) ist der nächste Anlaufpunkt. Lighthouse ist die Labor-Engine, auf der PSI läuft; CrUX (der Chrome UX Report) ist die Felddatenquelle im oberen Bereich jedes PSI-Berichts. Wenn Sie alle drei Systeme verstehen, ist PSI keine Blackbox mehr.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• PSI = zwei Tools in einer Oberfläche. Felddaten aus dem Chrome UX Report (echte Nutzer) und Labordaten aus einem einzelnen Lighthouse-Lauf, für dieselbe URL, unter pagespeed.web.dev. Kostenlos, ohne Anmeldung, jede öffentliche URL, mobil + Desktop.
• Felddaten treiben die Core Web Vitals-Bewertung an – Bestanden/Nicht bestanden, beim 75. Perzentil, über LCP (<2,5 s), INP (<200ms) und CLS (<0,1). Gleitendes 28-Tage-Fenster, täglich aktualisiert. FCP und TTFB werden angezeigt, zählen aber nicht für das Urteil.
• Labordaten sind der 0–100-Leistungswert (90+ gut, 50–89 Verbesserung nötig, <50 schlecht) plus Diagnosen. Mobil wird gedrosselt und erzielt niedrigere Werte als Desktop.
• Der 0–100-Wert ist NICHT als Ranking-Faktor dokumentiert. Die Ranking-Systeme von Google verwenden Feld-Core Web Vitals (CrUX-basierte Echtnutzerdaten – dieselbe Art von Daten, die der Feldbereich von PSI zeigt, obwohl Google die genaue interne Pipeline nicht als identisch mit der öffentlichen Anzeige von PSI veröffentlicht hat). Eine Seite kann 72 erreichen und trotzdem CWV bestehen – unterschiedliche Zahlen aus unterschiedlichen Systemen.
• CrUX-Fallback: URL-Ebene → Ursprungs-Ebene → „Keine Daten“ (Lighthouse läuft trotzdem). Seiten mit geringem Traffic und neue Seiten haben oft keine Felddaten auf URL-Ebene.
• Der Wert ist variabel von Lauf zu Lauf – führen Sie 3–5 Läufe durch. „Geschätzte Einsparungen“ sind nicht additiv. Sie brauchen keine 100.
• Lesen Sie zuerst die Felddaten (Bestanden/Nicht bestanden), dann nutzen Sie Labordiagnosen, um die Ursache zu finden; liefern Sie den Fix aus, dann warten Sie bis zu 28 Tage, bis die Felddaten ihn widerspiegeln.
• PSI vs. Lighthouse (Engine vs. Oberfläche+Feld) und vs. Search Console CWV-Bericht (ebenfalls CrUX, aber in großem Maßstab gruppiert). CWV ist insgesamt ein geringer Ranking-Eingang.

Offizielle Dokumentation

Primärquellen-Dokumentation von Google und den Chrome-/web.dev-Teams.

Google / PageSpeed Insights

• PageSpeed Insights-Tool – das Tool selbst.
• PageSpeed Insights API – Über – was PSI tut, die zwei Datentypen und die 0–100-Wertbereiche.
• PSI API – runPagespeed-Referenz – Parameter (url, strategy, category) und die Antwortstruktur.

Chrome UX Report (die Felddatenquelle)

• CrUX in PageSpeed Insights verwenden – wie der Feldbereich funktioniert und die Bestanden/Nicht bestanden-Bewertung.
• CrUX-Methodik – Berechtigung, Opt-in und welche Seiten enthalten sind.
• CrUX API – der gleitende 28-Tage-Durchschnitt, der die Felddaten von PSI speist.
• CrUX-Überblick – wie CrUX das Page-Experience-Ranking-Signal speist.

web.dev / Core Web Vitals

• Was sind die Core Web Vitals-Tools? – wo PSI in die CrUX/Lighthouse-Tooling passt.
• Core Web Vitals – die LCP/INP/CLS-Schwellenwerte und die 75-Perzentil-Regel.
• Definition der Core Web Vitals-Schwellenwerte – warum p75.
• Core Web Vitals & Google Search – der Ranking-Signal-Kontext.

Zitate aus der Quelle

Wörtliche Aussagen, jeweils verlinkt zur Passage auf der Quellseite.

Google / Chrome / web.dev – wie PSI funktioniert

• “PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page.” (Übersetzung) „PSI ist ein Tool, das Felddaten aus CrUX und Labordaten aus Lighthouse für eine bestimmte Seite meldet.“ — web.dev. Zum Zitat springen
• “PSI is only available for public URLs. It cannot be used on development sites that are not publicly accessible.” (Übersetzung) „PSI ist nur für öffentliche URLs verfügbar. Es kann nicht für Entwicklungsumgebungen verwendet werden, die nicht öffentlich zugänglich sind.“ — web.dev. Zum Zitat springen
• Der Feldabschnitt wird beschrieben als “Discover what your real users are experiencing.” (Übersetzung) „Entdecken Sie, was Ihre echten Nutzer erleben.“ — Chrome-Entwicklerdokumentation, CrUX in PSI. Zum Zitat springen
• “To pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals. Otherwise, the assessment appears as ‘failed’.” (Übersetzung) „Um zu bestehen, muss das Perzentil in allen drei Core Web Vitals als ‚gut‘ eingestuft werden. Andernfalls wird die Bewertung als ‚fehlgeschlagen‘ angezeigt.“ — Chrome-Entwicklerdokumentation, CrUX in PSI. Zum Zitat springen
• Die CrUX-API bietet “low-latency access to aggregated real-user experience data at page and origin granularity” (Übersetzung) „Zugriff mit geringer Latenz auf aggregierte Daten zur Erfahrung echter Nutzer auf Seiten- und Ursprungs-Ebene“ als “28-day rolling average.” (Übersetzung) „gleitenden 28-Tage-Durchschnitt“. — Chrome-Entwicklerdokumentation zur CrUX API. Zum Zitat springen

web.dev — Schwellenwerte

• “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” (Übersetzung) „Ein guter Schwellenwert zur Messung ist das 75. Perzentil der Seitenaufrufe, aufgeteilt nach mobilen und Desktop-Geräten.“ — web.dev, Core Web Vitals. Zum Zitat springen
• “if at least 75 percent of page views to a site meet the ‘good’ threshold, the site is classified as having ‘good’ performance.” (Übersetzung) „Wenn mindestens 75 Prozent der Seitenaufrufe einer Website den Schwellenwert ‚gut‘ erreichen, wird die Website als ‚gut‘ in Bezug auf die Leistung eingestuft.“ — web.dev, Definition der Schwellenwerte. Zum Zitat springen

Branche — die Unterscheidung zwischen Score und Ranking (weitergegeben, nicht von Google)

• “The Performance score on PageSpeed Insights does not impact SEO directly. However, the real-user Core Web Vitals assessment does impact Google rankings.” (Übersetzung) „Der Performance-Score in PageSpeed Insights wirkt sich nicht direkt auf SEO aus. Die Bewertung der Core Web Vitals auf Basis echter Nutzer wirkt sich jedoch auf das Google-Ranking aus.“ — Matt Zeunert, DebugBear. Quelle
• “Core Web Vitals are the only metrics Google explicitly uses for grading.” (Übersetzung) „Core Web Vitals sind die einzigen Metriken, die Google explizit zur Bewertung verwendet.“ und “Running the same URL just minutes apart can yield different scores.” (Übersetzung) „Wenn Sie dieselbe URL nur wenige Minuten später ausführen, können unterschiedliche Ergebnisse erzielt werden.“ — Ryan Sullivan, SiteCare. Quelle

PSI-Bericht-Spickzettel

Jeder PSI-Abschnitt: Feld vs. Labor, und was er bedeutet

Core Web Vitals „gut”-Schwellenwerte (Feld, p75)

Lighthouse-Score-Bereiche (Labor)

• 90–100 — gut · 50–89 — verbesserungswürdig · <50 — schlecht

Fallback auf Felddaten

• URL-Ebene CrUX → falls nicht genügend, Origin-Ebene → falls keine, „Keine Daten“ (Lighthouse läuft trotzdem).

Schnelle Fakten

• Felddaten = rollierende 28 Tage, täglich aktualisiert → eine Korrektur kann bis zu 28 Tage brauchen, bis sie sichtbar wird.
• Der 0–100-Score ist variabel — führen Sie 3–5 Läufe durch, ignorieren Sie eine Schwankung von 3–5 Punkten.
• „Geschätzte Einsparungen“ summieren sich nicht — sie gehen davon aus, dass jede Korrektur einzeln vorgenommen wird.
• Mobil ist der Standard-Tab und schneidet normalerweise schlechter ab als Desktop.
• INP ersetzte FID im März 2024.

Tools rund um PSI

• PageSpeed Insights (pagespeed.web.dev) — das Tool selbst: Felddaten (CrUX) + Lab (Lighthouse), mobil und Desktop, jede öffentliche URL.
• Google Lighthouse — die Lab-Engine, die PSI ausführt. Führen Sie es lokal in Chrome DevTools (Lighthouse-Bereich) oder über die CLI für den Lab-Audit auf Ihrem eigenen Gerät/Netzwerk aus (keine Felddaten).
• Google Search Console — Core Web Vitals-Bericht — die andere CrUX-basierte Ansicht; gruppiert ähnliche URLs und meldet Felddaten für Ihre gesamte Property.
• CrUX Vis / CrUX API / BigQuery — gehen Sie direkt zu den Felddaten hinter PSI für Trends über die Zeit. (Das alte CrUX-Dashboard in Looker Studio wurde Ende November 2025 eingestellt — Googles eigene Versionshinweise und der spezielle Einstellungsbeitrag bestätigen beide das Datum und verweisen auf CrUX Vis (cruxvis.withgoogle.com) als Ersatz. Wenn ein Leitfaden Ihnen immer noch sagt, Sie sollen das Dashboard verwenden, ist er veraltet.)
• PSI API — testen Sie viele URLs programmatisch in großen Mengen (url, strategy, category); die Antwort teilt sich in loadingExperience, originLoadingExperience, und lighthouseResult. Google hat angekündigt, die Einbeziehung von CrUX-Echtdaten in dieser API einzustellen und empfiehlt nun die dedizierte CrUX API oder CrUX History API für dauerhafte Felddaten-Automatisierung — bauen Sie keine Pipeline, die davon ausgeht, dass die Feldobjekte der PSI API langfristig bestehen bleiben.
• Ahrefs Site Audit und WebPageTest / DebugBear — mehr Konfiguration und in einigen Fällen Echtbenutzer-Überwachung über einen einzelnen Lighthouse-Lauf hinaus.

PageSpeed Insights-Fehler, die Prioritäten verzerren

• Den 0–100-Score als Ranking-Faktor behandeln. Der Score ist ein einzelner Lighthouse-Lab- Lauf. Die rankingrelevante Core Web Vitals-Bewertung stammt aus CrUX-Felddaten.
• Origin-Fallback als URL-Leistung lesen. Wenn einer URL nicht genügend Stichproben fehlen, kann PSI Daten auf Origin-Ebene anzeigen. Überprüfen Sie das Bereichs-Label, bevor Sie behaupten, die Seite selbst habe bestanden oder nicht bestanden.
• Auf einen einzelnen Lab-Lauf reagieren. Serverantwort und die synthetische Umgebung variieren. Wiederholen Sie passende Läufe und verwenden Sie den Bereich oder Median, um Signal von Rauschen zu unterscheiden.
• Opportunity-Einsparungen zusammenzählen. Audit-Schätzungen überlappen sich und gehen davon aus, dass jede Korrektur unabhängig erfolgt. Verwenden Sie diese Angaben als Richtungshinweise, nicht als versprochene Summe.
• Erwarten, dass ein Deployment Felddaten sofort ändert. CrUX ist eine rollierende 28-Tage-Ansicht. Verwenden Sie den Lab-Bereich für sofortige Diagnose und den Feldbereich für Bestätigung über die Zeit.
• Mobile und Desktop-Scores vergleichen, als ob die Bedingungen gleich wären. Bewerten Sie jedes Profil gegen sich selbst und Ihre Zielgruppe, anstatt die Zahlen als eine Skala zu behandeln.

PSI sagt „Keine Daten“

Symptom: Der Feldbereich hat kein CrUX-Ergebnis, aber der Lighthouse-Bericht läuft.

Wahrscheinliche Ursache: Die URL und der Origin erfüllen nicht die CrUX-Berechtigungs- oder Stichprobenumfangs- anforderungen, oder die Seite ist neu oder hat wenig Traffic.

Behebung und Bestätigung: Erfinden Sie keine Feld-Schlussfolgerung. Verwenden Sie Lab-Diagnosen für sofortige Arbeit, prüfen Sie repräsentative Vorlagen mit höherem Traffic und kehren Sie später zurück, um zu sehen, ob ein Feld-Ergebnis auf URL- oder Origin-Ebene erscheint.

PSI und Search Console widersprechen sich

Symptom: Eine URL sieht in PSI gesund aus, während ihre Search Console-Gruppe schlecht ist, oder umgekehrt.

Wahrscheinliche Ursache: PSI kann Daten auf URL- oder Origin-Ebene anzeigen, während Search Console ähnliche URLs gruppiert. Gerät, Bereich und Zeitpunkt des rollierenden Fensters können ebenfalls abweichen.

Behebung und Bestätigung: Mobil/Desktop abgleichen, den Datenbereich von PSI prüfen und mehrere URLs aus der Search Console-Gruppe stichprobenartig testen, bevor Sie schlussfolgern, dass einer der Berichte falsch ist.

Der Lab-Score schwankt zwischen den Läufen

Symptom: Wiederholtes Ausführen von PSI liefert deutlich unterschiedliche Scores oder Metrikwerte.

Wahrscheinliche Ursache: Eine variable Serverantwort, eine Drittanbieter-Anfrage oder normales Rauschen bei einzelnen Lab-Läufen hat die Spur verändert.

Behebung und Bestätigung: Führen Sie dieselbe Strategie mehrmals aus, vergleichen Sie einzelne Metriken und Request-Wasserfälle und untersuchen Sie einen wiederkehrenden Engpass statt nur den Score.

Eine Korrektur ist in Lighthouse sichtbar, aber nicht in den Felddaten

Symptom: Die Lab-Metrik verbessert sich sofort, während die Feldbewertung der Core Web Vitals unverändert bleibt.

Wahrscheinliche Ursache: CrUX enthält weiterhin Besuche vor dem Release im rollierenden 28-Tage-Fenster, oder die Korrektur hat den Nutzern und Vorlagen, die im Felddatensatz repräsentiert sind, nicht geholfen.

Behebung und Bestätigung: Überprüfen Sie jetzt die Bereitstellung und die Lab-Spur, dokumentieren Sie das Releasedatum und beobachten Sie dann die Feldverteilung über das gesamte Berichtsfenster.

Ein PSI-Ergebnis aus der API abrufen

Die API stellt Feld- und Lab-Abschnitte getrennt bereit. Geben Sie Ihren eigenen API-Schlüssel und Ihre URL an:

curl --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode "url=$TARGET_URL" \
  --data 'strategy=mobile' \
  --data-urlencode "key=$PSI_KEY" \
  --output psi.json

Bewahren Sie die Rohantwort auf, damit Testdatum, Strategie und Datenbereich prüfbar bleiben.

Feldbereich vom Lab-Score trennen

Mit jq extrahieren Sie die URL-Feldkategorie, die Origin-Fallback-Kategorie und den Lighthouse-Score, statt sie in einer Zahl zusammenzufassen:

jq '{
  url_field: .loadingExperience.overall_category,
  origin_field: .originLoadingExperience.overall_category,
  lab_score: (.lighthouseResult.categories.performance.score * 100)
}' psi.json

Ein fehlender Feldwert ist keine Null; er bedeutet, dass dieser Bereich in der Antwort nicht verfügbar war.

Den Lab-Lauf wiederholen, ohne die Stichproben zu verbergen

for run in 1 2 3; do
  curl --silent --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
    --data-urlencode "url=$TARGET_URL" \
    --data 'strategy=mobile' \
    --data-urlencode "key=$PSI_KEY" \
  | jq -r "[$run, (.lighthouseResult.categories.performance.score * 100)] | @tsv"
done

Berichten Sie alle Stichproben oder eine dokumentierte Zusammenfassung; wählen Sie nicht nur den besten Score aus.

Testen Sie sich selbst: PageSpeed Insights

Fünf kurze Fragen zum korrekten Lesen von PSI. Wählen Sie für jede eine Antwort und prüfen Sie dann.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• Google PageSpeed Insights: A Beginner-Friendly Guide — meine Ahrefs-Erläuterung (Hinweis: Sie stammt aus der Zeit vor dem FID→INP-Wechsel).
• Core Web Vitals: A Complete Guide — Feld vs. Lab und meine Einschätzung, wie viel CWV tatsächlich ausmacht.
• The Beginner’s Guide to Technical SEO — wo Performance im größeren Zusammenhang steht.

Offiziell

• CrUX in PageSpeed Insights verwenden — Chromes eigene Erläuterung des Feldabschnitts.
• Was sind die Core-Web-Vitals-Tools? — wie PSI, Lighthouse, CrUX und Search Console zusammenhängen.

Von anderen

• How To Use PageSpeed Insights — Matt Zeunert (DebugBear); starke technische Tiefe zu Score und Diagnose.
• PageSpeed Insights: Google’s Highly Misunderstood Diagnostic Tool — Ryan Sullivan (SiteCare); gute Mythenentlarvung.
• Core Web Vitals als Ranking-Faktor: mehr als nur ein Tiebreaker — Berichterstattung des Search Engine Journal über Gary Illyes’ Kommentare zur Einordnung der Auswirkungen von CWV.
• Google Page Experience Update Is More Than A Tie Breaker — SE Roundtable; Barry Schwartz’ Berichterstattung darüber, wie Google-Vertreter das Page-Experience-Signal charakterisiert haben.

Statistiken, die sich zu zitieren lohnen

• Fast niemand erreicht 100 Punkte. Nur etwa 2 % der getesteten Seiten erreichen eine perfekte 100, und ein Wert von 50 liegt bereits in den Top 25 % – ein nützlicher Kontext für alle, die bei einer Zahl unter 90 in Panik geraten. Quelle
• Felddaten sind ein 28-Tage-gleitender Durchschnitt. Eine Korrektur kann bis zu ~28 Tage dauern, bis sie vollständig in der Core Web Vitals-Bewertung berücksichtigt wird – nutzen Sie in der Zwischenzeit Labordaten für schnelles Feedback. Quelle
• Der Schwellenwert für „gut“ ist das 75. Perzentil. Google bewertet bei p75, sodass „eine Mehrheit der Besuche das angestrebte Leistungsniveau erreicht hat“ – das bedeutet, selbst bei einem bestandenen LCP von 2,5 s wartete ein Viertel der Besucher länger. Quelle

Änderungsprotokoll