Monitoring syntetyczny testuje Twoją stronę lub API za pomocą skryptowanych żądań według harmonogramu – niezależnie od tego, czy ktoś ją odwiedza. Real User Monitoring (RUM) mierzy to, czego doświadczają prawdziwi odwiedzający, za pomocą skryptu w ich przeglądarkach, ale tylko wtedy, gdy faktycznie odwiedzają stronę. Testy syntetyczne mówią Ci, że coś przestało działać, często zanim zauważą to klienci. RUM pokazuje, jak szybko i płynnie działa strona dla osób, które z niej korzystają, na ich urządzeniach i w ich sieciach. Zacznij od testów syntetycznych sprawdzających dostępność, a RUM dodaj, gdy wydajność dla prawdziwych odwiedzających stanie się pytaniem, na które musisz znać odpowiedź.
Jak działa monitoring syntetyczny
Usługa monitorująca wciela się w odwiedzającego. Ze znanej lokalizacji, według stałego harmonogramu, wysyła żądanie lub uruchamia skrypt i ocenia wynik. Ponieważ za każdym razem robi to samo, wyniki kolejnych testów można ze sobą porównywać, a awaria o 03:00 zostaje wykryta o 03:00 – bez potrzeby jakiegokolwiek ruchu. Monitoring syntetyczny występuje w kilku formach:
Testy dostępności: jedno żądanie do adresu URL, hosta lub portu, sprawdzane pod kątem kodu statusu, czasu odpowiedzi i często treści. To najprostszy rodzaj – zobacz, czym jest monitorowanie dostępności.
Testy API: żądanie z metodą, nagłówkami i treścią oraz weryfikacja zwróconego JSON-a.
Scenariusze wieloetapowe: ścieżka taka jak logowanie czy zakup, wykonywana krok po kroku jako zwykłe żądania HTTP lub w prawdziwej przeglądarce, która uruchamia JavaScript.
Laboratoryjne testy wydajności: narzędzie takie jak Lighthouse ładuje stronę na symulowanym urządzeniu i w symulowanej sieci, a następnie ją ocenia.
Jak działa Real User Monitoring
Real User Monitoring dodaje skrypt do Twoich stron. W przeglądarce każdego odwiedzającego odczytuje czasy, które przeglądarki udostępniają przez standardowe API, takie jak Navigation Timing, i wysyła je do kolektora. Po zebraniu danych z wielu wizyt otrzymujesz rozkłady: jak długo ładują się strony, jak szybko reagują na kliknięcia, które strony zgłaszają błędy JavaScript – z podziałem na kraje, urządzenia i przeglądarki.
Ponieważ wyniki to rozkłady, RUM podaje percentyle, a nie pojedyncze liczby. Wskaźniki Core Web Vitals od Google mierzy się na 75. percentylu wczytań stron, z takimi progami dobrego doświadczenia:
Largest Contentful Paint (ładowanie): 2,5 sekundy lub mniej.
Interaction to Next Paint (responsywność): 200 milisekund lub mniej.
Cumulative Layout Shift (stabilność wizualna): 0,1 lub mniej.
Istnieją też dane RUM, których nie zbierasz samodzielnie. Chrome UX Report (CrUX) od Google publikuje dane terenowe od użytkowników Chrome, którzy się na to zgadzają, dla poszczególnych stron i całych witryn – gdy ruch jest wystarczający. To z tych danych Google korzysta przy ocenie Core Web Vitals w wyszukiwarce.
Porównanie
Monitoring syntetycznyReal User MonitoringKto generuje daneUsługa monitorująca, według harmonogramuTwoi odwiedzający, gdy odwiedzają stronęWymaga ruchuNieTakWymaga skryptu na stronachNieTakWykrywa awarięTak, przy następnym teściePośrednio, gdy przestają napływać daneObejmujeStrony i ścieżki, które oskryptujeszKażdą stronę, którą odwiedzają ludzieUrządzenia i sieciKilka znanychWszystkie, z których korzystają Twoi odwiedzającyWynikiSukces lub błąd, czas dla każdego testuRozkłady i percentyleNajlepszy doDostępności, alertów, wyłapywania regresji po wdrożeniachRzeczywistej wydajności, Core Web Vitals, błędów w przeglądarce
Czego nie widzi każde z nich
Martwe pola monitoringu syntetycznego
Ścieżki, których nie oskryptowałeś. Jeśli scenariusz zakupu testuje jeden produkt, zepsuta strona innej kategorii przejdzie niezauważona.
Miejsca, w których są Twoi odwiedzający. Test z jednego miasta widzi trasę z tego miasta do Twojego serwera, a nie trasę odwiedzającego korzystającego z sieci komórkowej na innym kontynencie.
Prawdziwe urządzenia. Wolny telefon, rozszerzenie przeglądarki lub stara wersja przeglądarki mogą zepsuć lub spowolnić stronę, która przechodzi każdy test.
Martwe pola RUM
Brak odwiedzających, brak danych. W nocy, na nowej stronie lub na witrynie o małym ruchu RUM ma niewiele lub nic do powiedzenia.
Awarie. Gdy strona nie działa, skrypt w ogóle się nie ładuje, więc nic nie zostaje zgłoszone. Lukę na wykresie łatwo przeoczyć, a do tego nikogo nie obudzi.
Odwiedzający, których nie da się zmierzyć. Blokery reklam i wybory dotyczące zgód mogą zatrzymać skrypt, więc dane opisują tylko odwiedzających, którzy na to pozwalają.
Obciążenie. Sam skrypt to dodatkowa praca dla strony. Ładuj go asynchronicznie i sprawdź jego rozmiar.
Dane laboratoryjne a dane terenowe
Ten sam podział pojawia się w narzędziach do pomiaru wydajności, gdzie mówi się o danych laboratoryjnych (lab) i terenowych (field). Wynik Lighthouse to dane laboratoryjne: jedno syntetyczne wczytanie strony na symulowanym telefonie ze średniej półki i w symulowanej sieci. CrUX i Twój własny RUM to dane terenowe: to, co zmierzyły prawdziwe wizyty. Często się nie zgadzają. Strona może wypaść słabo w laboratorium, a mimo to spełniać Core Web Vitals w terenie, bo większość odwiedzających ma szybkie urządzenia – albo odwrotnie. Dane laboratoryjne wykorzystuj do znajdowania i naprawiania problemów oraz porównywania kolejnych wydań, a dane terenowe do oceny tego, co faktycznie dostają odwiedzający. Wskazówki, jak przyspieszyć ładowanie strony, pomogą w obu przypadkach, a tekst o tym, jaki czas odpowiedzi jest dobry, omawia stronę serwerową.
Od czego zacząć
Każda strona: syntetyczne testy dostępności strony głównej i stron, które zarabiają pieniądze. Awaria kosztuje więcej niż wolna strona, a niezawodnie zaalarmują Cię o niej tylko testy syntetyczne. Lista kontrolna tego, co monitorować, wymienia adresy URL warte objęcia testami.
Sklepy i produkty SaaS: dodaj scenariusze wieloetapowe dla zakupu lub logowania, by wyłapać zepsutą ścieżkę nawet wtedy, gdy każda pojedyncza strona odpowiada kodem 200.
Strony, dla których liczy się ruch z wyszukiwarki: obserwuj Core Web Vitals z CrUX i codzienny test laboratoryjny, by zauważyć wolne wydanie, zanim odbije się na pozycjach w wynikach.
Duże lub globalne grono odbiorców, złożony front-end: dodaj RUM, by widzieć wydajność i błędy JavaScript według kraju, urządzenia i strony.
Jak działają razem
Wyobraź sobie sklep, który we wtorek po południu wdraża nowy proces zakupu. W środę o 03:12 krok płatności zaczyna przekraczać limit czasu. Nikt nie robi zakupów, więc RUM nie pokazuje niczego nietypowego, ale syntetyczny scenariusz zakupu kończy się błędem, drugi test to potwierdza, a dyżurny programista dostaje alert. O 03:30 problem jest naprawiony. W czwartek RUM pokazuje, że Interaction to Next Paint w nowym procesie zakupu podwoił się dla odwiedzających z Androidem – czego żaden test syntetyczny z szybkiego serwera by nie zauważył. Jedno narzędzie wyłapało awarię, drugie spowolnienie. Tak zwykle wygląda ten podział pracy.
Co obejmuje Uptimecheck, a czego nie
Uptimecheck to usługa monitoringu syntetycznego. Nie dodaje skryptu RUM do Twoich stron, więc do pomiaru czasów i błędów JavaScript u Twoich odwiedzających używaj obok niego dedykowanego narzędzia RUM. Co robi Uptimecheck:
Monitorowanie dostępności: testy HTTP(S), ping i portów nawet co minutę ze Sztokholmu, Londynu i Nowego Jorku, ze sprawdzaniem słów kluczowych, JSON-a i nagłówków, a każda awaria jest potwierdzana z drugiej lokalizacji przed wysłaniem alertu. Czasy odpowiedzi są rozbite na DNS, połączenie, TLS, serwer i pobieranie.
Monitorowanie scenariuszy: do 10 kroków, takich jak otwarcie strony, logowanie, wysłanie formularza czy wywołanie API, z wartościami przekazywanymi z kroku do kroku. Scenariusze oparte na zwykłych żądaniach mogą działać co minutę; scenariusze w prawdziwej przeglądarce uruchamiają JavaScript i kliknięcia najwyżej co 15 minut, ze zrzutem ekranu kroku, który się nie powiódł.
Monitorowanie szybkości stron: codzienny test Lighthouse na urządzeniach mobilnych i desktopie dla strony startowej i maksymalnie 4 kolejnych stron, a dla stron i witryn z wystarczającą liczbą wizyt – dane z Chrome UX Report o tym, czego doświadczyli prawdziwi użytkownicy Chrome w ciągu 28 dni. Dostajesz alert, gdy wynik strony spadnie poniżej ustalonego przez Ciebie progu.
Aby skonfigurować ścieżkę, zobacz, jak monitorować logowanie lub zakup za pomocą scenariusza oraz jak sprawdzać szybkość stron. Plany zaczynają się od 9 € miesięcznie przy płatności rocznej lub 12 € przy płatności miesięcznej, netto (bez VAT); szczegóły znajdziesz w cenniku.
Dowiedz się o awarii, zanim powiedzą Ci o niej odwiedzający. Wypróbuj Uptimecheck za darmo przez 14 dni, bez karty kredytowej.