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 z pola nie można mieć pewności, czy wprowadzone w witrynie zmiany rzeczywiście 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ędzia analitycznego, które obsługuje 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 opisujemy sprawdzone metody pomiaru podstawowych wskaźników internetowych (lub dowolnych danych niestandardowych) za pomocą wewnętrznych lub zewnętrznych narzędzi analitycznych. 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ę, będziesz w stanie mierzyć każdy z podstawowych wskaźników internetowych za pomocą tego mechanizmu.
Pomiar niestandardowych danych lub zdarzeń za pomocą narzędzia analitycznego składa się zwykle z 3 etapó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ść wskaźnika w kodzie JavaScript frontendu.
- Prześlij wartość rodzaju danych do backendu usługi analitycznej, upewniając się, że nazwa lub identyfikator odpowiadają tym zdefiniowanym w kroku 1 (jeśli to konieczne).
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
Sugerujemy podsumowanie zakresu wartości wskaźników skuteczności poprzez wyliczenie średniej. Na pierwszy rzut oka średnie wydają się wygodne, ponieważ stanowią uporządkowane 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 powolnych sieci lub urządzeń, które zbliżają się do maksymalnego zakresu wartości, ale liczba sesji użytkowników nie jest wystarczająca, aby wpływać na średnią w sposób sugerujący problem.
W miarę możliwości korzystaj z wartości percentylowych zamiast średnich. Centyl rozkładu danego wskaźnika skuteczności lepiej opisuje pełny zakres wrażeń użytkowników 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 wyświetlający zebrane wartości.
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 Twoje narzędzie analityczne nie udostępnia raportowania kwantyli jako wbudowanej funkcji, możesz nadal uzyskać te dane ręcznie, generując raport, który zawiera listę wszystkich wartości danych 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 Twoje narzędzie analityczne nie zapewnia domyślnie szczegółowości raportowania na poziomie danych, możesz prawdopodobnie osiągnąć taki sam wynik, jeśli obsługuje wymiary niestandardowe. Ustawienie unikalnej, niepowtarzalnej wartości wymiaru niestandardowego dla każdej śledzonej instancji danych powinno umożliwić wygenerowanie raportu z podziałem na poszczególne przypadki danych, jeśli uwzględnisz wymiar niestandardowy w konfiguracji raportu. Ponieważ każde wystąpienie będzie miało unikalną wartość wymiaru, grupowanie nie będzie mieć miejsca.
Przykładem tej metody z wykorzystaniem Google Analytics jest raport dotyczący wskaźników internetowych. Kod raportu to open source, więc deweloperzy mogą wykorzystać go jako przykład techniki opisanej 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, podczas gdy inne (np. CLS) uwzględniają cały okres jej działania i są ostateczne dopiero po rozpoczęciu ładowania strony.
Może to jednak być problematyczne, 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 samą aplikację przeglądarki.
Zdarzenie visibilitychange jest też uruchamiany, gdy użytkownik zamyka kartę lub przechodzi na nową stronę. Dzięki temu zdarzenie visibilitychange jest znacznie bardziej niezawodne niż zdarzenia unload i 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.
Wersja zmian
Naiwne (i ostatecznie nierzetelne) podejście do śledzenia zmian polega na wdrażaniu zmian w środowisku produkcyjnym i przy założeniu, że wszystkie wskaźniki otrzymane po dacie wdrożenia odpowiadają nowej witrynie, a wszystkie dane zebrane przed datą wdrożenia odpowiadają starej witrynie. 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 osobnej wersji dla każdej wdrożonej zmiany, a potem śledzenie tej wersji w narzędziu analitycznym. Większość narzędzi analitycznych umożliwia ustawienie wersji. Jeśli nie, możesz utworzyć wymiar niestandardowy i przypisać go do 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ć zmiany eksperymentalne w podzbiorze użytkowników i porównać ich 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 skuteczności na podstawie danych pochodzących od rzeczywistych użytkowników bardzo ważne jest, aby kod pomiaru skutecznoś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 operacji, i zwykle jako ostatni. Jeśli kod analityczny jest wczytywany 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 dokumentie <head> tylko kod, który musi być wykonywany wczesnej, aby nie blokować renderowania, a resztę 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 uruchamia się w odpowiedzi na dane wejściowe użytkownika, ale jeśli wykonuje on wiele pomiarów DOM lub korzysta z innych interfejsów API wymagających dużej mocy procesora, sam kod Analytics może powodować słabą responsywność na dane wejściowe. 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 pomiarowe służące do pasywnej analizy powinny być wykonywane w okresach bezczynności.
Ś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 Resource Timing API dostarcza szczegółowe dane o czasie dla każdego zasobu wczytanego na stronie. Jednak mało prawdopodobne jest, że wszystkie te dane będą niezbędne do poprawy wydajności wczytywania 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.