Jak mierzyć wskaźniki internetowe za pomocą obecnie używanego narzędzia do analizy.
Możliwość pomiaru i raportowania rzeczywistej wydajności stron ma kluczowe znaczenie dla diagnozowania i poprawy wydajności w miarę upływu czasu. Bez danych zgromadzonych nie da się określić, czy zmiany, które wprowadzasz w witrynie, przynoszą oczekiwane rezultaty.
Wielu popularnych dostawców analityki Real User Monitoring (RUM) obsługuje już w swoich narzędziach podstawowe wskaźniki internetowe (a także wiele innych wskaźników internetowych). Jeśli korzystasz obecnie z jednego z tych narzędzi analitycznych RUM, możesz łatwo ocenić, w jakim stopniu strony w Twojej witrynie spełniają zalecane wartości progowe podstawowych wskaźników internetowych, i zapobiec regresjom w przyszłości.
Chociaż zalecamy korzystanie z narzędzia analitycznego, które obsługuje takie dane, nie musisz zmieniać ustawień, jeśli używane obecnie narzędzie do analityki ich nie obsługuje. Prawie wszystkie narzędzia analityczne umożliwiają definiowanie i mierzenie danych niestandardowych lub zdarzeń. Oznacza to, że prawdopodobnie możesz korzystać z usług swojego obecnego dostawcy analityki, aby mierzyć podstawowe wskaźniki internetowe i dodawać je do istniejących raportów i paneli analitycznych.
W tym przewodniku omawiamy sprawdzone metody pomiaru podstawowych wskaźników internetowych (lub dowolnych danych niestandardowych) za pomocą narzędzia analitycznego firmy zewnętrznej lub narzędzia analitycznego wewnętrznego. Może też służyć jako przewodnik dla dostawców rozwiązań analitycznych, którzy chcą dodać do swojej usługi obsługę podstawowych wskaźników internetowych.
Używanie 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ę, powinno być możliwe mierzenie za pomocą tego mechanizmu wszystkich podstawowych wskaźników internetowych.
Pomiar niestandardowych danych lub zdarzeń w narzędziu analitycznym składa się zwykle z trzech etapów:
- Zdefiniuj lub zarejestruj dane niestandardowe u administratora narzędzia (w razie potrzeby). (Uwaga: nie wszyscy dostawcy usług analitycznych wymagają wcześniejszego określenia danych niestandardowych).
- Oblicz wartość wskaźnika w kodzie JavaScript frontendu.
- Wyślij wartość wskaźnika do backendu analityki, upewniając się, że nazwa lub identyfikator są zgodne z definicją podaną w kroku 1 (w razie potrzeby).
Kroki 1 i 3 znajdziesz w dokumentacji Twojego narzędzia analitycznego. W kroku 2 możesz użyć biblioteki JavaScript web-vitals, aby obliczyć wartość wszystkich podstawowych wskaźników internetowych.
Poniższy przykładowy kod pokazuje, jak łatwo można śledzić te wskaźniki w kodzie i wysyłać je do usługi analitycznej.
import {onCLS, onFID, 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);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);
Unikaj średnich wartości
Podsumowanie zakresu wartości wskaźnika wydajności przez obliczenie średniej jest bardzo kuszące. Średnie na pierwszy rzut oka wydają się przydatne, ponieważ są uporządkowanym podsumowaniem dużej ilości danych, ale lepiej się ich oprzeć i oceniać wydajność strony.
Średnie wartości są problematyczne, ponieważ nie reprezentują sesji pojedynczego użytkownika. Wartości odstające w obu zakresach rozkładu mogą zniekształcać średnią w mylący sposób.
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 nie uwzględniają wystarczającej liczby sesji użytkowników, aby wpłynęły na średnią w sposób sugerujący problem.
Jeśli to możliwe, polegaj na centylach zamiast na wartościach średnich. Centyle rozkładu danego wskaźnika skuteczności lepiej opisują pełny zakres wrażeń użytkownika witryny. Dzięki temu możesz skupić się na podzbiorach rzeczywistych doświadczeń, co daje Ci więcej statystyk niż pojedyncza wartość.
Sprawdź, czy możesz zgłosić dystrybucję
Gdy już obliczysz wartości wszystkich podstawowych wskaźników internetowych i prześlesz je do usługi analitycznej za pomocą niestandardowych danych lub zdarzeń, kolejnym krokiem jest utworzenie raportu lub panelu wyświetlającego zgromadzone wartości.
Aby mieć pewność, że osiągasz zalecane wartości progowe podstawowych wskaźników internetowych, Twój raport będzie wyświetlał wartości poszczególnych danych na 75. percentylu.
Jeśli Twoje narzędzie analityczne nie oferuje wbudowanej funkcji raportowania kwantylowego, prawdopodobnie nadal możesz uzyskać te dane ręcznie, generując raport zawierający wszystkie wartości wskaźników posortowaną w kolejności rosnącej. Wynik, który po wygenerowaniu raportu obejmuje 75% całej, posortowanej listy wszystkich wartości w tym raporcie, będzie 75. centylem dla tych danych – niezależnie od tego, jak posegmentujesz dane (według typu urządzenia, typu połączenia, kraju itd.).
Jeśli Twoje narzędzie analityczne nie zapewnia domyślnie szczegółowości raportowania na poziomie danych, prawdopodobnie uzyskasz taki sam wynik, o ile obsługuje ono wymiary niestandardowe. Ustawiając niepowtarzalną, niestandardową wartość wymiaru dla każdego śledzonego wystąpienia danych, możesz wygenerować raport z podziałem na poszczególne wystąpienia danych (o ile uwzględnisz go w konfiguracji raportu). Każde wystąpienie będzie miało unikalną wartość wymiaru, więc grupowanie nie nastąpi.
Przykładem tej metody korzystającej z Google Analytics jest raport dotyczący wskaźników internetowych. Kod raportu to kod open source, więc deweloperzy mogą wykorzystać go jako przykład technik opisanych w tej sekcji.
Wysyłaj dane we właściwym czasie
Niektóre wskaźniki wydajności można obliczać po zakończeniu wczytywania strony, inne (np. CLS) uwzględniają cały okres jej życia, a są ostateczne dopiero po rozpoczęciu jej wyładowywania.
Może to jednak być problem, ponieważ zarówno zdarzenia beforeunload, jak i unload nie są wiarygodne (zwłaszcza na urządzeniach mobilnych), a ich użycie jest niezalecane (ponieważ mogą uniemożliwić stronom kwalifikację do pamięci podręcznej stanu strony internetowej).
W przypadku wskaźników, które śledzą cały okres ważności strony, przy każdej zmianie stanu widoczności strony na hidden najlepiej jest przesyłać dowolną aktualną wartość w trakcie zdarzenia visibilitychange. Dzieje się tak, ponieważ po zmianie stanu widoczności strony na hidden nie ma gwarancji, że każdy skrypt na tej stronie zostanie ponownie uruchomiony. Dotyczy to zwłaszcza mobilnych systemów operacyjnych, w których aplikację przeglądarki można zamknąć bez wywoływania wywołań zwrotnych strony.
Pamiętaj, że systemy operacyjne mobilne zwykle uruchamiają zdarzenie visibilitychange, gdy przechodzisz między kartami, przełączasz aplikacje lub zamykają przeglądarkę.
Uruchamiają też zdarzenie visibilitychange, gdy zamykają kartę lub otwierają nową stronę. Dzięki temu zdarzenie visibilitychange jest znacznie bardziej niezawodne niż zdarzenie unload lub beforeunload.
Monitorowanie skuteczności na przestrzeni czasu
Następnym krokiem po zaktualizowaniu analityki jest śledzenie i raportowanie podstawowych wskaźników internetowych, jak zmiany w witrynie wpływają na jej wydajność w dłuższym okresie.
Wersja wprowadzonych zmian
Naiwne (i ostatecznie niewiarygodne) podejście do śledzenia zmian polega na wdrożeniu zmian w środowisku produkcyjnym i założeniu, że wszystkie wskaźniki otrzymane po dacie wdrożenia odpowiadają nowej witrynie, a wszystkie wskaźniki otrzymane przed datą wdrożenia odpowiadają starej witrynie. Jednak może to uniemożliwić ze względu na różne czynniki (m.in. pamięć podręczną w pamięci HTTP, skrypt service worker lub warstwę CDN).
Znacznie lepiej jest utworzyć osobną wersję dla każdej wdrożonej zmiany, a potem śledzić ją w narzędziu analitycznym. Większość narzędzi analitycznych obsługuje ustawianie wersji. Jeśli wymiar niestandardowy nie istnieje, możesz utworzyć wymiar niestandardowy i ustawić go na wdrożoną wersję.
Eksperymentuj
Możesz pójść o krok dalej, śledząc wiele wersji (lub eksperymentów) jednocześnie.
Jeśli Twoje narzędzie analityczne umożliwia definiowanie grup eksperymentalnych, korzystaj z tej funkcji. W przeciwnym razie możesz użyć wymiarów niestandardowych, by mieć pewność, że każda wartość danych zostanie powiązana w raportach z konkretną grupą eksperymentalną.
Dzięki eksperymentom w statystykach możesz wprowadzić zmianę eksperymentalną na podzbiorze użytkowników i porównać jej skuteczność ze skutecznością użytkowników w grupie kontrolnej. Gdy będziesz mieć pewność, że zmiana rzeczywiście poprawia skuteczność, możesz ją wdrożyć na wszystkich kontach użytkowników.
Upewnij się, że pomiary nie wpływają na skuteczność
Przy pomiarze skuteczności reklam u rzeczywistych użytkowników absolutnie kluczowe jest to, aby używany przez Ciebie kod do pomiaru skuteczności nie wpływał negatywnie na wydajność strony. Jeśli tak, wszelkie wnioski, które spróbujesz wyciągnąć w związku z wpływem skuteczności na działalność, będą niemiarodajne, ponieważ nigdy nie dowiesz się, czy sam kod analityczny ma największy negatywny wpływ.
Podczas wdrażania kodu analitycznego RUM w witrynie produkcyjnej przestrzegaj zawsze tych zasad:
Odłóż analizy
Kod Analytics powinien być zawsze ładowany w sposób asynchroniczny, nieblokujący i zwykle powinien być ładowany jako ostatni. Wczytywanie kodu analitycznego w sposób blokujący może negatywnie wpłynąć na LCP.
Wszystkie interfejsy API służące do pomiaru podstawowych wskaźników internetowych zostały zaprojektowane pod kątem obsługi asynchronicznego i odroczonego wczytywania skryptów (za pomocą flagi buffered), więc nie trzeba się spieszyć, żeby szybko załadować skrypty.
Jeśli mierzysz dane, których nie można obliczyć później na osi czasu wczytywania strony, umieść w nich tylko kod, który musi się pojawić na początku w elemencie <head> dokumentu (dzięki czemu nie będzie to żądanie blokujące renderowanie), a resztę odłóż na później. Nie ładuj wszystkich statystyk wcześniej,
tylko dlatego, że wymaga tego pojedynczy wskaźnik.
Nie twórz długich zadań
Kod Analytics często uruchamia się w odpowiedzi na dane wejściowe użytkownika. Jeśli jednak Twój kod Analytics przeprowadza dużo pomiarów DOM lub korzystasz z innych interfejsów API obciążających procesor, sam kod analityczny może powodować słabą responsywność na dane wejściowe. Poza tym, jeśli plik JavaScript, który zawiera kod Analytics, jest duży, jego uruchomienie może zablokować wątek główny i niekorzystnie wpłynąć na opóźnienie po pierwszym działaniu (FID) lub interakcję z kolejnym wyrenderowaniem (INP).
Użyj nieblokujących interfejsów API
Interfejsy API takie jak sendBeacon() i requestIdleCallback() zostały zaprojektowane do uruchamiania mniej ważnych zadań w sposób, który nie blokuje zadań o znaczeniu krytycznym dla użytkowników.
Te interfejsy API są świetnymi narzędziami do wykorzystania w bibliotece analityki RUM.
Ogólnie wszystkie sygnały Analytics powinny być wysyłane za pomocą interfejsu sendBeacon() API (jeśli jest dostępny), a cały pasywny kod pomiarowy powinien być uruchamiany w okresach bezczynności.
Nie śledź więcej, niż potrzebujesz
Przeglądarka udostępnia wiele danych o wydajności. Nie musi to jednak oznaczać, że trzeba je rejestrować i wysyłać na serwery analityczne.
Na przykład interfejs Resource Timing API zapewnia szczegółowe dane o czasie w przypadku każdego zasobu wczytywanego na stronie. Jest jednak mało prawdopodobne, że wszystkie te dane będą konieczne lub przydatne w zwiększaniu wydajności wczytywania zasobów.
Krótko mówiąc, nie warto po prostu śledzić danych, które istnieją, ale upewnij się, że zostaną one wykorzystane, zanim zużyjesz zasoby, które je śledzą.