Warum die 28-Tage-Verzögerung der Core Web Vitals ein Mythos ist

Die 28-Tage-Verzögerung der Core Web Vitals ist ein Mythos

Ich höre es ständig: „Wir haben den Fix deployt, jetzt müssen wir 28 Tage warten, um zu sehen, ob er funktioniert hat.“ Das ist falsch. Die Daten sind nicht 28 Tage alt. Sie sind etwa zwei Tage alt. Die Verwirrung entsteht dadurch, wie Google die Zahlen berechnet. Sobald du das verstehst, verschwindet die 28-Tage-Panik.

Zuletzt überprüft von Arjen Karel im März 2026

CrUX-Daten sind zwei Tage alt, nicht 28

Der Chrome User Experience Report (CrUX) aktualisiert sich täglich gegen 04:00 UTC. Wenn du die CrUX API abfragst, enthält die Antwort ein collectionPeriod-Feld, das den genauen Datumsbereich zeigt. Das Enddatum ist normalerweise gestern oder vorgestern. Seit Dezember 2024 zeigt auch PageSpeed Insights diese Daten an, du kannst es also selbst sehen.

Woher kommen also die 28 Tage?

Was du in PageSpeed Insights siehst, ist das 75. Perzentil, berechnet aus den echten Nutzerdaten der letzten 28 Tage. Google verwendet ein rollierendes 28-Tage-Fenster, nicht um deine Daten zu verzögern, sondern um Rauschen zu glätten. Ein einzelner schlechter Tag ruiniert deinen Score nicht. Ein einzelner guter Tag rettet ihn nicht. Das Fenster gibt dir ein stabiles, repräsentatives Bild davon, wie echte Nutzer deine Seite erleben.

Jeden Tag fallen die Daten des ältesten Tages weg und die Daten des neuesten Tages kommen hinzu. Es gibt keine Verzögerung. Das Fenster bewegt sich einfach Tag für Tag vorwärts.

Eine Sache, die viele falsch verstehen: Das ist ein 75. Perzentil, kein Durchschnitt. Einige bekannte Leitfäden (darunter der von Vercel) bezeichnen es fälschlicherweise als Durchschnitt. Der Unterschied ist wichtig. Ein p75 bedeutet, dass 75 % der Nutzererlebnisse bei oder unter diesem Wert liegen. Es ist widerstandsfähiger gegen Veränderungen als ein Durchschnitt, weil Ausreißer auf der schnellen Seite es nicht so schnell nach unten ziehen.

Warum Verbesserungen langsam erscheinen

Wenn du einen Performance-Fix deployst, mischen sich deine neuen Daten mit bis zu 27 Tagen an alten Daten. Das 75. Perzentil verschiebt sich allmählich, nicht über Nacht.

Stell es dir so vor: Du hast eine Kiste mit 28 roten Murmeln. Jeden Tag nimmst du eine alte rote Murmel heraus und ersetzt sie durch eine neue grüne Murmel. Es dauert volle 28 Tage, bis die gesamte Kiste erneuert ist, aber es gab nie eine Verzögerung!

Wie schnell die Kiste überwiegend grün wird (das 75. Perzentil sich verschiebt), hängt davon ab, wie viele rote Murmeln bereits darin waren. Wenn deine Seite durchweg langsam war, müssen viele rote Murmeln ersetzt werden. Wenn sie grenzwertig war, wird die Kiste viel schneller grün.

Was dich nach dem Deployment eines Fixes erwartet

Hier ist ein realistischer Zeitplan, was passiert, nachdem du eine Performance-Verbesserung deployt hast:

• Tag 0: Du deployst den Fix. In CrUX ändert sich noch nichts.
• Tag 2-3: Die ersten verbesserten Datenpunkte erreichen das 28-Tage-Fenster. Wenn du genau beobachtest, können winzige Verschiebungen sichtbar werden.
• Tag 7: Etwa ein Viertel des Fensters enthält Daten nach dem Fix. Trends werden in der CrUX History sichtbar.
• Tag 14: Die Hälfte des Fensters besteht aus neuen Daten. Wenn dein Fix signifikant war (zum Beispiel fiel der LCP-Wert von 4s auf 2s), hat sich das p75 spürbar verschoben.
• Tag 28: Das Fenster ist vollständig erneuert. CrUX spiegelt nun deine aktuelle Performance wider.

Wie dramatisch die Verschiebung ist, hängt von drei Dingen ab: wie groß die Verbesserung war, wie viel Traffic deine Seite hat (mehr Traffic bedeutet mehr neue Datenpunkte pro Tag) und wie konsistent der Fix über alle Seitenaufrufe hinweg ist.

Drei Orte, drei Update-Geschwindigkeiten

Nicht alle CrUX-Daten aktualisieren sich im gleichen Tempo. Das ist eine weitere Quelle für Verwirrung:

• CrUX API und PageSpeed Insights: tägliches Update (~2 Tage Verzögerung). Das nutzen die meisten Leute.
• CrUX History API: wöchentliches Update montags, mit Daten bis zum vorherigen Samstag. Bildet die Basis für das CrUX History Tool und Trenddiagramme.
• CrUX BigQuery: monatliches Update, am zweiten Dienstag nach Ende des Erfassungszeitraums. Wenn du nur in BigQuery nachsiehst, fühlt es sich wirklich wie eine monatelange Verzögerung an.

Wenn du ungeduldig darauf wartest, dass sich deine Zahlen bewegen, prüfe PageSpeed Insights (täglich), nicht BigQuery (monatlich).

Warte keine 28 Tage. Nutze RUM.

CrUX sind Googles Daten. Sie sagen dir, wie Google deine Seite sieht. Aber du musst nicht dasitzen und darauf warten. Mit Real User Monitoring kannst du die Core Web Vitals tagesgenau oder sogar pro Seitenaufruf verfolgen. Du weißt innerhalb von Stunden, ob dein Fix funktioniert, nicht in Tagen.

CrUX trackt derzeit 18,56 Millionen Origins mit einer Pass-Rate der Core Web Vitals von 55,8 %. Wenn deine Seite zu den 44 % gehört, die immer noch nicht bestehen, lass dich nicht vom Mythos der „28-Tage-Verzögerung“ davon abhalten, Änderungen vorzunehmen. Die Daten sind fast in Echtzeit. Das Fenster glättet sie nur.