Dlaczego 28-dniowe opóźnienie Core Web Vitals to mit

Dowiedz się, co Google naprawdę ma na myśli, mówiąc że dane Core Web Vitals mają 28-dniowe opóźnienie

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-07

Obalanie mitu o 28-dniowym opóźnieniu Core Web Vitals

Przekonanie, że dane Core Web Vitals mają 28-dniowe opóźnienie, jest powszechnym błędnym mniemaniem w społeczności web developerów. To przekonanie doprowadziło do stwierdzeń takich jak „Nie zobaczymy zmian przez kolejne 28 dni” czy „Miejmy nadzieję, że zadziała; dowiemy się za 28 dni”. Jednakże to postrzeganie jest nieprawidłowe i oparte na niezrozumieniu sposobu, w jaki dane Chrome User Experience Report (CrUX) są przetwarzane i prezentowane.

Rzeczywistość danych CrUX!

Wbrew powszechnemu przekonaniu, dane CrUX nie podlegają 28-dniowemu opóźnieniu. W rzeczywistości dane są niezwykle aktualne, zazwyczaj mają zaledwie około dwa dni. Można to zweryfikować, odpytując Google CrUX API, co wyraźnie pokazuje aktualność danych!

crux json 2 day delay

Zrozumienie 28-dniowego okna

Zamieszanie wynika ze sposobu, w jaki Google prezentuje dane Core Web Vitals. To, co użytkownicy faktycznie widzą, to wartość 75. percentyla obliczona z ostatnich 28 dni. To podejście statystyczne ma na celu zapewnienie bardziej stabilnej i reprezentatywnej miary wydajności strony internetowej w czasie, zamiast odzwierciedlania krótkoterminowych wahań.

Dlaczego wydaje się, że istnieje opóźnienie

Zastosowanie 28-dniowego okna kroczącego do obliczania 75. percentyla może tworzyć iluzję opóźnienia w zauważaniu popraw. Oto dlaczego:

  • Stopniowa wymiana danych: Początkowo te nowe dane są mieszane ze starszymi, potencjalnie gorszymi danymi wydajności. Każdego dnia dane są dodawane do 28-dniowego okna wydajności, a jeden dzień najstarszych danych jest usuwany. Pełna wymiana wszystkich danych zajmie 28 dni.
  • Obliczanie percentyla: Ponieważ używany jest 75. percentyl, potrzeba czasu, aby wystarczająca ilość poprawionych punktów danych znacząco przesunęła tę metrykę. Może to wydawać się nieintuicyjne, ale nie można myśleć o wynikach percentylowych w taki sam sposób jak o średnich. Podsumowując, 75. percentyl może być „odporny na zmiany” w przypadku nagłych wahań.

Pomyśl o tym tak: Masz pudełko z 28 czerwonymi kulkami. Każdego dnia wyjmujesz jedną starą, czerwoną kulkę i zastępujesz ją nową zieloną kulką. Pełne odświeżenie całego pudełka zajmie 28 dni, ale nigdy nie było żadnego opóźnienia!

To, jak szybko słoik stanie się w większości zielony (75. percentyl), zależy od tego, ile czerwonych kulek jest już w nim. Jeśli jest dużo czerwonych kulek, zmiana na zielony zajmie więcej czasu. Ale jeśli jest mniej czerwonych kulek, słoik stanie się zielony szybciej.

Implikacje dla web developerów

Zrozumienie tego mechanizmu ma ważne implikacje dla web developerów i właścicieli stron:

  • Ciągłe monitorowanie: Zamiast czekać 28 dni na wyniki, monitoruj swoje Core Web Vitals regularnie, najlepiej za pomocą RUM, który może obliczać 75. percentyl w interwałach dziennych.
  • Stopniowe ulepszenia: Nawet małe usprawnienia mogą przyczynić się do stopniowego przesuwania 75. percentyla w czasie.
  • Cierpliwość i wytrwałość: Choć możesz nie zobaczyć natychmiastowych dramatycznych zmian w raportowanych metrykach, konsekwentne ulepszenia w końcu zostaną odzwierciedlone.


Stop debating in Jira.

Get a definitive answer on your performance issues. I deliver a granular breakdown of your critical rendering path.

Book a Deep Dive >>

  • Definitive Answers
  • Granular Breakdown
  • Critical Path Analysis
Dlaczego 28-dniowe opóźnienie Core Web Vitals to mitCore Web Vitals Dlaczego 28-dniowe opóźnienie Core Web Vitals to mit