Jak mierzyć wskaźniki internetowe za pomocą używanego obecnie narzędzia do analityki.
Możliwość pomiaru i raportowania skuteczności stron w rzeczywistych warunkach jest kluczowa do diagnozowania i ulepszania skuteczności w czasie. Bez danych nie można mieć pewności, czy wprowadzone zmiany w witrynie przynoszą oczekiwane rezultaty.
Wielu popularnych dostawców usług analitycznych Real User Monitoring (RUM) udostępnia w swoich narzędziach dane podstawowych wskaźników internetowych (a także wiele innych wskaźników internetowych). Jeśli korzystasz obecnie z jednego z tych narzędzi analitycznych RUM, możesz ocenić, na ile strony w Twojej witrynie spełniają zalecane wartości podstawowych wskaźników wydajności witryny i zapobiegać regresji w przyszłości.
Chociaż zalecamy korzystanie z narzędzi analitycznych obsługujących wskaźniki Core Web Vitals, jeśli używane przez Ciebie narzędzie analityczne ich nie obsługuje, nie musisz się przełączać. Prawie wszystkie narzędzia analityczne umożliwiają definiowanie i mierzenie danych niestandardowych lub zdarzeń, co oznacza, że możesz używać obecnego dostawcy usług analitycznych do pomiaru danych Core Web Vitals i dodawania ich do dotychczasowych raportów i paneli analitycznych.
W tym przewodniku przedstawiamy sprawdzone metody pomiaru podstawowych wskaźników internetowych (lub dowolnych danych niestandardowych) za pomocą zewnętrznego lub własnego narzędzia analitycznego. Może ona też służyć jako przewodnik dla dostawców usług analitycznych, którzy chcą dodać obsługę podstawowych wskaźników internetowych w swoich usługach.
Korzystanie z danych lub zdarzeń niestandardowych
Jak już wspomnieliśmy, większość narzędzi analitycznych umożliwia pomiar danych niestandardowych. Jeśli Twoje narzędzie analityczne obsługuje tę funkcję, możesz mierzyć wszystkie podstawowe wskaźniki internetowe za pomocą tego mechanizmu.
Pomiar danych niestandardowych lub zdarzeń w narzędziu analitycznym polega zazwyczaj na wykonaniu 3 kroków:
- Zdefiniuj lub zarejestruj dane niestandardowe w panelu administracyjnym narzędzia (jeśli to konieczne). (Uwaga: nie wszyscy dostawcy usług analitycznych wymagają wcześniejszego definiowania danych niestandardowych).
- Oblicz wartość danych w kodzie JavaScript po stronie klienta.
- Prześlij wartość rodzaju danych do backendu usługi analitycznej, pamiętając, aby nazwa lub identyfikator były zgodne z definicją w kroku 1 (ponowne sprawdzenie w razie potrzeby).
Instrukcje dotyczące kroków 1 i 3 znajdziesz w dokumentacji narzędzia analitycznego. W kroku 2 możesz użyć biblioteki JavaScript web-vitals, aby obliczyć wartość każdego z podstawowych wskaźników internetowych.
Poniższy przykładowy kod pokazuje, jak łatwo można śledzić te dane w kodzie i przesyłać je do usługi analitycznej.
import {onCLS, onINP, onLCP} from 'web-vitals';
function sendToAnalytics({name, value, id}) {
const body = JSON.stringify({name, value, id});
// Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
Unikaj średnich wartości
Możesz mieć pokusę, aby zsumować zakres wartości danych dotyczących skuteczności, obliczając średnią. Na pierwszy rzut oka średnie wydają się wygodne, ponieważ stanowią przejrzyste podsumowanie dużej ilości danych, ale nie należy się na nich opierać przy interpretacji skuteczności strony.
Średnie są problematyczne, ponieważ nie odzwierciedlają sesji żadnego pojedynczego użytkownika. Wyjątki w obu zakresach rozkładu mogą zniekształcać średnią w sposób wprowadzający w błąd.
Na przykład niewielka grupa użytkowników może korzystać z bardzo wolnych sieci lub urządzeń, które mają wartości zbliżone do maksymalnego zakresu, ale nie generują wystarczającej liczby sesji, aby wpłynąć na średnią w sposób sugerujący, że występuje problem.
W miarę możliwości korzystaj z wartości percentylowych zamiast średnich. Przedziały procentowe w przypadku danego rozkładu danych o skuteczności lepiej opisują pełny zakres wrażeń użytkowników Twojej witryny. Dzięki temu możesz skupić się na podzbiorach rzeczywistych doświadczeń, co zapewni Ci więcej informacji niż jakakolwiek pojedyncza wartość.
Sprawdzanie, czy możesz zgłosić rozpowszechnianie
Gdy obliczysz wartości dla każdego z rodzajów danych Core Web Vitals i wyślesz je do usługi analitycznej za pomocą danych lub zdarzeń niestandardowych, utwórz raport lub panel z wyświetlanymi wartościami.
Aby mieć pewność, że spełniasz zalecane progi Podstawowych wskaźników internetowych, musisz wyświetlić w raporcie wartość każdego wskaźnika w 75. percentylu.
Jeśli narzędzie analityczne nie oferuje raportowania kwantyli jako wbudowanej funkcji, możesz te dane uzyskać ręcznie, generując raport, który zawiera listę wszystkich wartości wskaźnika posortowanych w kolejności rosnącej. Po wygenerowaniu tego raportu wynik, który znajduje się w 75% części pełnej, posortowanej listy wszystkich wartości w tym raporcie, będzie odpowiadał 75. percentylowi danego rodzaju danych. Będzie tak niezależnie od tego, jak podzielisz dane na segmenty (np. według typu urządzenia, typu połączenia czy kraju).
Jeśli narzędzie analityczne domyślnie nie zapewnia szczegółowości raportowania na poziomie danych, możesz uzyskać ten sam wynik, jeśli narzędzie to obsługuje wymiary niestandardowe. Jeśli w każdym przypadku danych, które śledzisz, ustawisz unikalną wartość wymiaru niestandardowego, możesz wygenerować raport z podziałem na poszczególne przypadki danych, pod warunkiem że uwzględnisz wymiar niestandardowy w konfiguracji raportu. Każde wystąpienie będzie mieć unikalną wartość wymiaru, więc nie będzie dochodziło do grupowania.
Raport Web Vitals to przykład techniki, która korzysta z Google Analytics. Kod raportu jest oprogramowaniem open source, więc deweloperzy mogą go używać jako przykładu technik opisanych w tej sekcji.
Wysyłaj dane we właściwym czasie
Niektóre dane o skuteczności można obliczyć po zakończeniu wczytywania strony, a inne (np. CLS) uwzględniają cały okres działania strony i są ostateczne dopiero po rozpoczęciu jej wylogowywania.
Może to jednak stanowić problem, ponieważ zdarzenia beforeunload i unload nie są niezawodne (zwłaszcza na urządzeniach mobilnych), a ich używanie nie jest zalecane (mogą one uniemożliwić stronie spełnienie wymagań Back-Forward Cache).
W przypadku danych, które śledzą cały okres istnienia strony, najlepiej jest wysyłać bieżącą wartość danych w ramach zdarzenia visibilitychange, gdy tylko stan widoczności strony zmieni się na hidden. Dzieje się tak, ponieważ po zmianie stanu widoczności strony na hidden nie ma gwarancji, że jakikolwiek skrypt na tej stronie będzie mógł zostać ponownie uruchomiony. Dotyczy to szczególnie systemów operacyjnych mobilnych, w których aplikacja przeglądarki może zostać zamknięta bez wywołania żadnych wywołań zwrotnych strony.
Pamiętaj, że systemy operacyjne urządzeń mobilnych zwykle wywołują zdarzenie visibilitychange, gdy użytkownik przełącza karty, aplikacje lub zamyka przeglądarkę.
Zdarzenie visibilitychange jest też uruchamiany podczas zamykania karty lub przechodzenia na nową stronę. Dzięki temu zdarzenie visibilitychange jest znacznie bardziej niezawodne niż zdarzenia unload lub beforeunload.
Monitorowanie skuteczności na przestrzeni czasu
Gdy zaktualizujesz implementację usług analitycznych, aby śledzić i raportować dane podstawowe wskaźniki internetowe, następnym krokiem będzie śledzenie, jak zmiany w witrynie wpływają na jej wydajność w czasie.
Numerowanie wersji zmian
Naiwnym (i ostatecznie niewiarygodnym) podejściem do śledzenia zmian jest wdrożenie zmian w produkcji, a potem założenie, że wszystkie dane otrzymane po dacie wdrożenia dotyczą nowej witryny, a wszystkie dane otrzymane przed datą wdrożenia dotyczą starej witryny. Jednak może to uniemożliwić wiele czynników (w tym buforowanie na poziomie HTTP, usługi lub CDN).
Znacznie lepszym podejściem jest utworzenie unikalnej wersji dla każdej wdrożonej zmiany, a następnie śledzenie tej wersji w narzędziu analitycznym. Większość narzędzi analitycznych obsługuje ustawianie wersji. Jeśli nie, możesz utworzyć wymiar niestandardowy i ustawić go w wersji wdrożenia.
Eksperymentuj
Możesz stosować wersjowanie na jeszcze wyższym poziomie, śledząc jednocześnie wiele wersji (lub eksperymentów).
Jeśli Twoje narzędzie analityczne umożliwia definiowanie grup eksperymentalnych, użyj tej funkcji. Możesz też użyć wymiarów niestandardowych, aby mieć pewność, że wszystkie wartości danych będą mogły być powiązane z konkretną grupą eksperymentalną w raportach.
Dzięki eksperymentom w statystykach możesz wdrożyć zmianę eksperymentalną w podzbiorze użytkowników i porównać jej skuteczność z wynikami użytkowników z grupy kontrolnej. Gdy będziesz mieć pewność, że zmiana rzeczywiście poprawia skuteczność, możesz wdrożyć ją dla wszystkich użytkowników.
Zapewnienie, że pomiar nie wpływa na wydajność
Podczas pomiaru wydajności na podstawie danych pochodzących od rzeczywistych użytkowników bardzo ważne jest, aby kod pomiaru wydajności nie miał negatywnego wpływu na wydajność strony. W takim przypadku wszelkie wnioski, które spróbujesz wyciągnąć na temat wpływu skuteczności na Twoją firmę, będą niewiarygodne, ponieważ nigdy nie dowiesz się, czy to właśnie obecność kodu analityki ma największy negatywny wpływ.
Podczas wdrażania kodu analitycznego RUM w witrynie produkcyjnej zawsze przestrzegaj tych zasad:
Odkładanie analizy
Kod Analytics powinien być wczytywany asynchronicznie, bez blokowania innych procesów, i zwykle jako ostatni. Jeśli kod analityczny jest ładowany w sposób blokujący, może to negatywnie wpłynąć na LCP.
Wszystkie interfejsy API używane do pomiaru podstawowych wskaźników internetowych zostały zaprojektowane z myślą o obsługiwaniu asynchronicznym i opóźnionym ładowania skryptów (za pomocą flagi buffered), więc nie musisz się spieszyć z wcześniejszym wczytywaniem skryptów.
Jeśli mierzisz dane, których nie można obliczyć później w ramach harmonogramu wczytywania strony, wstawiaj w kod HTML <head> dokumentu tylko kod, który musi zostać uruchomiony wcześniej, aby nie blokować renderowania. Pozostałą część kodu odłóż na później. Nie wczytuj wszystkich danych analitycznych wcześniej tylko dlatego, że wymaga tego jeden rodzaj danych.
Nie twórz długich zadań
Kod Analytics często działa w odpowiedzi na działania użytkownika, ale jeśli wykonuje on wiele pomiarów DOM lub korzysta z innych interfejsów API wymagających dużej mocy obliczeniowej, może to powodować niską responsywność. Jeśli plik JavaScript zawierający kod analityczny jest duży, jego wykonanie może zablokować główny wątek i niekorzystnie wpłynąć na czas od interakcji do następnego wyświetlenia (INP) strony.
Korzystanie z interfejsów API, które nie blokują
Interfejsy API takie jak sendBeacon() i requestIdleCallback() są specjalnie zaprojektowane do wykonywania zadań nieistotnych w taki sposób, aby nie blokować zadań istotnych dla użytkownika.
Te interfejsy API to świetne narzędzia do korzystania z biblioteki analitycznej RUM.
Ogólnie wszystkie sygnały analityczne powinny być wysyłane za pomocą interfejsu API sendBeacon() (jeśli jest dostępny), a wszystkie kody pomiarów analityki pasywnej powinny być uruchamiane w okresach bezczynności.
Nie śledź więcej niż potrzebujesz
Przeglądarka udostępnia wiele danych o wydajności, ale to, że są one dostępne, nie oznacza, że należy je rejestrować i przesyłać na serwery Analytics.
Na przykład interfejs Resource Timing API udostępnia szczegółowe dane o czasie wczytywania poszczególnych zasobów na stronie. Nie jest jednak prawdopodobne, aby wszystkie te dane były niezbędne lub przydatne do poprawy wydajności ładowania zasobów.
Krótko mówiąc, nie śledź danych tylko dlatego, że są dostępne. Zanim zaczniesz wykorzystywać zasoby na ich śledzenie, upewnij się, że dane będą używane.