O czym jest ten tekst i dla kogo?
Ten tekst jest dla DevOps, eCommerce Managerów i Project Managerów, którzy odpowiadają za monitorowanie działania aplikacji lub sklepu internetowego. Nowoczesne platformy to nie monolity. To systemy zależności: backend, frontend, integracje, third party apps i infrastruktura, nad którymi często nie masz pełnej kontroli.
Im większa aplikacja – tym mniej elementów działa w obszarze twojej infrastruktury. Skoro jesteś w sekcji Level Up w Monit24.pl to pewnie to wiesz. Skoro to czytasz być może oznacza jednak, że nie tak dobrze jak tego od siebie wymagasz.
Serwis Web Almanac wskazuje, że w 2024r. na przebadanych przez nich strony, 92% zawierało zasoby pobierane z zewnętrznych domen. Jest to ok. 49% łącznych requestów! Połowa komunikacji odbywa się poza twoją infrastrukturą!
Poniżej metodyka, której używali:
Jak widać wciągali do danych wszystko co się da. Przyglądamy się dalej a tam, im wyższy page rank tym więcej embeeded kodów (najlepiej aby były to reklamy). Żeby było weselej to sama grafika w serwisie źródłowym jest oczywiście embeedowana z Google Sheets.
I tutaj kluczowy wniosek. 26% zaciąganych treści to obrazki. 26%. 1/4 zaciąganych obiektów to obrazki. Sporo co nie ? Pomyśl o swoim sklepie czymkolwiek administrujesz, w końcu wszędzie coś oglądamy. Prawdę mówiąc zaskoczyło to nawet mnie podczas, gdy zbierałem dane do tego tekstu.
Sprawdźmy to w takim razie na naszym podwórku. Odwiedziłem bardzo, bardzo duży sklep i marketplace empik.pl, postawiony na platformie ecommerce Magento. Wizyta miała miejsce 18/02/2025 o godz. 16:04. Oczywiście wiem, że to jest kawał sklepu ale miejmy jakiś punkt odniesienia. Oczywiście pierwsze ok. 400 skryptów wskoczyło w przeciągu 1,5 sekundy. Doładowanie brakujących już trochę zajęło. I pełna zgoda, mogą to nie być krytyczne, z punktu widzenia UX rzeczy. Na pewno tak jest. Pytanie czy każdy jest tego świadomy i pozostawia właśnie nie krytyczny resources.
Jeśli więc twój serwis/sklep działa wolno, ma problemy z funkcjonowaniem dla użytkowników, albo konwersja spada bez wyraźnej przyczyny – problemem nie musi być twój backend ani hosting. Statystycznie masz niemal 50% szans, że problem, który powoduje że sklep działa wolno, znajduje się poza Twoją infrastrukturą. To oznacza, że klasyczne application performance monitoring (APM), skoncentrowane wyłącznie na serwerze, daje Ci tylko połowę obrazu. Monitoring aplikacji bez monitorowania third party, to iluzja kontroli.
Zobacz, duży sklep to system zależności. Załóżmy, że jest oparty o jedną z tych platform: Magento, Shopify, WooCommerce. Z perspektywy architektury mamy:
- bazę danych
- CDN
- hosting
- integracje ERP
- integracje płatności
- marketing automation (to nie tylko kod JS do identyfikacji i śledzenia użytkownika)
- systemy rekomendacji
- systemy analityczne
- czasami feed do marketplace
- system opinii
I to by było mniej więcej tyle. Z perspektywy przeglądarki użytkownika wygląda to jednak zupełnie inaczej.
Zanim przeglądarka w ogóle wyśle pierwszy request HTTP do Twojego serwera, musi rozwiązać nazwę domenową. A to oznacza zapytanie do DNS. Jeśli korzystasz z zewnętrznego operatora DNS (a korzystasz niemal na pewno), to właśnie on jest pierwszym third party w całym łańcuchu.
Jeśli jego infrastruktura:
- ma opóźnienia,
- ma regionalne problemy,
- jest objęta atakiem DDoS,
- ma błędną propagację rekordu,
to użytkownik może nawet nie dotrzeć do Twojego serwisu. Backend może działać idealnie. Hosting sklepu może mieć 100% SLA. A i tak „nie działa”.
W kontekście monitorowania działania aplikacji DNS to absolutny punkt krytyczny — bo jeśli on zawiedzie, cała reszta przestaje mieć znaczenie.
Warstwa szyfrowania SSL/TLS to kolejny element, o którym rzadko myślimy w kontekście wydajności i ryzyka. Jeszcze długa droga zanim user wejdzie na stronę, co nie ?
Podczas nawiązywania połączenia HTTPS przeglądarka nie tylko negocjuje szyfrowanie, ale również weryfikuje ważność certyfikatu. W tym celu może wysłać zapytanie do serwera OCSP (Online Certificate Status Protocol) utrzymywanego przez wystawcę certyfikatu.
Schemat wygląda tak:
przeglądarka użytkownika → serwer OCSP → dopiero potem Twoja aplikacja
To oznacza kolejne third party w łańcuchu zależności.
Jeśli serwer OCSP odpowiada wolno lub znajduje się w odległej lokalizacji, czas ładowania strony z perspektywy użytkownika wydłuża się — zanim backend w ogóle zacznie przetwarzać request.
W Twoim application performance monitoring (APM) wszystko może wyglądać poprawnie:
- serwer odpowiada szybko,
- baza działa,
- SLA hostingu jest dotrzymane.
A mimo to aplikacja działa wolno.
Dlatego monitorowanie działania aplikacji powinno obejmować cały proces nawiązywania połączenia — nie tylko backend. Bez observability 360 nie zobaczysz, że problem leży poza Twoją infrastrukturą.
Wejdźmy wreszcie na stronę!
Jakie przeważnie elementy ładujemy „z zewnątrz” ? Podzielmy sobie to na kilka oszarów:
1. Analityka:
– Google Analytics
– piksele reklamowe, kluczowe remarketingu (a pamiętaj, że utracony koszyk to 70% transakcji o czym pisaliśmy tutaj)
– systemy testów A/B
2. Ramki rekomendacji produktów – bardzo istotne nie tylko dla samego x-sell czy up-sell ale coraz częściej aby w ogóle wrzucić produkt do koszyka zakupowego. Wśród nich:
– silniki rekomendacji
– prostsze boxy np. „podobne produkty”
3. Systemy płatności – $$$ – tylko najwięksi gracze nie korzystają z zewnętrznego dostawcy. Osadzenie procesu płatności, bez przekierowania na zewnątrz z tokenem transakcji to większa konwersja. Do niej potrzeujesz:
– iframe
– walidator kart
– pamiętaj o 3D Secure
4. Systemy opinii:
– widgety ocen
– biblioteki JS
– API do zaciągania komentarzy
5. Zewnętrzne czcionki i zasoby statyczne:
– fonty
– biblioteki JS
– frameworki CSS
6. Marketplace/integracje, które muszą być up-to-date aby porpawić UX:
– feed produktowy (xml to nieraz cały skład jak: opis, zdjęcia, wersje, ceny itd.)
– synchronizacja cen (i cen archiwalnych do 30 dni)
– dostępność i stan magazynowy
7. Embeed. Wszelkie materiały hostowane na zewnątrz. To nie tylko wideo z YouTube z recenzją produktu. To również iframe twojej platformy elearning, w intranecie klienta.
Każdy z tych elementów wykonuje osobny request, posiada (lub nie) swoje SLA, może generować timeout i renderowanie.
Dlaczego więc klasyczne podejście Application Performance Monitoring (APM) jest niewystarczające?
APM monitoruje twój backend. Serwer, zapytania do bazy, czas odpowiedzi i ewentualnie szuka błędów w samym działaniu procesów składających się na twoją aplikację.
Co znajdziesz w APM jeśli zewnętrzne serwisy:
– odpowiadają zbyt wolno
– blokują renderowanie
– generują błędy
– nie ładują się wcale (!)
APM powie, że:
Dziwne, u mnie działa.
¯_(ツ)_/¯
Tymczasem po drugiej stronie przeglądarki:
– przycisk „Przejdź do płatności” nie wysyła eventu
– sklep muli
– aplikacja pracuje z błędami
– użytkownicy wchodzący z mobile mają timeout
I ty nic o tym nie wiesz.
Dlatego badanie końcowego rezultatu, co konkretnie widzi użytkownik to tak istotna sprawa aby uzyskać Observability 360. Odwiedzając stronę i odtwarzając konkretny proces, automatycznie i z różnych lokalizacji zbierasz dane z frontu. Te dane pokażą tobie:
– waterfall requestów
– co blokuje LCP
– które third parties generują błędy
– itd. itd.
Musisz widzieć różnicę pomiędzy „u mnie działa, serwer działa” a „użytkownikowi nie działa.
SLA a realna dostępność. SLA mierzy dostępność usługi. Jeśli spada musisz o tym wiedzieć bo za tym idą problemy dla ciebie.
Gdzie popełniamy kluczowe błędy, szukając rozwiązań?
W pierwszej kolejności firmy inwestują w hosting i skalowanie backendu. Szybsza maszyna i wydajniejszy stack to dosłownie połowa sukcesu. Ignorują fakt, że około połowa requestów nie trafia do ich serwera.
Brakuje pełnej widoczności na warstwie przeglądarki. Spójrzmy na to szerzej, możesz myśleć, że twój serwis to backend + hosting.
Nie
Twój serwis to: backend + frontend + third party apps + integracje + CDN + przeglądarka użytkownika.
Co warto zapamiętać ?
1. Około połowa requestów pochodzi z zewnętrznych domen. Sprawdź jak to wygląda w twoim serwisie. Oceń, które są krytyczne i monitoruj ich poprawne ładowanie.
2. Zastanów się czy masz lub czy możesz przygotować sobie backup dla kluczowych źródeł.
3. Trace routing. To często słabo zaadresowany obszar. Kluczowe są tutaj dwie rzeczy.
– Jak dużo pakietów pożera użytkownik? (Ilość)
– Dokąd je ściąga? (Geolokalizcja)
To jak podróż samolotem. Więcej kroków w trace routing to dłuższy czas ładowania, i możliwość zagubienia walizek…pakietów.
4. APM bez RUM (Real User Monitoring) nie daje pełnej widoczności
Chcesz sprawdzić to w praktyce? Umów demo i zobacz:
- ile requestów nie trafia do Twojej infrastruktury,
- które third party spowalniają sklep,
- gdzie tracisz konwersję,
- jak szybko możesz dostać powiadomienie o błędzie zanim zrobi to dział sprzedaży.
Bo „u mnie działa” to za mało.
Źródła:
https://almanac.httparchive.org/en/2024/third-parties
https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2024/third-parties/percent_of_third_parties_by_content_type.sql
