Wymiar Core/Dash: Powracający użytkownik

Wymiar: Zachowanie użytkownika: Powracający użytkownik (fv)

Wymiar Powracający użytkownik dzieli dane dotyczące wydajności na dwie populacje: użytkowników, którzy odwiedzili Twoją witrynę wcześniej, oraz tych, którzy robią to po raz pierwszy. Inżynieryjna różnica między tymi grupami to pamięć podręczna 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 jest średnią ważoną obu tych wartości. Jeśli 40% Twoich sesji to 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 luka w wydajności jest większa niż oczekujesz

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

W danych CoreDash z monitorowanych witryn, powracający użytkownicy zazwyczaj wykazują 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 obraz hero jest duży, a serwer źródłowy jest geograficznie oddalony od użytkownika. Na stronach z renderowaniem po stronie serwera i tekstowym elementem LCP, różnica ta się zmniejsza, ponieważ opóźnienie ładowania tekstu jest bliskie zeru dla obu grup.

Różnice w INP między tymi dwiema grupami są mniejsze, ale wciąż obecne. Nowi użytkownicy często inicjują więcej parsowania JavaScript przy pierwszym ładowaniu, ponieważ pakiety modułów są oceniane 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 przez JavaScript może to skrócić czas przetwarzania o 50 ms do 150 ms.

Interpretacja trzech wartości

0: Powracający użytkownik

Przeglądarka zgłosiła, że nie jest to 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 to Twoja linia bazowa dla ciepłej pamięci podręcznej: scenariusz optymalny dla rzeczywistych użytkowników, którzy znają Twoją witrynę. Jeśli Twój LCP jest tutaj słaby, problemem nie jest pamięć podręczna. Zamiast tego przyjrzyj się zasobom blokującym renderowanie, czasowi odpowiedzi serwera lub opóźnieniu renderowania.

1: Nowy użytkownik

Brak pamięci podręcznej. Przeglądarka pobiera każdy zasób z sieci. To Twój najgorszy scenariusz z zimną pamięcią podręczną, który reprezentuje pierwsze wrażenie dla każdego użytkownika, który znajdzie Cię przez bezpłatne wyniki wyszukiwania, płatną reklamę lub udostępnienie w mediach społecznościowych. Nowi użytkownicy zazwyczaj stanowią od 30% do 45% sesji. Ich wyniki LCP są o 300 ms do 700 ms wyższe niż powracających użytkowników na stronach opartych na obrazach. Jeśli LCP nowych użytkowników nie spełnia progu 2,5 s, ale LCP powracających użytkowników tak, Twój cel optymalizacji jest jasny: zmniejsz rozmiar i opóźnienie samego zasobu LCP, ponieważ dla tej grupy odbiorców nie możesz polegać na pamięci podręcznej.

2: Nie zmierzono

CoreDash nie mógł określić typu wizyty dla tej sesji. Zazwyczaj dzieje się tak, gdy przeglądarka blokuje dostęp do pamięci masowej wymagany do rozróżnienia nowych i powracających użytkowników, lub gdy konfiguracja przeglądarki zorientowana na prywatność uniemożliwia to sprawdzenie. Na większości witryn ten segment stanowi mniej niż 5% sesji. Traktuj to jako szum, a nie jako segment, pod kątem którego należy optymalizować.

Przepływ pracy przy debugowaniu

1. Ustal swój bazowy podział: Otwórz wymiar Powracający użytkownik w CoreDash i zanotuj odsetek nowych w stosunku do powracających sesji. Jeśli nowi użytkownicy stanowią ponad 50% ruchu, wydajność z zimną pamięcią podręczną determinuje Twój dominujący user experience i musi być głównym celem optymalizacji.
2. Porównaj LCP według typu wizyty: Przefiltruj tylko nowych użytkowników i zanotuj LCP dla percentyla p75. Następnie przefiltruj 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. Wyceluj bezpośrednio w zasób LCP: W przypadku nowych użytkowników z wolnym LCP, rozwiązaniem jest skrócenie czasu ładowania zasobu. Skompresuj obraz LCP, serwuj go z węzła brzegowego CDN blisko użytkowników i zastosuj fetchpriority="high". Te korzyści utrzymują się niezależnie od stanu pamięci podręcznej. Nie polegaj na buforowaniu jako rekompensacie za zbyt duży lub wolno serwowany zasób LCP.
4. Zweryfikuj za pomocą wymiaru Typ nawigacji: Porównaj z wymiarem Typ nawigacji. Nawigacje typu reload i back-forward przeważają u powracających użytkowników. Jeśli Twój LCP u powracających użytkowników wydaje się nieoczekiwanie wolny, przyczyną może być duży odsetek nawigacji typu reload (gdzie zbuforowane zasoby są rewalidowane, a nie obsługiwane bezpośrednio).

Praktyczna zasada inżynieryjna

• Cel LCP dla nowych użytkowników: Poniżej 2,5 s dla percentyla p75. Jest to trudniejsze do osiągnięcia niż LCP dla powracających użytkowników i wymaga rzeczywistej pracy nad infrastrukturą: CDN, optymalizacji obrazów oraz odpowiedniego priorytetu pobierania (fetch priority).
• Akceptowalna różnica między LCP nowych i powracających użytkowników: Do 400 ms. Większa różnica wskazuje, że Twoja witryna polega na pamięci podręcznej przeglądarki, aby zaliczyć Core Web Vitals, co oznacza, że pierwsze wrażenia zawodzą.
• Odsetek „Nie zmierzono” poniżej 5%: Jeśli ten segment wzrośnie powyżej 10%, zbadaj, czy wdrożenie zgody na pliki cookie lub zmiana uprawnień do pamięci masowej nie blokuje wykrywania typu wizyty.

Wymiar Powracający użytkownik to jeden z pierwszych filtrów, które stosuję, gdy witryna ledwo zalicza LCP. Zagregowane dane z pola ukrywają prawdziwą historię. Podział według typu wizyty natychmiast pokazuje, czy praca nad optymalizacją jest solidna, czy też witryna bazuje na trafieniach w pamięć podręczną od lojalnej, powracającej grupy odbiorców, jednocześnie zawodząc każdego nowego użytkownika, który trafia z wyników wyszukiwania.