Wymiar Core/Dash: Repeat Visitor

Wymiar: Zachowanie użytkownika: Repeat Visitor (fv)

Wymiar Repeat Visitor dzieli Twoje dane wydajnościowe na dwie populacje: użytkowników, którzy już wcześniej odwiedzili Twoją witrynę, oraz tych, którzy są na niej po raz pierwszy. Z inżynieryjnego punktu widzenia różnica między tymi grupami sprowadza się do pamięci podręcznej przeglądarki. Powracający użytkownik ładuje czcionki, skrypty i obrazy z dysku. Nowy użytkownik pobiera każdy bajt z sieci.

Ma to znaczenie, ponieważ zagregowany wynik LCP to średnia ważona ich obu. Jeśli 40% Twoich sesji stanowią nowi użytkownicy, ich czasy ładowania z zimną pamięcią podręczną zawyżają Twój p75. Bez tego wymiaru nie jesteś w stanie stwierdzić, czy regresja LCP to rzeczywisty problem z infrastrukturą, czy też tymczasowy skok w pozyskiwaniu nowych użytkowników.

Dlaczego różnica w wydajności jest większa, niż się spodziewasz

Pamięć podręczna przeglądarki eliminuje całe łańcuchy żądań dla powracających użytkowników. W typowej witrynie z treściami powracający użytkownik pomija wyszukiwanie DNS, nawiązywanie połączenia TCP, negocjację TLS i odpowiedź serwera dla każdego zbuforowanego zasobu. Sam zasób LCP często jest serwowany z pamięci podręcznej w mniej niż 5 ms, zamiast 200–800 ms wymaganych na pobranie go z sieci. To nie jest marginalna poprawa: to strukturalna różnica w sposobie ładowania strony.

W danych CoreDash dla monitorowanych witryn, powracający użytkownicy zazwyczaj osiągają wyniki LCP o 35% do 60% niższe niż nowi użytkownicy na tych samych stronach. Różnica ta jest największa na stronach bogatych w obrazy, gdzie główny obraz (hero image) jest duży, a serwer źródłowy jest geograficznie oddalony od użytkownika. Na stronach renderowanych po stronie serwera z tekstowym elementem LCP ta luka się zmniejsza, ponieważ opóźnienie ładowania tekstu wynosi niemal zero dla obu grup.

Różnice w INP między dwiema grupami są mniejsze, ale wciąż zauważalne. Nowi użytkownicy często powodują intensywniejsze parsowanie JavaScript przy pierwszym załadowaniu, ponieważ pakiety modułów są ewaluowane po raz pierwszy. Powracający użytkownicy korzystają z pamięci podręcznej kodu silnika V8, która przechowuje skompilowany kod bajtowy i całkowicie pomija etap parsowania i kompilacji. Na stronach mocno obciążonych JavaScript może to skrócić czas przetwarzania o 50–150 ms.

Interpretacja trzech wartości

0: Repeat Visitor (Powracający użytkownik)

Przeglądarka zgłosiła, że to nie jest pierwsza sesja użytkownika w Twoim źródle (origin). Zbuforowane zasoby są dostępne. W większości witryn marketingowych i redakcyjnych śledzonych w CoreDash, powracający użytkownicy stanowią od 55% do 70% wszystkich sesji. Ich dane wydajnościowe stanowią Twoją linię bazową dla rozgrzanej pamięci podręcznej (warm-cache baseline): najlepszy możliwy scenariusz dla prawdziwych użytkowników znających Twoją witrynę. Jeśli Twoje LCP w tym przypadku jest słabe, problemem nie jest pamięć podręczna. Przyjrzyj się raczej zasobom blokującym renderowanie, czasowi odpowiedzi serwera lub opóźnieniu renderowania.

1: New Visitor (Nowy użytkownik)

Brak pamięci podręcznej. Przeglądarka pobiera każdy zasób z sieci. Jest to Twój najgorszy przypadek (zimna pamięć podręczna – cold cache) i reprezentuje on pierwsze wrażenie każdego użytkownika, który trafia do Ciebie z bezpłatnych wyników wyszukiwania, płatnej reklamy lub udostępnienia w mediach społecznościowych. Nowi użytkownicy to zazwyczaj 30–45% sesji. Ich wyniki LCP są o 300–700 ms gorsze niż w przypadku powracających użytkowników na stronach z dużą ilością grafik. Jeśli LCP nowych użytkowników nie spełnia progu 2,5 s, podczas gdy LCP powracających go spełnia, Twój cel optymalizacyjny jest jasny: zredukuj rozmiar i opóźnienie samego zasobu LCP, ponieważ dla tej grupy odbiorców nie możesz polegać na pamięci podręcznej.

2: Not Measured (Nie zmierzono)

CoreDash nie był w stanie określić typu wizyty dla tej sesji. Zwykle ma to miejsce, gdy przeglądarka blokuje dostęp do pamięci (storage access) wymagany do odróżnienia nowych od powracających użytkowników, lub gdy uniemożliwia to konfiguracja przeglądarki zorientowana na prywatność. W większości witryn ten koszyk stanowi poniżej 5% sesji. Traktuj to jako szum tła, a nie segment, pod kątem którego powinieneś optymalizować.

Przepływ pracy dla debugowania

1. Ustal podział linii bazowej: Otwórz wymiar Repeat Visitor w CoreDash i zanotuj procentowy udział nowych w stosunku do powracających sesji. Jeśli nowi użytkownicy stanowią ponad 50% ruchu, wydajność zimnej pamięci podręcznej (cold-cache) determinuje Twój dominujący user experience i musi stanowić główny cel optymalizacji.
2. Porównaj LCP według typu wizyty: Odfiltruj tylko nowych użytkowników i zapisz p75 LCP. Następnie odfiltruj powracających użytkowników i zanotuj tę samą metrykę. Różnica powyżej 500 ms wskazuje, że wąskim gardłem jest rozmiar zasobu lub czas pobierania z sieci. Różnica poniżej 200 ms sugeruje problemy po stronie renderowania, które wpływają na obie grupy w równym stopniu.
3. Weź na cel bezpośrednio zasób LCP: Dla nowych użytkowników z wolnym LCP rozwiązaniem jest skrócenie czasu ładowania zasobu. Skompresuj obraz LCP, zaserwuj go z węzła brzegowego CDN blisko użytkowników i zastosuj fetchpriority="high". Te zyski utrzymują się niezależnie od stanu pamięci podręcznej. Nie polegaj na buforowaniu, aby zrekompensować przewymiarowany lub powoli serwowany zasób LCP.
4. Zweryfikuj to za pomocą wymiaru Navigation Type: Skrzyżuj dane z wymiarem Navigation Type. Przeładowania i nawigacje wstecz-dalej skłaniają się ku powracającym użytkownikom. Jeśli LCP u powracających użytkowników wydaje się nieoczekiwanie wolne, powodem może być wysoki odsetek przeładowań (gdzie zbuforowane zasoby są rewalidowane, a nie serwowane bezpośrednio).

Praktyczne wskazówki inżynieryjne

• Cel LCP dla nowego użytkownika: Poniżej 2,5 s dla p75. Jest to trudniejsze do osiągnięcia niż LCP powracającego użytkownika i wymaga faktycznej pracy nad infrastrukturą: CDN, optymalizacji obrazów i poprawnego fetch priority.
• Dopuszczalna różnica LCP między nowym a powracającym użytkownikiem: Do 400 ms. Większa luka wskazuje, że Twoja witryna polega na pamięci podręcznej przeglądarki w celu spełnienia wymogów Core Web Vitals, co oznacza, że pierwsze wrażenie zawodzi.
• Not Measured (Nie zmierzono) poniżej 5%: Jeśli udział tego koszyka wzrośnie powyżej 10%, sprawdź, czy implementacja zgody na pliki cookie lub zmiana uprawnień do pamięci masowej blokuje wykrywanie typu wizyty.

Wymiar Repeat Visitor to jeden z pierwszych filtrów, jakie nakładam, gdy witryna wykazuje graniczny wynik zaliczenia LCP. Skumulowane dane z pola ukrywają prawdziwy stan rzeczy. Podział według typu wizyty natychmiast pokazuje, czy praca optymalizacyjna jest solidna, czy też witryna bazuje na trafieniach w pamięć podręczną od lojalnych, powracających odbiorców, podczas gdy zawodzi każdego nowego użytkownika, który trafia z wyszukiwarki.