Technologia · wersja V2 po audycie źródeł
Jak czytać CrUX Vis, 28-dniowe okna danych, percentyl 75, LCP, INP i CLS oraz odróżniać dane terenowe od pomiarów laboratoryjnych.
Poziom dowodów: Wysoka dla działania narzędzia; interpretacja zmian wymaga danych diagnostycznych poza CrUX
Co wiemy
- CrUX Vis pokazuje tygodniową historię z CrUX History API za maksymalnie około 40 tygodni.
- Każdy punkt obejmuje poprzednie 28 dni, dlatego sąsiednie punkty silnie się nakładają.
- Dostępne są dane origin i URL, form factor oraz widok 75. percentyla i rozkładów.
Co pozostaje niepewne
- CrUX nie wyjaśnia sam, który skrypt, element lub wdrożenie spowodowało zmianę.
- Brak danych dla adresu może wynikać z niewystarczającego ruchu lub kryteriów prywatności.
- Jednoczesna zmiana wielu czynników utrudnia przypisanie przyczyny na podstawie wykresu historycznego.
1. Czym jest CrUX i co pokazuje CrUX Vis
Chrome UX Report, w skrócie CrUX, to publiczny zbiór zagregowanych danych o doświadczeniach użytkowników Chrome na stronach spełniających kryteria kwalifikacji. Google udostępnia je przez kilka narzędzi: PageSpeed Insights, API, History API, BigQuery i CrUX Vis.[1]
CrUX Vis służy przede wszystkim do oglądania trendu. Użytkownik podaje origin albo konkretny URL, a narzędzie pokazuje dostępne metryki i ich rozkład w czasie. Origin oznacza protokół, host i port, na przykład https://example.com. Dane URL dotyczą konkretnej strony, ale są dostępne tylko przy wystarczającej liczbie obserwacji.
2. Dane terenowe i laboratoryjne odpowiadają na inne pytania
| Rodzaj danych | Co mierzy | Najlepsze zastosowanie |
|---|---|---|
| CrUX, RUM | Rzeczywiste urządzenia, sieci i zachowania użytkowników | Ocena doświadczenia populacji i trendu |
| Lighthouse | Symulowana wizyta w kontrolowanych warunkach | Diagnoza techniczna i porównywalny test |
| DevTools Performance | Szczegółowy ślad konkretnej sesji | Wyszukiwanie przyczyny opóźnień i zadań głównego wątku |
| Search Console | Grupy adresów z podobnym problemem CWV | Priorytetyzacja na poziomie serwisu |
Dobry wynik laboratoryjny nie gwarantuje dobrych danych terenowych. Użytkownicy mogą mieć wolniejsze urządzenia, niestabilne sieci, rozszerzenia, różne stany cache i odmienne zachowania. Odwrotna sytuacja również jest możliwa: test syntetyczny może wyglądać słabo, ale większość realnych wizyt korzysta z pamięci podręcznej i szybkich urządzeń.
3. Dlaczego wykres reaguje powoli
History API i wizualizacje CrUX wykorzystują kroczące okresy obejmujące 28 dni. Punkt nie opisuje jednego dnia. Łączy dane z czterech tygodni, a następny punkt w dużej części korzysta z tych samych dni.[2]
Jeżeli 1 lipca wdrożono szybszy obraz LCP, to 2 lipca większość obserwacji w oknie nadal pochodzi sprzed zmiany. Udział nowych wizyt rośnie codziennie. Pełny efekt może stać się widoczny dopiero po wymianie całego okna, a przy zmiennym ruchu jeszcze później.
Dlatego do oceny wdrożenia warto zaznaczyć datę zmiany i obserwować kierunek przez co najmniej kilka tygodni. Nagły jednodniowy skok zwykle nie jest widoczny tak jak w analityce dziennej.
4. Jak czytać LCP, INP i CLS
LCP: szybkość pokazania głównej treści
Largest Contentful Paint mierzy czas renderowania największego widocznego elementu treści w początkowym widoku. Dobry próg wynosi do 2,5 sekundy na 75. percentylu. Częstymi przyczynami problemu są wolna odpowiedź serwera, duży obraz hero, blokujące arkusze CSS, późne wykrycie zasobu i renderowanie po stronie klienta.[3]
INP: responsywność podczas całej wizyty
Interaction to Next Paint ocenia opóźnienie interakcji w całym czasie życia strony. Dobra wartość to nie więcej niż 200 ms. Źródłem problemów bywają długie zadania JavaScript, rozbudowane komponenty, praca wykonywana po kliknięciu i przeciążony główny wątek.
CLS: stabilność wizualna
Cumulative Layout Shift mierzy niespodziewane przesunięcia układu. Dobry wynik to nie więcej niż 0,1. Typowe przyczyny to obrazy bez zarezerwowanych wymiarów, późno wstawiane reklamy, bannery i fonty powodujące zmianę geometrii tekstu.
5. Dlaczego liczy się 75. percentyl
Core Web Vitals ocenia się na 75. percentylu wizyt. Oznacza to, że co najmniej 75 procent doświadczeń powinno mieścić się w dobrym progu. Średnia byłaby zbyt podatna na rozkład i mogłaby ukryć słabe doświadczenia istotnej grupy użytkowników.
Należy też sprawdzać wymiary. Wynik mobilny i desktopowy może się różnić, podobnie jak origin i konkretny URL. Agregacja originu może wyglądać dobrze, gdy problem dotyczy małej, lecz biznesowo ważnej sekcji.
6. Praktyczny proces analizy
- Sprawdź origin i kluczowe szablony URL.
- Zapisz daty wdrożeń, migracji, kampanii i zmian dostawców skryptów.
- Oceń osobno LCP, INP i CLS oraz udział kategorii „good”, „needs improvement” i „poor”.
- Porównaj urządzenia i szablony.
- Potwierdź przyczynę w PageSpeed Insights, DevTools i danych RUM.
- Po wdrożeniu obserwuj trend przez pełne 28 dni, ale nie czekaj z diagnozą laboratoryjną.
Przykład interpretacji
Po zmianie systemu zgód INP zaczyna się pogarszać, a LCP pozostaje stabilny. W tym przypadku nie ma sensu optymalizować obrazów. Trzeba sprawdzić JavaScript uruchamiany przy interakcji, liczbę listenerów, pracę CMP i zadania na głównym wątku.
7. Co oznacza brak danych
CrUX stosuje progi kwalifikacji i ochronę prywatności. Dla mało popularnego URL może nie pokazać danych, choć origin ma ich wystarczająco dużo. Brak danych nie jest oceną „poor”. Oznacza, że publiczny zbiór nie może wiarygodnie zwrócić metryki dla tego poziomu agregacji.
W takim przypadku warto wdrożyć własny Real User Monitoring, korzystać z biblioteki web-vitals i analizować dane laboratoryjne. RUM daje większą szczegółowość, ale wymaga poprawnej implementacji, zgód i kontroli jakości danych.
8. Najczęstsze błędy interpretacyjne
- Porównywanie punktu CrUX z testem Lighthouse wykonanym dziś.
- Oczekiwanie pełnego efektu dzień po wdrożeniu.
- Analizowanie tylko wyniku originu.
- Traktowanie dobrego LCP jako dowodu dobrej responsywności.
- Ignorowanie zmian w strukturze ruchu, urządzeniach i kampaniach.
- Uznawanie braku danych za zły wynik.
- Optymalizacja pod wynik narzędzia zamiast pod przyczynę doświadczenia użytkownika.
9. Pytania i odpowiedzi
Czy CrUX Vis jest narzędziem Google?
Tak. Jest częścią zestawu narzędzi Chrome UX Report opisanego w dokumentacji Chrome for Developers.
Dlaczego PageSpeed pokazuje inny wynik niż CrUX Vis?
PageSpeed łączy dane terenowe, jeśli są dostępne, z testem laboratoryjnym Lighthouse. CrUX Vis pokazuje trend danych terenowych, więc porównywane okresy i warunki są inne.
Po ilu dniach widać efekt wdrożenia?
Kierunek może być widoczny wcześniej, ale pełna wymiana kroczącego okna trwa 28 dni. Na małych próbach zmiana może być mniej stabilna.
Czy Core Web Vitals są jedynymi wskaźnikami wydajności?
Nie. Są wspólnym zestawem metryk doświadczenia, ale diagnostyka wymaga także danych serwerowych, technicznych i biznesowych.
Bibliografia i źródła
- Chrome for Developers, Overview of CrUX tools.
- Chrome for Developers, CrUX History API.
- web.dev, Web Vitals.
- Chrome for Developers, CrUX Vis.
- W3C Web Performance Working Group, Web Performance.
Jak czytać nakładające się okna 28-dniowe
Punkt z danego poniedziałku nie jest pomiarem jednego tygodnia. Jest agregatem z poprzednich 28 dni. Kolejny punkt zachowuje około trzy czwarte wcześniejszego okresu i wymienia tylko najstarszy tydzień na najnowszy. Z tego powodu wykres reaguje wolniej niż monitoring laboratoryjny, a pojedynczy zły dzień nie musi być od razu widoczny.
Gdy wdrożenie nastąpiło 1 lipca, pełny obraz jego wpływu może ujawniać się stopniowo przez kilka tygodni. Warto oznaczać na osi daty wdrożeń, kampanii, zmian szablonu, consent mode, CDN i dużych aktualizacji. Bez takiego dziennika wykres łatwo zamienia się w korelację bez przyczyny.
Od sygnału w CrUX do diagnozy technicznej
- Sprawdź, czy regresja dotyczy URL czy całego originu.
- Rozdziel telefon, desktop i tablet; mieszanie form factor może ukrywać problem.
- Porównaj 75. percentyl z rozkładem „good / needs improvement / poor”.
- Zweryfikuj datę pierwszego widocznego odchylenia i uwzględnij 28-dniowe wygładzanie.
- Przejdź do danych laboratoryjnych, RUM i logów wdrożeń, aby znaleźć element powodujący zmianę.
CrUX odpowiada na pytanie „jak stronę odczuwali kwalifikujący się użytkownicy Chrome”. Lighthouse odpowiada na inne pytanie: „jak zachował się kontrolowany test w konkretnych warunkach”. Rozbieżność między nimi jest normalna i diagnostycznie użyteczna.