Viele Teams starren auf den Lighthouse-Score und feiern eine 100, doch in der Google Search Console bleibt der Bericht zu den Core Web Vitals rot. Der Grund ist ein verbreitetes Missverständnis: Der Lighthouse-Laborwert beeinflusst das Ranking nicht. Google bewertet die Core Web Vitals ausschließlich über Felddaten aus dem Chrome User Experience Report (CrUX) - gemessen an echten Chrome-Nutzern, über ein rollierendes 28-Tage-Fenster und am 75. Perzentil (Quelle: Google web.dev). Eine Seite kann im Labor einen Score von 68 zeigen und trotzdem 85 Prozent gute LCP-Werte im Feld erreichen (Quelle: DebugBear). Dieser Beitrag erklärt den Unterschied zwischen Lab-, CrUX- und eigenem Real-User-Monitoring (RUM), zeigt, warum die drei Datenquellen voneinander abweichen, und wie sich daraus belastbare Performance-Budgets am 75. Perzentil ableiten lassen. Wer Tempo datenbasiert statt nach Bauchgefühl optimiert, misst die richtigen Werte, priorisiert die wirksamsten Maßnahmen und kann jede Verbesserung mit einer fundierten Performance-Analyse belegen.
Das Wichtigste in Kürze
- Drei Quellen beantworten drei Fragen: Lab-Tests zeigen, warum eine Seite langsam ist, CrUX-Felddaten, ob Google ein Problem sieht, und eigenes Real User Monitoring, welches Element oder Skript es auslöst.
- Der Lighthouse-Laborwert fließt nicht ins Ranking ein: Google bewertet die Core Web Vitals über CrUX-Felddaten echter Chrome-Nutzer am 75. Perzentil (Google web.dev). Ein Score von 100 sagt ein Bestehen im Feld nicht zu (DebugBear).
- CrUX und eigenes RUM weichen systematisch ab: CrUX erfasst nur angemeldete Chrome-Nutzer, keine iOS-Geräte und keine Soft Navigations in Single-Page-Applications (web.dev, DebugBear). Vergleichen Sie erst nach Filter auf Chrome, Gerätetyp und 75. Perzentil.
- CrUX aggregiert über ein rollierendes 28-Tage-Fenster (Chrome UX Report): Ein heute ausgerollter Fix zeigt seine volle Wirkung im Feld erst nach etwa vier Wochen. Bis dahin dient das eigene RUM als Echtzeit-Frühindikator.
- Performance-Budgets gehören ans 75. Perzentil der Felddaten: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1 – getrennt je Template-Typ und getrennt für mobil und Desktop, weil der Origin-Schnitt Ausreißer verdeckt.
- CrUX hat eine Eignungsschwelle: Ohne ausreichenden Traffic erscheinen für eine URL keine Daten (web.dev). Eigenes RUM liefert schon bei wenigen Besuchen und deckt auch Safari und Firefox ab – die Quellen ersetzen einander nicht.
Drei Datenquellen, drei Wahrheiten
Web-Performance lässt sich aus drei grundsätzlich verschiedenen Blickwinkeln messen, und jeder beantwortet eine andere Frage. Lab-Daten (synthetische Tests wie Lighthouse) laden eine Seite in einer kontrollierten Umgebung mit fest definiertem Gerät, fester Netzwerkverbindung und fester Position (Quelle: web.dev). Felddaten aus CrUX spiegeln, wie echte Chrome-Nutzer eine Website tatsächlich erleben - mit der ganzen Bandbreite an Geräten, Netzen und Verhaltensweisen (Quelle: web.dev). Eigenes Real-User-Monitoring (RUM) sammelt dieselbe Art Felddaten über ein Skript auf der eigenen Website, allerdings über alle Browser hinweg und mit deutlich mehr Detailtiefe (Quelle: DebugBear).
Der entscheidende Punkt für das Ranking: Google nutzt für die Bewertung der Core Web Vitals die CrUX-Felddaten, nicht den Lab-Score. Ein synthetischer Test wie Lighthouse kann erklären, warum eine Seite langsam ist, misst aber nicht die Core Web Vitals, die ins Ranking einfließen (Quelle: DebugBear). Daraus folgt eine klare Arbeitsteilung: CrUX zeigt, ob ein Problem existiert und ob Google es sieht. RUM zeigt, woran es liegt und welche Elemente oder Skripte verantwortlich sind. Lab-Tests dienen der schnellen Diagnose und Regressionssuche im Build, bevor Änderungen überhaupt live gehen.
Diese Trennung erklärt, warum eine isolierte Lighthouse-Optimierung ins Leere laufen kann. Entwickler arbeiten typischerweise mit erstklassigen Internetverbindungen auf modernen Geräten, während reale Nutzer oft auf älteren Smartphones mit schwankender Mobilfunkverbindung unterwegs sind (Quelle: web.dev). Wer nur das Labor optimiert, optimiert für ein Szenario, das in den rankingrelevanten Felddaten kaum vorkommt. Eine durchdachte Core-Web-Vitals-Optimierung setzt deshalb am Feld an und nutzt das Labor als Werkzeug, nicht als Ziel.
Lab (Lighthouse)
Eine simulierte Messung unter festen Bedingungen. Schnell, reproduzierbar und ideal für Diagnose und Regressionschecks im Build - aber ohne direkten Ranking-Einfluss.
CrUX (Felddaten)
Echte Chrome-Nutzer über ein 28-Tage-Fenster, berichtet am 75. Perzentil. Das ist die Datenquelle, die Google für die Bewertung der Core Web Vitals heranzieht.
Eigenes RUM
Felddaten über alle Browser, in Echtzeit und mit Detailtiefe bis zum auslösenden Element oder Skript. Zeigt das Warum hinter den CrUX-Zahlen.
Warum CrUX und RUM voneinander abweichen
Eine der häufigsten Fragen in der Praxis lautet: Warum stimmen die CrUX-Werte nicht mit den Zahlen aus dem eigenen RUM überein? Die Antwort liegt in der unterschiedlichen Erhebung. CrUX misst ausschließlich eine Teilmenge von Chrome-Nutzern, die der Datensammlung zugestimmt haben und mit ihrem Google-Konto angemeldet sind (Quelle: DebugBear). Nutzer auf iOS fließen nicht ein, weil dort die WebKit-Engine zum Einsatz kommt - und damit fehlt eine Gruppe, die typischerweise auf leistungsfähigeren Geräten und in Regionen mit besserer Netzinfrastruktur unterwegs ist (Quelle: web.dev). Diese Auslassung kann die CrUX-Werte gegenüber dem eigenen RUM verzerren.
Ein zweiter großer Unterschied betrifft Single-Page-Applications. CrUX erfasst sogenannte Soft Navigations - Seitenwechsel innerhalb einer SPA ohne vollständigen Neuladevorgang - derzeit nicht, während viele RUM-Lösungen diese als eigene Seitenaufrufe zählen (Quelle: web.dev). Das führt dazu, dass SPAs in CrUX künstlich hohe Metrikwerte zeigen können, weil alle Interaktionen einer Sitzung dem ersten Seitenaufruf zugeschlagen werden. Wer eine SPA betreibt, sollte diesen Effekt kennen, bevor er CrUX- und RUM-Zahlen direkt vergleicht.
Hinzu kommen technische Feinheiten bei der Messung selbst. CrUX wertet Back-Forward-Cache-Wiederherstellungen als Seitennavigationen, während die zugrundeliegenden Web-APIs das nicht tun - eine Quelle systematischer Abweichungen (Quelle: web.dev). Auch der Zugriff auf Inhalte in iframes unterscheidet sich: CrUX kann innerhalb von iframes messen, RUM-Skripte können das aus Sicherheitsgründen in der Regel nicht (Quelle: web.dev). Wer diese Unterschiede ignoriert, vergleicht Aepfel mit Birnen und zieht falsche Schlüsse.
Gleiches mit Gleichem vergleichen
| Aspekt | CrUX (Felddaten) | Eigenes RUM |
|---|---|---|
| Browser-Abdeckung | nur Chrome, angemeldete und opt-in Nutzer | alle Browser inkl. Safari und Firefox |
| iOS-Nutzer | nicht enthalten (WebKit-Engine) | vollständig erfasst |
| Aktualität | 28-Tage-Fenster, Wirkung erst nach Wochen | in Echtzeit bis stündlich verfügbar |
| SPA-Soft-Navigations | derzeit nicht erfasst | als eigene Seitenaufrufe zählbar |
| Detailtiefe | fünf Kernmetriken plus Netz-Daten | Element-, Skript- und Diagnose-Detail |
| Seiten-Eignung | Mindesttraffic nötig, sonst keine Daten | auch bei wenigen Besuchen verfügbar |
Die Tabelle macht deutlich, warum sich die beiden Quellen ergänzen statt ersetzen. CrUX ist die rankingrelevante Wahrheit, hat aber eine Eignungsschwelle: Eine Seite muss öffentlich auffindbar und ausreichend besucht sein, damit überhaupt Daten erscheinen (Quelle: web.dev). Neue oder traffic-schwache URLs tauchen schlicht nicht auf - hier springt das eigene RUM ein, das schon bei wenigen Besuchen liefert (Quelle: DebugBear). Eine begleitende technische Analyse verbindet beide Sichten zu einem vollständigen Bild.
Das 75. Perzentil und das 28-Tage-Fenster
Zwei Eigenschaften des CrUX-Datensatzes sind für die Praxis besonders wichtig, weil sie steuern, ob eine Seite die Core Web Vitals besteht. Die erste ist das 75. Perzentil. Google bewertet eine Seite nicht am Durchschnitt, sondern an dem Wert, den 75 Prozent der Nutzererlebnisse erreichen oder unterbieten (Quelle: Google web.dev). Anschaulich: Besuchen 100 Menschen Ihre Seite, muss der LCP für 75 von ihnen bei 2,5 Sekunden oder darunter liegen, damit der Wert als gut gilt. Das Perzentil ist bewusst streng gewählt - es schützt die Bewertung davor, dass einige sehr schnelle Besuche eine langsame Mehrheit kaschieren.
Die zweite Eigenschaft ist das rollierende 28-Tage-Fenster. CrUX aggregiert die Werte über die vergangenen 28 Tage und schiebt das Fenster täglich um einen Tag weiter: Der aelteste Tag fällt heraus, der neueste kommt hinzu (Quelle: Chrome UX Report). Dieses Fenster glättet Rauschen und Tagesschwankungen, hat aber eine direkte Konsequenz für die Arbeit - Verbesserungen werden erst nach einigen Wochen vollständig sichtbar, weil sie sich erst durch das gesamte Fenster ziehen müssen. Ein Fix, der heute live geht, zeigt seine volle Wirkung im Feld typischerweise erst in vier Wochen.
Aus dieser Verzögerung folgt eine wichtige Arbeitsweise: Während man auf die Feldbestätigung wartet, kontrolliert man die Wirkung im eigenen RUM, das in Echtzeit liefert (Quelle: DebugBear). So bleibt man handlungsfähig, ohne 28 Tage blind abzuwarten. Das eigene RUM wird damit zum Frühindikator für die später folgende CrUX-Bewegung. Diese Kombination aus schnellem RUM-Feedback und langsamer, aber rankingrelevanter CrUX-Bestätigung ist der Kern einer professionellen Mess-Strategie.
Geduld ist Teil der Methode
Warum Lab-Werte vom Feld abweichen
Lab- und Felddaten weichen aus systematischen Gründen voneinander ab, und das ist kein Fehler, sondern eine Folge ihrer Konstruktion. Lab-Daten entstehen durch das Laden einer Seite in einer synthetischen Umgebung mit einem einzigen, vordefinierten Satz an Geräte- und Netzwerkbedingungen (Quelle: web.dev). Felddaten dagegen enthalten die ganze Vielfalt realer Bedingungen sowie unzählige Verhaltensmuster echter Nutzer. Ein einzelner Lab-Lauf ist damit stets nur eine Annäherung an einen Punkt einer breiten Verteilung.
Besonders deutlich wird die Abweichung bei Metriken, die von der Interaktion abhängen. Der Interaction to Next Paint (INP) misst die Reaktionszeit auf echte Nutzereingaben - ein Headless-Browser im Labor klickt und tippt jedoch in der Regel nicht und scrollt nicht durch die Seite. Solche Metriken lassen sich im klassischen Lab-Lauf nur schwer realistisch erfassen, weshalb das Feld hier die verlässlichere Quelle ist. Wie sich INP-Probleme gezielt aufdecken und beheben lassen, vertieft unser Beitrag zum INP optimieren und Interaktionslatenz senken.
Auch Cumulative Layout Shift (CLS) klafft zwischen Lab und Feld oft auseinander, weil ein Labortest die Seite einmal lädt, ohne zu scrollen oder zu interagieren - genau dort entstehen aber viele reale Sprünge. Diese Lücke wird mit dem 2026 diskutierten Nachfolgesignal noch relevanter; die Hintergründe beleuchtet unser Beitrag zum Visual Stability Index als CLS-Nachfolger. Wer Lab-Werte als alleinigen Maßstab nimmt, übersieht systematisch das, was reale Nutzer erleben - und was Google bewertet.
Der Score-100-Trugschluss
Performance-Budgets am 75. Perzentil setzen
Ein Performance-Budget definiert eine Obergrenze, die eine Metrik nicht überschreiten darf - und der entscheidende Schritt für datenbasiertes Tempo ist, dieses Budget am 75. Perzentil der Felddaten festzulegen, nicht am Lab-Wert. Konkret heißt das: Das Budget ist gehalten, wenn der LCP für 75 Prozent der echten Nutzer unter 2,5 Sekunden bleibt, der INP unter 200 Millisekunden und der CLS unter 0,1. Diese Schwellen entsprechen den von Google als gut definierten Grenzwerten und sind damit direkt rankingrelevant.
Der Vorteil eines feldbasierten Budgets ist seine Ehrlichkeit. Ein Budget am Lab-Wert kann grün leuchten, während ein Viertel der echten Nutzer eine deutlich langsamere Seite erlebt - und genau dieses Viertel entscheidet über die Bewertung. Das im Mockup gezeigte Beispiel illustriert das: Ein LCP von 1,9 Sekunden im Labor sieht sauber aus, doch das Feld-Perzentil von 3,1 Sekunden reißt das Budget. Nur ein Budget, das am 75. Perzentil prüft, fängt diese Diskrepanz ab.
- Budget je Kernmetrik festlegen: LCP unter 2,5 s, INP unter 200 ms, CLS unter 0,1 - jeweils am 75. Perzentil echter Nutzer.
- Je Template-Typ getrennt budgetieren: Startseite, Kategorie, Produktdetail und Warenkorb verhalten sich unterschiedlich, der Origin-Schnitt verdeckt Ausreißer.
- Mobil und Desktop trennen: CrUX weist beide getrennt aus, und mobile Werte sind in der Regel der kritische Fall.
- RUM als Frühwarnsystem koppeln: Reißt eine Metrik im Echtzeit-RUM das Budget, kommt es später auch in CrUX an.
- Budget in die Pipeline integrieren: Build oder Pull Request markieren, sobald ein Lab-Proxy für das Budget reißt, bevor die Änderung live geht.
Wichtig ist die Rollenverteilung im Budget-Prozess: Das Feld definiert das Ziel, das Labor wacht über Regressionen. Ein Lab-Test im Build kann nicht das exakte 75-Perzentil-Feldergebnis vorhersagen, aber er erkennt zuverlässig, wenn ein neues Skript das Bundle aufbläht oder ein verspätetes Hero-Bild den LCP verschlechtert. Wie sich JavaScript-Budgets konkret in den Build einbauen lassen, vertieft unser Beitrag zu JavaScript und Performance-Budgets.
Kontinuierlich messen statt einmal prüfen
Tempo ist kein Zustand, den man einmal erreicht und dann abhakt. Jedes neue Plugin, jedes Theme-Update, jedes Marketing-Skript und jede zusätzliche Funktion kann eine mühsam aufgebaute Performance wieder verschlechtern. Nur eine kontinuierliche Messung deckt solche schleichenden Regressionen auf, bevor sie sich über das 28-Tage-Fenster in die rankingrelevanten CrUX-Werte fressen. Eine einmalige Prüfung liefert eine Momentaufnahme - und veraltet, sobald die nächste Änderung deployt wird.
Die belastbare Mess-Strategie kombiniert alle drei Quellen entsprechend ihrer Stärken. Lab-Tests laufen automatisiert im Build und fangen Regressionen ab, bevor sie live gehen. Das eigene RUM liefert in Echtzeit das Warum und dient als Frühindikator. CrUX bestätigt über das 28-Tage-Fenster die rankingrelevante Realität. Erst dieses Zusammenspiel macht aus einzelnen Zahlen eine Entscheidungsgrundlage. Eine kontinuierliche Frontend-Optimierung verankert diesen Kreislauf als festen Prozess statt als gelegentliche Aktion.
Messen
Drei Quellen kombinieren: Lab für die Diagnose, RUM für Echtzeit und Detailtiefe, CrUX für die rankingrelevante Bewertung am 75. Perzentil.
Priorisieren
Maßnahmen nach Wirkung auf das 75. Perzentil ordnen. Die Metrik, die das Budget am deutlichsten reißt, kommt zuerst - nicht die, die am leichtesten zu fixen ist.
Belegen
Verbesserung im RUM sofort, in CrUX nach dem 28-Tage-Fenster nachweisen. So wird Tempo zur messbaren Größe statt zur Behauptung.
Wer nur den Lab-Score optimiert, optimiert für ein Gerät, das kaum ein echter Nutzer besitzt. Das Ranking entscheidet das Feld - am 75. Perzentil.
Vom Bauchgefühl zur belegbaren Tempo-Strategie
Der wirtschaftliche Hebel liegt in der Klarheit über die richtige Datenquelle. Wer Budget in Optimierungen steckt, die nur den Lab-Score heben, investiert ins falsche Ziel - die Felddaten und damit das Ranking bewegen sich kaum. Umgekehrt liefert eine Optimierung, die das 75. Perzentil im Feld verbessert, sowohl bessere Core Web Vitals als auch eine spürbar schnellere Erfahrung für reale Nutzer auf realen Geräten. Datenbasiertes Tempo bedeutet, genau diese wirksamen Maßnahmen zu erkennen und zu priorisieren.
Praktisch heißt das: CrUX als Wahrheit für das Ranking, eigenes RUM als schnelles Diagnose- und Frühwarnsystem, Lab-Tests als Regressionswaechter im Build - und über allem ein Performance-Budget am 75. Perzentil, das für jede Änderung gilt. So wird aus diffusem Bauchgefühl eine belegbare Strategie, die jede Verbesserung mit Zahlen aus dem Feld untermauert. Genau dieses Vorgehen bildet den Kern unserer Leistungen rund um Web-Performance, die zuerst misst und priorisiert, statt blind an Stellschrauben zu drehen.
Quellen und Studien