Monitorowanie rzeczywistych użytkowników: analiza szybkości działania stron internetowych w warunkach rzeczywistych i laboratoryjnych

Prawdziwi użytkownicy i testy laboratoryjne

Monitorowanie rzeczywistych użytkowników (RUM) rejestruje, jak strona internetowa działa podczas rzeczywistych wizyt. Wywołanie strony na starszym smartfonie za pośrednictwem sieci komórkowej może znacznie różnić się od wizyty na komputerze stacjonarnym z szybkim połączeniem. Również przeglądane strony i interakcje są uwzględniane w analizowanym obrazie.

A Test laboratoryjny Natomiast w tym przypadku analizuje się określone wywołanie w kontrolowanych warunkach. Na potrzeby badania można zdefiniować typ urządzenia, warunki sieciowe oraz przebieg testu. Ułatwia to ponowne wywołanie nieprawidłowości oraz sprawdzenie ewentualnych zmian w porównywalnych warunkach.

Te dwa punkty widzenia odpowiadają na różne pytania: dane terenowe mogą wskazywać, że mobilne strony produktów często ładują się powoli. Nie dowodzą one jednak, czy przyczyną jest na przykład zdjęcie produktu, ścieżka renderowania czy też powolna odpowiedź dokumentu. Aby ustalić przyczynę, potrzebne są dodatkowe analizy diagnostyczne i weryfikowalne hipotezy.

PageSpeed Insights łączy obie perspektywy: porównuje dostępne dane terenowe z raportów Chrome User Experience Report z wynikami diagnostyki laboratoryjnej opartej na narzędziu Lighthouse. Wyniki te nie muszą być zgodne, ponieważ rzeczywiste wizyty obejmują różne warunki i scenariusze użytkowania, podczas gdy laboratorium analizuje ustalony scenariusz testowy.

RUM nie zastępuje zatem badań laboratoryjnych. Z drugiej strony pojedyncze badanie laboratoryjne nie jest w stanie wykazać, jak często dany problem występuje wśród rzeczywistych użytkowników. Ponadto przed publikacją lub w przypadku strony internetowej o niewielkiej liczbie odwiedzin może brakować wystarczających danych terenowych; bez rzeczywistych odwiedzin nie powstają w ogóle żadne własne pomiary RUM.

W ten sposób powstają wartości pomiarowe RUM

Własny pomiar wymaga trzech elementów: rejestracji w przeglądarce, odbiornika przekazywanych wartości oraz analizy. Najpierw należy określić, które strony i grupy odwiedzających chcesz uwzględnić oraz w jaki sposób dane będą chronione. Dopiero sensownie zestawione wartości jednostkowe stanowią podstawę do podejmowania decyzji.

Przeglądarki udostępniają w tym celu różne interfejsy związane z wydajnością. Czas nawigacji opisuje momenty związane z nawigacją do dokumentu, na przykład odpowiedź na żądanie dokumentu. Resource Timing dostarcza informacji o czasie dotyczących poszczególnych załadowanych zasobów, takich jak obrazy lub skrypty. Pozwala to na dokładniejsze określenie poszczególnych etapów procesu ładowania.

A PerformanceObserver śledzi wpisy dotyczące wydajności, gdy tylko staną się dostępne. W przypadku wskaźników Core Web Vitals biblioteka może web-vitals przejmują obliczenia i zgłaszanie. To, jakie wpisy i wskaźniki są dostępne, zależy między innymi od przeglądarki; dlatego skrypt pomiarowy nie rejestruje automatycznie w całości każdej wizyty.

Nie każda wartość powstaje bezpośrednio podczas ładowania strony. Na przykład w przypadku wskaźnika INP musi nastąpić odpowiednia interakcja: osoba, która jedynie czyta stronę, a następnie ją opuszcza, może nie generować żadnej wartości. Brak wartości pomiarowej nie oznacza zatem ani zera, ani dowodu na szybką reakcję.

Usługa RUM może zapewniać rejestrację, odbiór i analizę w ramach jednego pakietu. W przypadku rozwiązania własnego musisz dodatkowo zorganizować obsługę, przechowywanie danych oraz zapewnienie jakości. Obejmuje to również prawidłowe traktowanie powtarzających się zgłoszeń w cyklu życia strony, zamiast liczenia każdego zgłoszenia jako niezależnej wizyty bez weryfikacji.

Jak prawidłowo interpretować Core Web Vitals

Die Core Web Vitals opisują trzy różne aspekty doświadczenia użytkownika. Wskaźnik Largest Contentful Paint (LCP) mierzy, kiedy staje się widoczny największy istotny element treści. Na stronie produktu może to być na przykład duże zdjęcie produktu: jeśli pojawi się ono zbyt późno, strona może sprawiać wrażenie, jakby nie została jeszcze w pełni załadowana, mimo że elementy nawigacyjne są widoczne już wcześniej.

Wskaźnik Interaction to Next Paint (INP) mierzy opóźnienie między interakcją a kolejną widoczną aktualizacją. Jeśli filtr produktu reaguje w sposób zauważalny dopiero po kliknięciu, wskaźnik INP może wskazać na ten problem. Z kolei wskaźnik Cumulative Layout Shift (CLS) opisuje nieoczekiwane przesunięcia widocznych treści, na przykład gdy element wyświetlony później powoduje przesunięcie przycisku.

W ocenie w narzędziu PageSpeed Insights za dobry wynik uznaje się LCP do 2,5 sekundy włącznie, INP do 200 milisekund włącznie oraz CLS do 0,1 włącznie. CLS jest wartością bezwymiarową. Wartości progowe odnoszą się do poszczególnych wskaźników i nie należy ich mylić z czasem trwania pojedynczego wywołania strony.

Kluczowe znaczenie dla oceny terenu ma 75. percentyl (str. 75): Co najmniej około 75 procent uwzględnionych danych nie przekracza danej wartości. Z drugiej strony sama dobra średnia może przesłaniać fakt, że znaczna część odwiedzin przebiega powoli. Należy rozpatrywać urządzenia mobilne i stacjonarne oddzielnie, aby różnice między grupami urządzeń pozostały widoczne.

Wskaźnik „Time to First Byte” (TTFB) uzupełnia te wskaźniki podczas wyszukiwania przyczyn opóźnionego wyświetlania dokumentu. Wartość ta nie odzwierciedla jednak wyłącznie czasu obliczeniowego serwera: wpływ mają na nią również sieć oraz kolejne etapy procesu aż do otrzymania pierwszego bajtu odpowiedzi. Dane dotyczące czasu nawigacji (Navigation Timing) oraz, w razie potrzeby, udostępnione dane dotyczące czasu serwera (Server Timing) pomagają dokładniej zbadać poszczególne etapy tego procesu.

CrUX, własny RUM i laboratorium

Na początku nie musisz od razu korzystać z własnego systemu pomiarowego. PageSpeed Insights łączy dane terenowe z Raport dotyczący wrażeń użytkowników przeglądarki Chrome (CrUX) wraz z diagnostyką laboratoryjną Lighthouse. Te dwa widoki odpowiadają na różne pytania: jeden opisuje zebrane doświadczenia, drugi analizuje stronę w kontrolowanych warunkach.

Dane terenowe CrUX w narzędziu PageSpeed Insights odnoszą się do ostatniego okresu 28 dni. Jeśli dane dotyczące konkretnego adresu URL są niewystarczające, raport może zamiast tego wyświetlać dane dotyczące źródła. Obejmują one źródło powiązanej witryny i nie należy ich utożsamiać z doświadczeniami użytkowników na dokładnie tej samej stronie, co ta wprowadzona. Należy zatem zwrócić uwagę na to, jaki poziom faktycznie uwzględnia raport.

CrUX uwzględnia wyłącznie użytkowników przeglądarki Chrome, którzy spełniają odpowiednie wymagania; brakuje danych dotyczących innych przeglądarek oraz użytkowników niekwalifikujących się. W przypadku małych lub niepublicznych stron internetowych dane CrUX mogą być niekompletne. Własne gromadzenie danych, zgodne z przepisami prawnymi i wymogami technicznymi, może jednak zapewnić pewien wgląd w sytuację, choć przy niewielkiej liczbie odwiedzin jego wartość statystyczna pozostaje ograniczona.

Monitorowanie syntetyczne powtarza zdefiniowane testy, nawet jeśli w danym momencie nikt nie odwiedza strony internetowej. Nadaje się ono do regularnej obserwacji przebiegu procesu w podobnych warunkach. Na pytanie, czy użytkownicy korzystający z innych urządzeń lub sieci doświadczają tego samego, odpowiedź musi dać pomiar terenowy; pojedynczy przebieg syntetyczny nie zastępuje tego punktu widzenia.

Przy wyborze należy zatem wziąć pod uwagę pytanie, na które chcesz odpowiedzieć: publiczny raport jest szybko dostępny, natomiast własny system pozwala na bardziej ukierunkowane gromadzenie danych. Usługa może odciążyć dział operacyjny, podczas gdy badania laboratoryjne i testy syntetyczne umożliwiają przeprowadzenie kontrolowanych analiz. Jednak nawet usługa wymaga świadomego doboru danych i grup analitycznych.

Jak prawidłowo przygotować się do własnego pomiaru

Najpierw sformułuj konkretne pytanie, na przykład czy mobilne strony produktów częściej charakteryzują się wysokim wskaźnikiem LCP niż inne typy stron. Następnie określ, które strony i klasy urządzeń chcesz rozróżnić, jakie wskaźniki są do tego potrzebne oraz jak długo chcesz gromadzić dane. Dopiero potem zdecyduj o skrypcie pomiarowym, odbiorcach i analizie wyników.

Jako pierwszy krok techniczny możesz skorzystać z biblioteki web-vitals włączyć lokalnie w projekcie przeglądarki i obejrzeć wynik w narzędziach programistycznych. Poniższy kod JavaScript wykorzystuje opublikowaną wersję pakietu 6.2.3. Zakłada on, że ta wersja jest zainstalowana w projekcie, a kompilacja obsługuje import modułów. Przykład ten nie wysyła żadnych danych na serwer i nie aktywuje oddzielnego pomiaru nawigacji programowej.

import {onCLS, onINP, onLCP} from 'web-vitals';

onCLS(console.log);
onINP(console.log);
onLCP(console.log);

Wynik wyświetlany w konsoli to sposób na sprawdzenie integracji, a nie wskaźnik szybkości działania Twoich użytkowników. Otwórz stronę projektu i spróbuj na przykład skorzystać z filtra. Wartość INP wymaga odpowiedniej interakcji i nie musi pojawiać się od razu; bez odpowiedniej interakcji może w ogóle nie zostać wyświetlona. Na wynik wpływają również obsługa przeglądarki oraz cykl życia strony.

Zaplanuj na potrzeby późniejszej analizy Cykl życia strony Uwaga: zgłoszenia mogą pojawiać się wielokrotnie, na przykład gdy strona zostanie ukryta, a następnie ponownie wyświetlona. Nie należy traktować tych zgłoszeń jako niezależnych odwiedzin. Biblioteka udostępnia identyfikatory metryki, za pomocą których można przypisywać zgłoszenia do tej samej metryki.

Również przywrócenie z pamięci podręcznej Back/Forward wymaga określonego postępowania. Może ono wywołać nowy komunikat metryczny, mimo że dokument pochodzi z pamięci podręcznej. Określ, w jaki sposób w swoim raporcie odróżnisz takie przywrócenia od zwykłych operacji nawigacyjnych, i zapoznaj się ze szczegółowymi wskazówkami dotyczącymi biblioteki przed skonfigurowaniem gromadzenia danych w środowisku produkcyjnym.

Analiza wyników pomiarów według segmentów

Ogólna wartość dla sklepu może przesłaniać fakt, że właśnie mobilne strony produktów działają wolniej. Dlatego warto podzielić wyniki pomiarów przynajmniej według typu strony i klasy urządzenia oraz analizować każdy wskaźnik w określonym przedziale czasowym. W ten sposób można na przykład porównać mobilne strony produktów z mobilnymi stronami kategorii, zamiast nieświadomie mieszać różne sytuacje użytkowania.

Dla każdego segmentu jest to 75. percentyl jest bardziej miarodajny niż zwykła średnia: wskazuje wartość, której nie przekracza co najmniej około 75 procent uwzględnionych przypadków. Niska średnia może natomiast maskować fakt, że istotna grupa czeka długo. Porównania p75 należy przeprowadzać wyłącznie dla tej samej metryki i przy użyciu odpowiedniej jednostki miary.

Liczba prawidłowych wartości ma bezpośredni wpływ na wynik. Jeśli dany segment obejmuje tylko kilka pomiarów, pojedyncze wyniki mogą znacząco wpłynąć na wartość percentyla; zmiana nie musi wówczas wskazywać na ogólny problem. W razie potrzeby wybierz dłuższy okres lub połącz strony o podobnej tematyce, nie tracąc przy tym porównywalności wyników.

Brak wartości INP nie oznacza szybkiego INP i nie może być uwzględniony w rozkładzie jako zero. Zamiast tego należy podać oddzielnie liczbę prawidłowych wartości INP. Jeśli wiele wywołań nie dostarcza odpowiedniej interakcji, analiza INP opisuje jedynie zarejestrowane doświadczenia interakcyjne, a nie automatycznie wszystkie wywołania strony.

Należy odpowiednio grupować powtarzające się zgłoszenia na podstawie identyfikatora metryki, zamiast traktować każde zgłoszenie jako nową, niezależną obserwację. Należy również udokumentować sposób zliczania przywróceń z pamięci podręcznej typu „back/forward”. Dzięki temu będzie można prześledzić, które obserwacje faktycznie znajdują się w p75 i w podanej liczbie.

Od problemu w terenie do diagnozy

Jeśli dane z terenu wskazują na powolne ładowanie stron produktów na urządzeniach mobilnych, najpierw zawęź zakres analizy do odpowiedniego segmentu: czy słaby wskaźnik LCP dotyczy wielu produktów, czy tylko jednego typu strony? Sprawdź jednocześnie okres i liczbę prawidłowych wartości. W ten sposób uzyskasz punkt wyjścia do analizy, ale nie będziesz jeszcze mieć dowodu na to, który element powoduje opóźnienie.

Następnie umieść w Test laboratoryjny Odtwórz warunki jak najbardziej zbliżone do rzeczywistych, na przykład przy użyciu konfiguracji urządzenia mobilnego i ograniczonej prędkości sieci. Sprawdź, który element pojawia się jako LCP oraz kiedy jest ładowany i wyświetlany. Duży obraz produktu, opóźnione żądanie obrazu lub zablokowana ścieżka renderowania to możliwe hipotezy, które musisz zweryfikować na podstawie diagnozy.

Jeśli pojawią się informacje wskazujące na udostępnianie zdjęć, możesz sprawdzić rozmiar plików, formaty i sposób udostępniania. Jeden Sieć dostarczania treści jest to jeden z możliwych środków, ale nie gwarantuje poprawy wskaźnika LCP. Jeśli natomiast odpowiedź z dokumentu wskazuje na wąskie gardło, pomocne będzie dodatkowe Test wydajności serwera dla obciążeń PHP, w celu zbadania działania aplikacji w określonych warunkach.

W przypadku filtra opóźnionego decydujące znaczenie ma interakcja, a nie sam proces ładowania. Odtwórz kliknięcie filtra i sprawdź, jakie czynności są wykonywane, zanim widoczna aktualizacja nastąpi. Tam, gdzie przeglądarka to obsługuje, można Długie klatki animacji Wskazują na długotrwałe aktualizacje renderowania i związane z nimi skrypty; nie wyjaśniają jednak automatycznie każdego przypadku spowolnienia interakcji.

Wprowadź konkretną zmianę, a następnie ponownie obserwuj tę samą grupę stron w warunkach rzeczywistych. Lepszy wynik laboratoryjny wskazuje początkowo jedynie na efekt w wybranych warunkach testowych. Dopiero późniejsza analiza wyników z warunków rzeczywistych może wykazać, czy zmieniły się również odnotowane doświadczenia rzeczywistych użytkowników.

Jakość danych i ochrona danych w przedsiębiorstwie

Przed rozpoczęciem wdrożenia produkcyjnego określ, jakie wartości pomiarowe są niezbędne do rozwiązania Twojego problemu oraz kto będzie je przetwarzał. Planowanie powinno obejmować bezpieczne przekazywanie danych do odbiorcy, ograniczenia dostępu, ograniczony okres przechowywania oraz procedurę usuwania danych. W przypadku konkretnego wdrożenia należy sprawdzić kwestie dotyczące ochrony danych i zgody oraz obowiązujące przepisy z fachowego punktu widzenia, zamiast zakładać ogólne zezwolenie.

Z Minimalizacja danych Warto zwrócić uwagę na pola diagnostyczne: pełne adresy URL mogą zawierać poufne informacje w parametrach zapytania; również selektory DOM mogą ujawniać szczegóły dotyczące treści strony lub wprowadzonych danych. W miarę możliwości należy rejestrować ogólny typ strony oraz kilka starannie wybranych atrybutów. Sprawdź również, jakie dane dodatkowo gromadzi lub przechowuje zintegrowana usługa.

Wyniki pomiarów nie zawsze są dostępne od razu. Biblioteka web-vitals może generować komunikaty wielokrotnie w trakcie cyklu życia strony; dlatego też późniejszy komunikat nie może być automatycznie traktowany jako nowa, niezależna wizyta. Należy zaplanować sposób przetwarzania powiązanych komunikatów oraz postępowania w przypadku przywracania danych z pamięci podręcznej funkcji „Wstecz” i „Dalej”.

W przypadku niewielkich pakietów diagnostycznych transmisja może odbywać się za pośrednictwem sendBeacon podczas wydarzenia visibilitychange być odpowiednie. Zwiększa to szansę na wysłanie danych podczas ukrywania strony, ale nie gwarantuje ich dostarczenia. Odbiorca musi ponadto bezpiecznie przyjąć dane i przetworzyć je w taki sposób, aby powtarzające się komunikaty nie zafałszowały wyników analizy bez wiedzy użytkownika.

Na koniec weź pod uwagę Luki w rejestracji: Zablokowane skrypty, brak obsługi przez przeglądarkę lub utracone dane mogą powodować, że niektóre wizyty nie zostaną uwzględnione. Oszacuj przybliżony wskaźnik utraty danych wraz z rodzajem gromadzenia danych. Pozostałe wyniki pomiarów opisują obserwowaną grupę i niekoniecznie muszą odzwierciedlać wszystkich odwiedzających w równym stopniu.

Sprawdź zmiany i wybierz procedurę

Aby przeprowadzić porównanie po wdrożeniu, należy wcześniej określić, które typy stron, klasy urządzeń i okresy mają zostać uwzględnione. Dla każdego wskaźnika porównaj 75. percentyl oraz liczbę prawidłowych wartości przed i po zmianie. Podobnej długości przedziały czasowe pomagają w interpretacji wyników, jednak nie zapewniają one automatycznie wystarczającej liczby porównywalnych próbek.

Zwróć uwagę na zmiany w strukturze odwiedzających. Jeśli po wdrożeniu pojawi się więcej użytkowników korzystających z wolnych połączeń mobilnych, ogólny wynik może się pogorszyć, mimo że sama zmiana nie powoduje spowolnienia. Również sezonowość korzystania z serwisu lub inne równoczesne zmiany utrudniają przypisanie przyczyny. Związek czasowy jest zatem hipotezą, a nie Wykazanie związku przyczynowego.

CrUX i własny system RUM nie muszą dostarczać takich samych wyników: mogą obejmować różne grupy użytkowników, przedziały czasowe i warunki pomiaru. W przypadku CLS należy dodatkowo uwzględnić fakt, że CrUX uwzględnia również wkład ramek osadzonych w stronę nadrzędną. Pomiar za pomocą JavaScript w dokumencie głównym nie zawsze rejestruje ten wkład w pełni. Dlatego przed uznaniem rozbieżności za błąd należy najpierw porównać podstawy pomiaru.

W przypadku aplikacji jednostronicowej należy określić, czy chcesz analizować nawigację po dokumentach, czy też wewnętrzne zmiany trasy. W celu oddzielnego rejestrowania Miękka nawigacja obsługuje Web Vitals od wersji 6, o ile przeglądarka to obsługuje, opcję reportSoftNavs: true. Należy ją ustawić w odpowiednich wywołaniach zwrotnych metryki. Poprzedni przykład z konsoli, w którym nie zastosowano tej opcji, nie uruchamia oddzielnego pomiaru trasy.

Gdy włączono rejestrowanie nawigacji programowej, wartości CLS i INP dla nowej nawigacji są resetowane i rozpatrywane oddzielnie; wartości z poprzedniej nawigacji są zamykane przy zmianie trasy. Nie należy porównywać takich wartości, które są wyznaczane w innym przedziale czasowym, z pomiarami obejmującymi cały dokument bez ich uprzedniej weryfikacji. Bez odpowiedniej obsługi przez przeglądarkę opcja ta nie prowadzi do odpowiedniego, oddzielnego pomiaru trasy.

Przy wyborze usługi RUM należy sprawdzić nie tylko obsługę przeglądarek, ale także to, czy możliwe jest analizowanie wymaganych grup stron i klas urządzeń. Zapytaj o metody pobierania próbek, przetwarzanie danych, przechowywanie oraz możliwości eksportu. Równie ważne jest to, jaki wpływ na stronę może mieć sam skrypt pomiarowy oraz czy jego zakres pomiaru można ograniczyć do tego, co jest niezbędne do odpowiedzi na Twoje pytania.