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

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!

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.
- Definitive Answers
- Granular Breakdown
- Critical Path Analysis

