Chrome User Experience Report (CrUX)

TL;DR — CrUX ist Googles Sammlung von Geschwindigkeitsdaten aus der realen Welt, die von tatsächlichen Chrome-Nutzern stammen. Es sind die Daten, mit denen Google deine Core Web Vitals bewertet – nicht der Laborwert, den ein Tool wie Lighthouse auf einem einzelnen Testgerät erzeugt. Deshalb kann dein Lighthouse-Wert grün sein, während die Search Console Handlungsbedarf meldet: Beide messen unterschiedliche Dinge.

Was CrUX ist

Der Chrome User Experience Report – kurz CrUX – ist ein kostenloser Datensatz, den Google veröffentlicht und der zeigt, wie echte Menschen Websites auf echten Geräten und in echten Netzwerken erleben. Statt eine Seite einmal im Labor zu testen, sammelt CrUX Messungen von vielen tatsächlichen Chrome-Nutzern und berichtet das Ergebnis.

Das nennt man Felddaten (manchmal auch „Real-User-Daten“). Das Gegenstück sind Labordaten, wie sie ein Tool wie Lighthouse erzeugt, indem es deine Seite einmal auf einem kontrollierten Testgerät lädt. Beides ist nützlich, aber nur eines davon verwendet Google, um deine Website zu bewerten.

Warum das wichtig ist

CrUX ist der offizielle Datensatz hinter dem Programm Core Web Vitals. Googles Rankingsysteme verwenden die aus echten Nutzer-Felddaten gemessenen Core Web Vitals, nicht einen Lighthouse-Laborwert. Wenn du also immer nur auf deine Lighthouse-Zahl schaust, betrachtest du möglicherweise genau das Falsche.

Du hast CrUX wahrscheinlich schon gesehen, ohne es zu wissen. Der Abschnitt „Entdecke, was deine echten Nutzer erleben“ oben in PageSpeed Insights ist CrUX. Der Core-Web-Vitals-Bericht der Search Console ist CrUX. Das sind die Zahlen, die zählen.

Der häufigste Denkfehler

Ein guter Lighthouse-Wert bedeutet nicht, dass deine Core Web Vitals gut sind. Lighthouse läuft einmal auf einem simulierten Gerät, mit gedrosseltem Netzwerk und leerem Cache. Deine echten Besucher nutzen eine Mischung aus Smartphones, Laptops, schnellen und langsamen Verbindungen sowie nahen und entfernten Standorten. CrUX bildet dieses Durcheinander ab; Lighthouse tut das nicht. Eine Seite kann in Lighthouse 95 erreichen und in CrUX trotzdem „Schlecht“ anzeigen, wenn die meisten deiner echten Nutzer langsam mobil unterwegs sind.

Noch etwas überrascht viele: Nicht jede Seite ist in CrUX enthalten. Eine URL braucht genügend echte Besuche, um aufgenommen zu werden. Viele Seiten mit wenig Traffic haben überhaupt keine CrUX-Daten, daher zeigen Tools stattdessen die Daten deiner gesamten Website („Origin“) an oder melden einfach, dass noch keine Felddaten vorliegen.

Du möchtest die Methodik kennenlernen – das 28-Tage-Fenster, das 75. Perzentil, Origin- gegenüber URL-Daten und alle Wege, CrUX abzurufen? Wechsle zum Tab Fortgeschritten.

TL;DR — CrUX ist der offizielle Chrome User Experience Report: reale Feld-UX-Daten, aggregiert aus berechtigten Chrome-Nutzern – also Nutzern, die Googles Kriterien für Einwilligung, Synchronisierung und unterstützte Plattformen erfüllen – und der Datensatz hinter dem Programm Core Web Vitals. Die Daten werden auf dem 75. Perzentil über ein zurückliegendes 28-Tage-Aggregationsfenster sowohl auf Origin- als auch auf URL-Ebene berichtet. Die Abdeckung ist unvollständig: niemals jeder Chrome-Nutzer und niemals jeder Besucher, sondern nur berechtigte Chrome-Nutzer auf unterstützten Plattformen (kein Chrome auf iOS, kein Edge/Safari/Firefox). Eine Seite braucht außerdem genügend Stichproben, um aufgenommen zu werden; deshalb haben viele URLs mit wenig Traffic keine CrUX-Daten und Tools fallen auf Origin-Ebene oder „keine Daten“ zurück. Sechs Oberflächen stellen CrUX derzeit bereit: PageSpeed Insights, Search Console, die CrUX API (täglich), die History API (wöchentlich), BigQuery (monatlich) und CrUX Vis – prüfe die aktuellen Dokumente, da sich Taktung und Quoten ändern können. CrUX ist Feld; Lighthouse ist Labor – daher weichen die beiden voneinander ab.

CrUX ist die Felddatenschicht der Core Web Vitals

Google beschreibt es klar: “The Chrome User Experience Report … is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (Übersetzung) „Der Chrome User Experience Report … ist ein Datensatz, der widerspiegelt, wie echte Chrome-Nutzer beliebte Ziele im Web erleben.“ Und es ist kein Nebenprojekt – “CrUX is the Google dataset of the Web Vitals program. All user-centric Core Web Vitals metrics are represented.” (Übersetzung) „CrUX bildet Googles Datensatz für das Web-Vitals-Programm; sämtliche nutzerzentrierten Core-Web-Vitals-Metriken sind darin enthalten.“ Die Daten werden “used by Google Search to inform the page experience ranking signal.” (Übersetzung) „von der Google-Suche genutzt, um das Ranking-Signal für die Seitenerfahrung zu informieren.“

Das mentale Modell lautet also: Core Web Vitals sind die Metriken; CrUX ist der Datensatz, in dem sie liegen. Wenn die Suche deine CWV bewertet, liest sie CrUX. Diese eine Tatsache löst den größten Teil der Verwirrung auf dieser Seite.

Wie CrUX Daten sammelt

CrUX basiert auf echten Chrome-Nutzern – aber auf einer bestimmten, berechtigten Teilmenge, nicht auf jedem Chrome-Nutzer und nicht auf jedem Besucher deiner Website. Die Erlebnisse eines Nutzers werden nur aggregiert, wenn alle vier Kriterien erfüllt sind: „Nutzungsstatistiken aktivieren. Den Browserverlauf synchronisieren. Keine Sync-Passphrase eingerichtet haben. Eine unterstützte Plattform verwenden.“

„Unterstützte Plattform“ bedeutet hier sehr viel. Enthalten sind Desktop-Chrome unter Windows, macOS, ChromeOS und Linux sowie Android-Chrome (einschließlich Custom Tabs und WebAPKs). Ausgeschlossen sind Chrome auf iOS, Android WebViews und „andere Chromium-Browser“. Praktisch bedeutet das: Microsoft Edge, Samsung Internet, Safari und Firefox sind überhaupt nicht in CrUX enthalten – ebenso wenig wie irgendein iOS-Browser, weil sie alle WebKit verwenden.

Das ist der blinde Fleck, den du verinnerlichen solltest. Wenn du eine E-Commerce- oder Medienwebsite betreibst, deren Traffic überwiegend von iPhone/Safari kommt, misst CrUX möglicherweise nur eine Minderheit deiner tatsächlichen Zielgruppe. Die Daten sind nicht falsch – sie umfassen nur nicht alle.

Warum manche Seiten keine CrUX-Daten haben

CrUX deckt nicht jede Seite ab, und das führt viele in die Irre. Von Google: „Nicht alle Origins oder Seiten sind im Datensatz vertreten. Für Origins und Seiten gelten getrennte Teilnahmekriterien; vor allem müssen sie öffentlich auffindbar sein und es muss eine ausreichend große Zahl von Besuchern geben, um einen statistisch signifikanten Datensatz zu erstellen.“ Die genaue Popularitätsschwelle wird absichtlich nicht veröffentlicht – behandle jede konkrete Besucherzahl, die du siehst, als inoffizielle Schätzung, nicht als dokumentierte Regel.

Seiten- und Origin-Berechtigung werden getrennt bewertet. Ein Origin kann genügend berechtigten Traffic haben, um berichtet zu werden, auch wenn viele einzelne Seiten das nicht haben – genau deshalb kann eine Domain Origin-Daten anzeigen, während eine bestimmte URL keine hat. Ein fehlendes Ergebnis ist außerdem keine Bewertung: Es bedeutet nur, dass Google für diesen Geltungsbereich keine ausreichend große berechtigte Stichprobe zum Berichten hat. Fehlend ist weder null noch bestanden noch nicht bestanden.

Es gibt auch technische Anforderungen: Die Seite muss nach Weiterleitungen 200 zurückgeben und darf nicht per Header oder Meta-Tag auf noindex gesetzt sein. Außerdem gilt eine 20-%-Regel: „Origins oder Seiten, bei denen mehr als 20 % ihres gesamten Traffics aufgrund nicht berechtigter Dimensionskombinationen ausgeschlossen werden, werden vollständig aus dem Datensatz ausgeschlossen.“

Ich habe gemessen, wie dünn diese Abdeckung wird. In meiner Core-Web-Vitals-Datenstudie habe ich CrUX mit einem Ahrefs-Crawl von 43,66 Millionen Seiten kombiniert. Nur 5,21 Millionen davon – ungefähr 11,9 % – hatten im CrUX-Datensatz vom Januar 2022 mindestens eine Core-Web-Vitals-Metrik. Für den Rest gab es zu wenig Traffic, um die Voraussetzungen zu erfüllen. Das ist der Normalzustand des Webs, kein Fehler.

Wenn eine bestimmte URL keine Daten hat, greifen Tools stufenweise zurück. In PageSpeed Insights: CrUX auf URL-Ebene → bei unzureichenden Daten auf CrUX auf Origin-Ebene zurückfallen → wenn auch dort Daten fehlen, erhältst du keine Felddaten und nur der Lighthouse-Laborabschnitt bleibt. Googles Erklärung, warum fein abgestufte Abfragen häufiger scheitern: “The more fine-grained the request is, for example a specific combination of URL and form factor, the fewer user experiences it will include. This may lead to more frequent ‘not found’ errors.” (Übersetzung) „Je feiner die Anfrage ist, zum Beispiel eine bestimmte Kombination aus URL und Formfaktor, desto weniger Nutzererlebnisse enthält sie. Das kann zu häufigeren ‚nicht gefunden‘-Fehlern führen.“

Wie CrUX aggregiert: 28 Tage und p75

Zwei Zahlen bestimmen, wie CrUX alles berichtet.

Das rollierende 28-Tage-Fenster. “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” (Übersetzung) „Die Daten im Chrome UX Report sind ein gleitender 28-Tage-Durchschnitt aggregierter Metriken.“ Jeder angezeigte Wert ist ein Aggregat der zurückliegenden 28 Tage. Eine von Google genannte Folge: “the collectionPeriod will always show 28-days, even if the data is not for the full 28 days (for example if a page was launched less than 28 days ago).” (Übersetzung) „collectionPeriod zeigt immer 28 Tage an, auch wenn die Daten nicht für die gesamten 28 Tage vorliegen, etwa weil eine Seite vor weniger als 28 Tagen gestartet wurde.“

Die praktische Folge – und ich weise seit Jahren darauf hin – lautet: Korrekturen brauchen Zeit, bis sie sichtbar werden. CrUX liegt ungefähr zwei Tage hinter der Echtzeit zurück und jeder Wert ist ein Aggregat des zurückliegenden Fensters, keine Live-Zahl. Eine Änderung ersetzt die alten Daten daher erst vollständig, wenn genügend neue berechtigte Sitzungen gesammelt wurden und die alten herausfallen. Ein Zeitraum in der Größenordnung eines Monats ist eine vernünftige Faustregel, aber kein fester Countdown: Wie schnell eine Korrektur sichtbar wird, hängt vom Umfang des berechtigten Traffics der Seite oder des Origins, von der Lebensdauer der Metrik und von der für den Datensatz gemeldeten Erfassungsperiode ab. Wie ich in meinem CLS-Leitfaden schreibe: „Es dauert eine Weile, bis die Auswirkungen von Änderungen sichtbar werden.“ Nützlich für die Erwartungssteuerung: Versprich weder Bewegung am ersten Tag noch ein exaktes Datum.

Das 75. Perzentil (p75). CWV werden beim p75 bewertet, nicht beim Median. Googles Definition: „75 % der Seitenaufrufe erlebten die betreffende Metrik bei diesem Wert oder darunter.“ Zum Bestehen müssen also drei von vier Aufrufen beim guten Schwellenwert oder darunter liegen. Ein wichtiger Vorbehalt von Google: Die Perzentilwerte „sind synthetisch abgeleitet; daraus folgt nicht, dass irgendein Nutzer tatsächlich den angegebenen Wert erlebt hat.“ Ein p75 im Bereich „Gut“ bedeutet nicht wörtlich, dass „75 % der Nutzer zufrieden sind“ – es bedeutet, dass 75 % der Seitenaufrufe beim Schwellenwert oder darunter lagen und das oberste Quartil nicht benachteiligt wird, solange das gilt.

Origin-Ebene gegenüber URL-Ebene

CrUX berichtet auf zwei Granularitätsstufen, und der Unterschied ist für SEOs besonders wichtig.

• Origin-Ebene aggregiert „alle für alle Seiten in diesem Origin vorhandenen Daten … zusammen“ – im Wesentlichen den Durchschnitt deiner gesamten Domain.
• URL-Ebene liefert „nur Daten für diese bestimmte URL“.

Diese Werte können stark auseinanderlaufen. Eine Website kann bei CrUX auf Origin-Ebene „Gut“ anzeigen, während eine bestimmte wichtige Landingpage „Schlecht“ ist, weil schnellere Seiten an anderer Stelle den Origin-Durchschnitt ausgleichen. Da PSI auf Origin-Daten zurückfällt, wenn eine URL nicht genügend eigene Daten hat, schaust du möglicherweise auf den Domain-Durchschnitt und glaubst, du würdest die Seite vor dir betrachten.

Meine Datenstudie hat diese Lücke im großen Maßstab gezeigt: In der Stichprobe vom Januar 2022 bestanden etwa 33 % der Websites CWV auf Origin-Ebene, aber nur etwa 21,2 % der einzelnen Seiten. Die Domain-Werte lagen teilweise höher, weil sie wiederholte und gecachte Besuche über die gesamte Website einbeziehen. Behandle diese konkreten Zahlen als datierte Stichprobe eines großen Datensatzes, nicht als aktuelle allgemeingültige Quote – die Grundaussage bleibt aber: Prüfe wichtige Seiten auf URL-Ebene, wann immer diese Daten verfügbar sind, und nimm nicht an, dass ein bestandener Origin jede Seite bestehen lässt.

CrUX teilt außerdem nach Formfaktor auf – PHONE, TABLET und DESKTOP. Google bewertet mit dem passenden Formfaktor, weshalb sich deine mobilen und Desktop-Werte unterscheiden.

Feld- gegenüber Labordaten: Warum dein Lighthouse-Wert nicht übereinstimmt

Das ist die zentrale Spannung, und es lohnt sich, präzise zu sein. Felddaten werden „durch die Überwachung aller Nutzer bestimmt, die eine Seite besuchen, und durch die Messung eines bestimmten Satzes von Leistungsmetriken für die individuellen Erfahrungen jedes einzelnen Nutzers“ – diese allgemeine Kategorie wird auch RUM (Real-User Monitoring) genannt, und CrUX ist eine bestimmte öffentliche Umsetzung davon. Labordaten (Lighthouse) werden „durch das Laden einer Webseite in einer kontrollierten Umgebung mit einer vorgegebenen Reihe von Netzwerk- und Gerätebedingungen bestimmt“.

Sie unterscheiden sich, weil Felddaten „eine große Vielfalt von Netzwerk- und Gerätebedingungen sowie eine Vielzahl verschiedener Arten von Nutzerverhalten einschließen“, während ein Labortest „die Zahl der Variablen absichtlich begrenzt“ – ein Gerät, ein Netzwerk, ein Standort und normalerweise ein kalter Cache. PageSpeed Insights zeigt ausdrücklich beides: oben den CrUX-Feldabschnitt (wonach Google dich bewertet) und darunter den Lighthouse-Laborabschnitt (eine Näherung zum Debuggen). Wie die CrUX-Dokumentation sagt: „CrUX ist eine Sammlung echter Nutzererlebnisse aus dem Feld, während Lighthouse ein kontrollierter Test im Labor ist.“

Wenn dein lokaler Lighthouse-Lauf also 95 meldet, die Search Console aber „Verbesserung erforderlich“, ist nichts kaputt – du vergleichst einen einzelnen sauberen Laboraufruf mit der unordentlichen Realität deiner tatsächlichen Nutzer.

CrUX ist nicht dasselbe wie dein eigenes RUM. Ein privates, erstanbieterbetriebenes RUM-Tool (instrumentiert mit etwas wie der web-vitals-JavaScript-Bibliothek) und CrUX können für dieselbe Seite unterschiedliche Zahlen melden, weil sich Populationen, Einwilligungszustände, Stichproben und Lebensdauern der Metriken unterscheiden. Betrachte die drei Optionen als unterschiedliche Aufgaben:

• CrUX – der kostenlose, öffentliche Maßstab für berechtigte Chrome-Erlebnisse. Verwende ihn, um zu sehen, was Google sieht, und um die Felddaten-Performance eines Wettbewerbers zu prüfen.
• Privates RUM – deine eigene instrumentierte Überwachung. Verwende es, wenn du jeden Browser (nicht nur berechtigtes Chrome), Details pro Nutzer oder Segment oder Echtzeitwarnungen brauchst, die CrUX mit seinem rollierenden Fenster nicht liefern kann.
• Synthetisches Monitoring (Lighthouse, WebPageTest und ähnliche) – ein kontrollierter, wiederholbarer Test. Verwende es für Regressionstests vor einem Release und zur Diagnose, warum eine Feldmetrik schlecht ist, nicht um zu erklären, die Feldmetrik sei behoben.

Für allgemeine Theorie zu Feld- und Labordaten jenseits von CrUX – Optionen für RUM-Tools, Setups für synthetisches Monitoring und das umfassendere Entscheidungsmodell – siehe den Deep Dive Field vs. Lab Data.

Was in CrUX enthalten ist (und was nicht)

Die drei Core Web Vitals sind alle enthalten – Largest Contentful Paint (Ladeleistung), Interaction to Next Paint (Reaktionsfähigkeit) und Cumulative Layout Shift (visuelle Stabilität) – und werden beim p75 anhand dieser Schwellenwerte bewertet:

Neben diesen drei enthält CrUX auch unterstützende Metriken wie FCP (First Contentful Paint), das experimentelle TTFB und RTT (Round Trip Time, das die eingestellte ECT-Dimension im Januar 2025 ersetzt hat) sowie Teilmetriken zum LCP-Bild und Navigationstypen.

Was CrUX nicht enthält, sind reine Labordiagnosen: Total Blocking Time, Speed Index und Time to Interactive gibt es in CrUX nicht – diese Werte erhältst du nur aus Lighthouse. Außerdem gab es eine historische Änderung: INP ersetzte FID im März 2024 als Core Web Vital, und FID wurde im August 2024 aus CrUX entfernt (im September 2024 auch aus BigQuery). Viele ältere Leitfäden erwähnen FID noch – sie sind veraltet.

Sechs Wege, auf CrUX zuzugreifen

Taktung, Quoten und historische Tiefe unten entsprechen dem Stand dieses Textes – Google hat sie schon früher geändert (die kürzliche Abschaffung des CrUX-Dashboards ist ein Beispiel). Betrachte dies daher als Momentaufnahme und prüfe die verlinkten offiziellen Dokumente auf aktuelle Zahlen, bevor du etwas darauf aufbaust.

Einige Einzelheiten sind besonders wissenswert:

• PageSpeed Insights ist der schnellste Blick auf eine einzelne URL. Oben stehen Felddaten, unten Labordaten; kostenlos und ohne API-Schlüssel.
• Der Core-Web-Vitals-Bericht der Search Console gruppiert deine indexierten URLs nach Status (Gut / Verbesserung erforderlich / Schlecht) und trennt Mobil- und Desktop-Ansichten. Weil er Seiten nach Mustern gruppiert, kann eine „Seitengruppe“ schnelle und langsame URLs mischen – daher kann eine Seite in PSI gut aussehen, aber in GSC markiert werden.
• Die CrUX API (POST …/v1/records:queryRecord) liefert das aktuelle 28-Tage-Fenster mit p75-Werten und Histogramm-Bins; frage nach origin oder url ab (gegenseitig ausschließend). Sie ist kostenlos, benötigt einen Google-API-Schlüssel und ist „auf 150 Abfragen pro Minute und Google-Cloud-Projekt begrenzt“.
• Die CrUX History API liefert bis zu 40 Wochen wöchentlicher Snapshots – Trenddaten, ohne BigQuery anzufassen.
• BigQuery ist die Option für große Maßstäbe (Historie bis 2017 und von den APIs nicht bereitgestellte Daten auf Länderebene), aber nur auf Origin-Ebene verfügbar – die Standardtabellen enthalten keine URL-Daten.
• CrUX Vis (cruxvis.withgoogle.com) ist das visuelle Tool. Hinweis: Das alte CrUX-Dashboard in Looker Studio wurde im November 2025 eingestellt – sein Connector wird nicht mehr aktualisiert. Wenn ein Leitfaden noch auf das Dashboard verweist, ist er veraltet; nutze stattdessen CrUX Vis.

Beeinflusst CrUX Rankings?

CrUX ist die Felddatenquelle für das Signal zur Seitenerfahrung, also fließt es in einen Ranking-Input ein – aber ich würde die Erwartungen an den Umfang dämpfen. Meine feste Einschätzung aus meinem Core-Web-Vitals-Leitfaden lautet: „Ich erwarte durch die Verbesserung der Core Web Vitals keine oder nur geringe Rankingverbesserungen“ und „außer wenn du extrem langsam bist, würde ich die Behebung im Allgemeinen nicht priorisieren.“ Der stärkere Grund, sich um deine CrUX-Zahlen zu kümmern, ist Nutzererfahrung, nicht ein Ranking-Schub. Verstehe die Daten, aber gerate nicht in Panik.

Wo das einzuordnen ist

CrUX ist die Felddaten-Engine unter dem Hub Core Web Vitals. Die von ihr gemeldeten Metriken haben jeweils eigene Vertiefungen – Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift – und die beiden wichtigsten Tools, die CrUX anzeigen, sind PageSpeed Insights (Feld + Labor) und Google Lighthouse (nur Labor). Wenn du dir nur eine Sache merkst: Die Trennung von Feld und Labor erklärt, warum ein grüner Laborwert und eine nicht bestandene CWV-Bewertung gleichzeitig wahr sein können.

KI-Zusammenfassung

Eine komprimierte Zusammenfassung der Advanced-Version:

• CrUX = Felddaten und der Datensatz hinter den Core Web Vitals. Wenn Google deine CWV für die Suche bewertet, liest es CrUX – nicht einen Lighthouse-Laborwert.
• Die Erfassung ist auf berechtigte Chrome-Erlebnisse beschränkt – Nutzer, die vier dokumentierte Kriterien erfüllen (Einwilligung, Browserverlauf synchronisiert, keine Sync-Passphrase, unterstützte Plattform), niemals jeder Chrome-Nutzer und niemals jeder Besucher. Kein Chrome auf iOS, keine Android WebViews, kein Edge/Safari/Firefox. Bei Zielgruppen mit viel Safari misst CrUX nur eine Minderheit der echten Nutzer.
• Die Abdeckung ist unvollständig, und die Berechtigung von Seite und Origin wird getrennt bewertet – ein Origin kann sich qualifizieren, auch wenn viele seiner Seiten das nicht tun. Ein fehlendes Ergebnis bedeutet „nicht genügend berechtigte Stichproben zum Berichten“, nicht null und nicht bestanden. In meiner Stichprobe von 43,66 Mio. eindeutigen Site-Audit-Seiten vom Januar 2022 hatten nur etwa 11,9 % mindestens eine Core-Web-Vitals-Metrik in CrUX. Tools fallen zurück: URL → Origin → „keine Daten“ (nur Labor).
• Aggregation = ein zurückliegendes 28-Tage-Fenster beim p75, kein wörtlicher Durchschnitt und keine Live-Zahl. p75 bedeutet, dass 75 % der Aufrufe beim Wert oder darunter lagen; die Werte sind synthetisch abgeleitet. Korrekturen brauchen im Allgemeinen etwa einen Monat, um sichtbar zu werden, aber es gibt keine feste 30-Tage-Garantie – es hängt von berechtigtem Traffic, der Lebensdauer der Metrik und der Verzögerung des Fensters ab.
• Origin gegenüber URL ist wichtig. Origin = Aggregat der gesamten Domain; URL = diese Seite. Sie können auseinanderlaufen – meine Studie ergab, dass etwa 33 % der Websites auf Origin-Ebene bestanden, aber nur etwa 21,2 % der einzelnen Seiten. Prüfe wichtige Seiten auf URL-Ebene.
• Feld gegenüber Labor erklärt, warum Lighthouse (ein einzelner sauberer Laboraufruf) von CrUX (unordentliche echte Nutzer) abweicht. PSI zeigt beides. CrUX selbst ist eine bestimmte öffentliche Form von RUM – ein privates, erstanbieterbetriebenes RUM-Tool und CrUX können trotzdem voneinander abweichen.
• Sechs Zugriffsoberflächen (Taktung/Quoten entsprechen dem Stand dieses Textes, vor der Nutzung prüfen): PSI (täglich, pro URL), Search Console (wöchentlich), CrUX API (täglich), History API (wöchentlich, 40 Wochen), BigQuery (monatlich, nur Origin, bis 2017), CrUX Vis (wöchentliche Visualisierung). Das CrUX-Dashboard wurde im November 2025 eingestellt – nutze CrUX Vis.
• Die Rankingwirkung ist gering; der eigentliche Grund, CrUX zu beachten, ist die Nutzererfahrung.

Offizielle Dokumentation

Primärquellen zur CrUX-Dokumentation des Chrome-Teams auf developer.chrome.com.

• CrUX-Überblick — was CrUX ist, welche Rolle es im Web-Vitals-Programm spielt und wie die Suche es verwendet.
• CrUX-Methodik — die vier Kriterien für die Nutzerberechtigung, unterstützte und ausgeschlossene Plattformen, die 20-%-Regel, das Entfernen von URL-Teilen und die Behandlung von SPAs/Iframes.
• CrUX API — das 28-Tage-Fenster, die p75-Definition, der queryRecord-Endpunkt, das Limit von 150 Anfragen pro Minute und die tägliche Aktualisierung.
• CrUX History API — wöchentliche Snapshots, bis zu 40 Wochen Historie.
• CrUX in BigQuery — monatliche Veröffentlichung (zweiter Dienstag), nur auf Origin-Ebene, Historie bis 2017 und Daten auf Länderebene.
• CrUX Vis — das visuelle Werkzeug als Ersatz für das eingestellte CrUX-Dashboard.
• PageSpeed Insights + CrUX-Leitfaden — die URL → Origin → keine-Daten-Rückfallkette und die Einordnung von Feld- und Labordaten.
• CrUX-Versionshinweise — der Übergang von FID zu INP, die Entfernung von FID und die Zeitleiste zur Abschaffung des Dashboards.

Verwandter Hintergrund (web.dev)

• Unterschiede zwischen Labor- und Felddaten — warum ein Laborwert und CrUX voneinander abweichen.
• Unterschiede zwischen CrUX und RUM — die Chrome-Beschränkung, den Ausschluss von iOS sowie Details zu SPAs und Iframes.

Zitate aus der Quelle

Wörtliche Aussagen aus der CrUX-Dokumentation des Chrome-Teams. Jeder Link ist ein Deep Link, der direkt zur zitierten Passage springt.

Was CrUX ist

• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (Übersetzung) „Der Chrome User Experience Report (auch Chrome UX Report genannt, kurz CrUX) ist ein Datensatz, der widerspiegelt, wie echte Chrome-Nutzer beliebte Ziele im Web erleben.“ [Zum Zitat](https://developer.chrome.com/docs/crux#:~:text=The%20Chrome%20User%20Experience%20Report%20(also%20known%20as%20the%20Chrome%20UX%20Report)
• “CrUX is the Google dataset of the Web Vitals program. All user-centric Core Web Vitals metrics are represented.” (Übersetzung) „CrUX ist der Google-Datensatz des Web-Vitals-Programms. Alle nutzerzentrierten Core-Web-Vitals-Metriken sind vertreten.“ Zum Zitat

Berechtigung und Abdeckung

• “Not all origins or pages are represented in the dataset. There are separate eligibility criteria for origins and pages, primarily that they must be publicly discoverable and there must be a large enough number of visitors in order to create a statistically significant dataset.” (Übersetzung) „Nicht alle Origins oder Seiten sind im Datensatz vertreten. Für Origins und Seiten gelten getrennte Teilnahmekriterien; vor allem müssen sie öffentlich auffindbar sein und es muss eine ausreichend große Zahl von Besuchern geben, um einen statistisch signifikanten Datensatz zu erstellen.“ Zum Zitat
• Die vier Nutzerkriterien: “Enable usage statistic reporting. Sync their browser history. Not have a Sync passphrase set. Use a supported platform.” (Übersetzung) „Nutzungsstatistiken aktivieren. Den Browserverlauf synchronisieren. Keine Sync-Passphrase eingerichtet haben. Eine unterstützte Plattform verwenden.“ Zum Zitat

Aggregation

• “The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics.” (Übersetzung) „Die Daten im Chrome UX Report sind ein gleitender 28-Tage-Durchschnitt aggregierter Metriken.“ Zum Zitat
• “75% of page loads experienced the given metric at or less than this value.” (Übersetzung) „75 % der Seitenaufrufe erlebten die betreffende Metrik bei diesem Wert oder darunter.“ Zum Zitat
• “The values for each percentile are synthetically derived, it does not imply that any user actually experienced the value indicated, only that some percentage of page loads experienced a metric value that was less than the value given.” (Übersetzung) „Die Werte für jedes Perzentil sind synthetisch abgeleitet; daraus folgt nicht, dass irgendein Nutzer tatsächlich den angegebenen Wert erlebt hat, sondern nur, dass ein bestimmter Prozentsatz der Seitenaufrufe einen Metrikwert unter dem angegebenen Wert erlebt hat.“ Zum Zitat

Origin gegenüber URL

• “When the identifier is an origin all data present for all pages in that origin are aggregated together.” (Übersetzung) „Wenn der Bezeichner ein Origin ist, werden alle für alle Seiten dieses Origins vorhandenen Daten zusammen aggregiert.“ / “When the identifier is a URL, only data for that specific URL will be returned.” (Übersetzung) „Wenn der Bezeichner eine URL ist, werden nur Daten für diese bestimmte URL zurückgegeben.“ Zum Zitat

Feld gegenüber Labor (web.dev)

• “Field data is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” (Übersetzung) „Felddaten werden bestimmt, indem alle Nutzer überwacht werden, die eine Seite besuchen, und eine bestimmte Reihe von Leistungsmetriken für die individuellen Erfahrungen jedes einzelnen Nutzers gemessen wird.“ Zum Zitat
• “The Chrome User Experience Report, as its name suggests, is Chrome-only.” (Übersetzung) „Der Chrome User Experience Report ist, wie sein Name schon sagt, nur für Chrome.“ Zum Zitat

CrUX-Zugriffsoberflächen — Spickzettel

Wo du CrUX-Daten erhältst und wofür die einzelnen Oberflächen gut sind – Taktung und Quoten entsprechen dem Stand dieses Textes; prüfe die offiziellen Dokumente, bevor du dich darauf verlässt.

Schnelle Fakten

• Fenster: immer die zurückliegenden 28 Tage, auch bei neu gestarteten Seiten.
• Bewertung bei: p75 (75 % der Aufrufe beim Wert oder darunter), nicht bei einem Durchschnitt.
• Verzögerung: CrUX liegt ungefähr 2 Tage zurück; Korrekturen werden im Allgemeinen im Laufe eines Monats sichtbar, aber es gibt keine feste 30-Tage-Garantie – es hängt vom berechtigten Traffic und der betreffenden Metrik ab.
• Abdeckung: nur berechtigte Chrome-Erlebnisse (Einwilligung, Synchronisierung, unterstützte Plattform) – niemals jeder Chrome-Nutzer, niemals jeder Besucher. Kein Chrome auf iOS, keine WebViews, kein Edge / Safari / Firefox.
• Keine Daten? Die Kette lautet URL-Ebene → Origin-Ebene → nur Labor (Lighthouse). Ein fehlendes Ergebnis bedeutet „nicht genügend berechtigte Stichproben“, nicht null und nicht bestanden. Seiten- und Origin-Berechtigung werden getrennt bewertet.
• Feld gegenüber Labor: CrUX = Feld (echte Nutzer, wonach Google bewertet). Lighthouse = Labor (ein simulierter Ladevorgang zum Debuggen).

CWV-Schwellenwerte (beim p75)

Werkzeuge für die Arbeit mit CrUX

• PageSpeed Insights (pagespeed.web.dev) — schnellste Felddatenprüfung pro URL; oben CrUX, unten das Lighthouse-Labor. Kostenlos, kein Schlüssel.
• Search Console — Core-Web-Vitals-Bericht — websiteweite CrUX-Bewertung, nach Status gruppiert und in Mobil/Desktop getrennt. Die beste Ansicht dafür, wie deine echten CWV stehen.
• CrUX Vis (cruxvis.withgoogle.com) — kostenloses visuelles Trendtool über die History API; auf Origin- und URL-Ebene; bis zu 40 Wochen. Der Ersatz für das eingestellte CrUX-Dashboard.
• CrUX API (chromeuxreport.googleapis.com/v1/records:queryRecord) — aktuelle 28-Tage-Daten programmgesteuert; täglich; benötigt einen kostenlosen Google-Cloud-API-Schlüssel für die Chrome UX Report API.
• CrUX History API (…:queryHistoryRecord) — wöchentliche Snapshots, bis zu 40 Wochen; dieselbe Authentifizierung und dieselben Ratenlimits wie die CrUX API.
• CrUX in BigQuery (Datensatz chrome-ux-report) — für Forschung im großen Maßstab: Origin-Ebene, monatlich (zweiter Dienstag), Daten auf Länderebene, Historie bis 2017; kostenloses Kontingent.
• Chrome DevTools — Performance-Panel — zeigt CrUX-Felddaten neben deinem lokalen Trace (seit März 2025), sodass du Labor und Feld direkt vergleichen kannst.

Welche CrUX-Oberfläche sollte ich verwenden?

CrUX-Fehler, die zu schlechten Entscheidungen führen

Einen Origin-Fallback als Beleg auf Seitenebene behandeln

PageSpeed Insights kann bei dünner Datenlage von einer URL auf ihren Origin zurückfallen. Lies den angezeigten Geltungsbereich, bevor du behauptest, eine bestimmte Seite bestehe; verwende URL-Daten, wenn sie verfügbar sind, und kennzeichne Origin-Daten ehrlich, wenn sie es nicht sind.

Erwarten, dass eine Korrektur am Starttag ein 28-Tage-Fenster umschreibt

CrUX ist ein rollierender Felddatensatz, kein Live-Test eines Deployments. Verwende für die frühe Diagnose Labordaten oder RUM und warte dann, bis neue Erlebnisse das alte Feldfenster ersetzen.

Lighthouse als CrUX-Messung bezeichnen

Lighthouse ist ein einzelner kontrollierter Laborlauf. CrUX aggregiert echte Besuche berechtigter Chrome-Nutzer. Verwende Lighthouse, um eine wahrscheinliche Ursache zu diagnostizieren, nicht um zu erklären, Googles Felddatenbewertung sei behoben.

Annehmen, dass CrUX jeden Nutzer repräsentiert

CrUX schließt Safari, Firefox, Edge, Chrome auf iOS, WebViews und Chrome-Nutzer ohne erfüllte Berechtigungsregeln aus. Vergleiche die Daten mit erstanbieterbetriebenem RUM, wenn die Zusammensetzung deiner Zielgruppe die Chrome-Stichprobe unrepräsentativ machen könnte.

PageSpeed Insights meldet keine Felddaten

Symptom: Der Feldabschnitt fehlt. Wahrscheinliche Ursache: Weder die URL noch ihr Origin erfüllt die CrUX-Berechtigungs- oder Stichprobenanforderungen. Behebung: Bestätige, dass die öffentliche Seite 200 zurückgibt und indexierbar ist, und verwende dann Labordaten oder erstanbieterbetriebenes RUM; Traffic lässt sich für CrUX nicht künstlich erzeugen. Später erneut prüfen, wenn die reale Nutzung wächst.

Die Seite sieht gut aus, aber der Origin sieht schlecht aus

Symptom: Ergebnisse auf URL- und Origin-Ebene widersprechen sich. Wahrscheinliche Ursache: Der Origin aggregiert viele Seitentypen mit unterschiedlicher Performance. Behebung: Den Geltungsbereich im Bericht beibehalten, repräsentative URLs aus den langsamen Templates prüfen und die beiden Datensätze nicht zu einem Durchschnitt zusammenfassen.

Lighthouse besteht, während die Search Console scheitert

Symptom: Ein kontrollierter Test ist grün, der CWV-Bericht aber nicht. Wahrscheinliche Ursache: Echte Nutzer haben langsamere Geräte, Netzwerke, Cache-Zustände oder Interaktionen als der Laborlauf. Behebung: CrUX nach Gerät aufteilen, Feld- und Labormetrik einzeln vergleichen und den Feldengpass mit dem Labor-Trace reproduzieren.

Eine API-Abfrage gibt „nicht gefunden“ zurück

Symptom: Eine Abfrage nach URL/Formfaktor hat keinen Datensatz. Wahrscheinliche Ursache: Die engere Kombination enthält zu wenige berechtigte Erlebnisse. Behebung: Optionale Dimensionen entfernen, den Origin-Geltungsbereich versuchen und den Fallback ausdrücklich berichten, statt fehlende Daten als bestanden zu behandeln.

CrUX-Analyse-Checkliste

• Festhalten, ob jeder Wert auf URL- oder Origin-Ebene gilt.
• Ergebnisse für Mobilgeräte und Desktop/Formfaktoren getrennt halten.
• Bestätigen, dass das Fenster die zurückliegenden 28 Tage umfasst, und die Erfassungsdaten notieren.
• p75 als Perzentil von Seitenaufrufen lesen, nicht als individuellen Nutzerwert.
• Prüfen, ob PageSpeed Insights von der URL auf den Origin zurückgefallen ist.
• Fehlende Daten als unzureichende Abdeckung behandeln, niemals als bestanden.
• LCP, INP und CLS getrennt vergleichen; eine bestandene Metrik lässt nicht alle bestehen.
• Lighthouse oder DevTools zur Diagnose verwenden, nicht als Ersatz für Felddaten.
• CrUX mit erstanbieterbetriebenem RUM vergleichen, wenn Nicht-Chrome-Nutzer einen großen Anteil ausmachen.
• Das rollierende Fenster abwarten, bevor du eine Produktionskorrektur in CrUX bewertest.

Geltungsbereich, Fenster, Perzentil, Population

Jede CrUX-Zahl wird leichter verständlich, wenn ich zuerst vier Dinge kennzeichne:

1. Geltungsbereich: Ist es die exakte URL oder der gesamte Origin?
2. Fenster: Welcher zurückliegende 28-Tage-Zeitraum hat den Wert erzeugt?
3. Perzentil: Das ist p75, kein Durchschnitt und nicht der Besuch eines einzelnen Nutzers.
4. Population: Berechtigte Chrome-Nutzer auf unterstützten Plattformen, nicht der gesamte Traffic.

Wenn ein Bericht eines davon auslässt, lässt sich die Zahl leicht übertreiben.

Erst das Urteil, dann die Diagnose

CrUX beantwortet, was echte berechtigte Nutzer erlebt haben. Ein Labor-Trace beantwortet, warum sich ein kontrollierter Ladevorgang so verhalten hat. Beginne mit dem Feldurteil, wähle die betroffene Metrik und den Geltungsbereich und nutze dann Labortools zur Untersuchung. Nach dem Ausliefern einer Korrektur bestätigst du mit dem Labor sofort den Mechanismus und mit CrUX das Ergebnis auf Populationsebene, sobald sich das rollierende Fenster ändert.

Laufende CrUX-KPIs

p75 LCP, INP und CLS

Metrik: jedes Core Web Vital beim p75. Was sie aussagt: das Felderlebnis, das Google für seine CWV-Bewertung verwendet. Wie du sie abrufst: CrUX API, History API, CrUX Vis oder PageSpeed Insights, mit dokumentiertem Geltungsbereich und Formfaktor. Benchmark / realistische Spanne: die veröffentlichten guten Schwellenwerte dieses Artikels verwenden; alle drei Metriken getrennt halten. Taktung: wöchentliche Trends, bei einem Rollout tägliche Prüfungen.

Abdeckung des Status „Gut“ nach Template

Metrik: Anteil wichtiger URL-Gruppen, die in der Search Console als „Gut“ bewertet werden. Was sie aussagt: wie breit die Feld-Performance auf der Website gesund ist. Wie du sie abrufst: Core-Web-Vitals-Berichte für Mobilgeräte und Desktop plus ein Template-Inventar. Benchmark / realistische Spanne: eine Website-Baseline festlegen und wertvolle Templates mit viel Traffic priorisieren; dünn besetzte URLs haben möglicherweise keinen eigenen CrUX-Datensatz. Taktung: wöchentlich.

Verfügbarkeit von Daten auf URL-Ebene

Metrik: überwachte priorisierte URLs mit eigenem CrUX-Datensatz statt eines Origin-Fallbacks. Was sie aussagt: wie viel seitenspezifischen Beleg deine Berichterstattung stützen kann. Wie du sie abrufst: den Erfolg der API-Abfrage und den PSI-Geltungsbereich für den festen URL-Satz protokollieren. Benchmark / realistische Spanne: hängt vom berechtigten Chrome-Traffic ab; die Abdeckung nicht zu einem Ziel machen, das künstlichen Traffic fördert. Taktung: monatlich.

Teste dich selbst: Chrome UX Report

Fünf kurze Fragen zu CrUX-Geltungsbereich, Abdeckung und Interpretation. Wähle jeweils eine Antwort und prüfe sie anschließend.

Ressourcen, die deine Zeit wert sind

Meine verwandten Texte

• Core-Web-Vitals-Datenstudie mit CrUX und 5,2 Mio. Seiten — meine eigene Studie, die CrUX mit einem Crawl von 43,66 Mio. Seiten kombiniert; Quelle der Zahlen zur Abdeckung von etwa 11,9 % und zu den Bestehensraten auf Origin- gegenüber Seitenebene.
• Was sind Core Web Vitals? — wo CrUX einzuordnen ist und meine Einschätzung dazu, wie stark CWV Rankings tatsächlich bewegen.
• Largest Contentful Paint (LCP) — die Felddaten-Einordnung von LCP.
• Cumulative Layout Shift (CLS) — einschließlich der Erklärung, warum das 28-Tage-Fenster sichtbare Verbesserungen verlangsamt.
• PageSpeed-Insights-Leitfaden — das Tool, das CrUX-Felddaten pro URL anzeigt.

Offiziell

• CrUX-Dokumentation (Chrome-Team) — die maßgebliche Referenz für alles oben Genannte.
• HTTP-Archive-CrUX-Bericht — laufende öffentliche Dashboards auf Basis von CrUX/BigQuery.

Von anderen

• DebugBear — Leitfaden zum Chrome User Experience Report — gründlicher, entwicklerorientierter Toolvergleich.
• Lumar — SEO-Leitfaden zu Website-Geschwindigkeit, CWV, Lighthouse und CrUX — starke SEO-Einordnung.
• SpeedCurve — Wann CrUX, RUM und synthetisches Monitoring verwendet werden — ehrlicher Vergleich der drei Ansätze; weist klar auf die Chrome-only-/iOS-Lücke hin.
• GTmetrix — Was ist CrUX und warum sollte mich das interessieren? — ausführliche Darstellung von Berechtigung und Abdeckungsgrenzen.

Statistiken, die sich zu zitieren lohnen

• Nur etwa 11,9 % der 43,66 Mio. eindeutigen Site-Audit-Seiten in meiner Stichprobe vom Januar 2022 hatten mindestens eine CrUX-Core-Web-Vitals-Metrik. Das waren 5,21 Mio. Seiten; für den Rest gab es zu wenig Traffic, um die Voraussetzungen zu erfüllen. Quelle
• Die Bestehensraten auf Origin-Ebene lagen in derselben Stichprobe vom Januar 2022 über den Bestehensraten auf Seitenebene: etwa 33 % gegenüber etwa 21,2 %. Domains, die CWV auf Origin-Ebene bestanden, lagen deutlich über dem Anteil der einzelnen Seiten, die bestanden – Origin-Durchschnitte beziehen schnellere Seiten und gecachte wiederholte Besuche ein. Eine datierte Stichprobe, keine aktuelle allgemeingültige Quote. Quelle
• Laut dieser Studie bestanden auf 3G oder langsameren Verbindungen fast keine Websites die CWV. „Die LCP-Schwelle scheint auf langsameren Verbindungen fast unmöglich zu erreichen.“ Quelle
• Die Geografie verzerrte die Ergebnisse in dieser Stichprobe. Die USA lagen weltweit auf Platz 38 mit einer Bestehensrate von etwa 41 %; Geräte- und Netzwerkgewohnheiten nach Land erklärten den größten Teil der Streuung. Quelle
• Es dauert ungefähr einen Monat, bis eine Korrektur vollständig sichtbar wird – das 28-Tage-Fenster plus die etwa zweitägige CrUX-Verzögerung; der genaue Zeitraum ist jedoch nicht fest und hängt vom berechtigten Traffic und der betreffenden Metrik ab. Quelle
• Mehr als die Hälfte der Origins besteht inzwischen die Core Web Vitals. Beim CrUX-Meilenstein im August 2024 berichtete Google, dass mehr als 50 % der Origins im Datensatz alle drei Core Web Vitals bestanden – deutlich mehr als die in früheren Studien gemessene Bestehensrate von etwa 33 % auf Origin-Ebene. Quelle
• CrUX umfasst mehr als 15 Millionen Origins. In den Jahren 2024–2025 enthielt der Datensatz laut der Methodik-Dokumentation des Chrome-Teams Daten von mehr als 15 Millionen verschiedenen Origins. Quelle

Änderungsprotokoll