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

Den Mythos der 28-Tage-Verzögerung bei den Core Web Vitals entlarven

Ich höre es ständig: "Wir haben den Fix bereitgestellt, 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 durch die Art und Weise, wie Google die Zahlen berechnet, und sobald man das verstanden hat, 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) wird täglich gegen 04:00 UTC aktualisiert. Wenn du die CrUX API abfragst, enthält die Antwort ein collectionPeriod-Feld, das den genauen Datumsbereich anzeigt. Das Enddatum ist typischerweise gestern oder vorgestern. Seit Dezember 2024 zeigt PageSpeed Insights diese Daten ebenfalls an, sodass du es selbst sehen kannst.

Woher kommen also die 28 Tage?

Was du in PageSpeed Insights siehst, ist das 75. Perzentil, berechnet über die letzten 28 Tage realer Nutzerdaten. Google verwendet ein rollierendes 28-Tage-Fenster, nicht weil sie deine Daten verzögern wollen, sondern weil es Rauschen glättet. Ein einziger schlechter Tag ruiniert deine Bewertung nicht. Ein einziger guter Tag rettet sie 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 rückt einfach vor, Tag für Tag.

Eine Sache, die viele Leute falsch verstehen: Dies ist ein 75. Perzentil, kein Durchschnitt. Mehrere beliebte Leitfäden (einschließlich Vercels) nennen es fälschlicherweise einen Durchschnitt. Der Unterschied ist wichtig. Ein p75 bedeutet, dass 75 % der Nutzererfahrungen bei oder unter diesem Wert liegen. Es ist widerstandsfähiger gegen Änderungen als ein Durchschnitt, da Ausreißer auf der schnellen Seite es nicht so schnell nach unten ziehen.

Warum Verbesserungen langsam erscheinen

Wenn du einen Performance-Fix bereitstellst, werden deine neuen Daten mit bis zu 27 Tagen alter Daten gemischt. 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 wird volle 28 Tage dauern, bis die gesamte Kiste vollständig aktualisiert 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 konstant langsam war, gibt es viele rote Murmeln zu ersetzen. Wenn sie grenzwertig war, wird die Kiste viel schneller grün.

Was dich nach der Bereitstellung eines Fixes erwartet

Hier ist ein realistischer Zeitplan dafür, was passiert, nachdem du eine Performance-Verbesserung bereitgestellt hast:

• Tag 0: Du stellst den Fix bereit. In CrUX ändert sich noch nichts.
• Tag 2-3: Die ersten verbesserten Datenpunkte gelangen in das 28-Tage-Fenster. Wenn du genau überwachst, können winzige Verschiebungen auftreten.
• Tag 7: Etwa ein Viertel des Fensters enthält Daten nach dem Fix. Trends werden im CrUX History sichtbar.
• Tag 14: Die Hälfte des Fensters besteht aus neuen Daten. Wenn dein Fix signifikant war (z. B. wenn LCP von 4s auf 2s gefallen ist), wird sich das p75 spürbar bewegt haben.
• Tag 28: Das Fenster ist vollständig aktualisiert. 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 Seitenladevorgänge hinweg ist.

Drei Orte, drei Aktualisierungsgeschwindigkeiten

Nicht alle CrUX-Daten werden im gleichen Tempo aktualisiert. Dies ist eine weitere Quelle der Verwirrung:

• CrUX API und PageSpeed Insights: täglich aktualisiert (~2 Tage Verzögerung). Dies ist, was die meisten Leute verwenden.
• CrUX History API: wöchentlich montags aktualisiert, mit Daten bis zum vorherigen Samstag. Betreibt das CrUX History-Tool und Trenddiagramme.
• CrUX BigQuery: monatlich aktualisiert, am zweiten Dienstag nach Ende des Erfassungszeitraums. Wenn du nur BigQuery überprüfst, kann es sich wirklich wie eine monatelange Verzögerung anfühlen.

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

Warte keine 28 Tage. Verwende 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 auf Tagesbasis oder sogar pro Seitenaufruf verfolgen. Du wirst innerhalb von Stunden wissen, ob dein Fix funktioniert, nicht in Tagen.

CrUX verfolgt derzeit 18,56 Millionen Origins mit einer Core Web Vitals-Bestehensquote 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 lediglich.