Zaprezentowany diagram ilustruje wyniki przeprowadzonych testów:
| Informacje o stronie | ||
|---|---|---|
| Wyświetlenie po | 1.431 s | i |
| Pobieranie | 2.815 s | i |
| Całkowity czas wczytania | 4.395 s | i |
| Czas powtórnego wczytania | 1.609 s | i |
| Ilość przekierowań (wpisanego adresu) | 1 | i |
| Ilość żądań | 145 | i |
| Łącznie przesłane | 6.71 MB | i |
| Pomijane przy powtórnym ładowaniu | 6.47 MB (96%) | i |
| Rozmiar rzeczywisty | 8.29 MB | i |
To właśnie są testy wydajnościowe – dokładnie takie parametry jak czasy ładowania, liczba żądań HTTP, rozmiar przesyłanych danych czy ilość przekierowań analizuje się w praktyce podczas oceny wydajności stron internetowych. Moim zdaniem ten typ testów jest absolutnie kluczowy w projektowaniu nowoczesnych aplikacji webowych, bo użytkownicy szybko rezygnują, jeśli strona się długo ładuje albo jest zbyt zasobożerna. W branży zwraca się obecnie ogromną uwagę na to, by strony były 'lekkie', szybkie i zoptymalizowane pod kątem przesyłu danych. Nawet Google premiuje szybkie serwisy w wynikach wyszukiwania, co niejeden programista już odczuł na własnej skórze. Testy wydajnościowe sprawdzają, jak aplikacja zachowuje się pod dużym obciążeniem i ile danych realnie pobierają użytkownicy. W praktyce polecam korzystać z narzędzi takich jak Google Lighthouse, WebPageTest czy nawet prosty DevTools w przeglądarce – pozwalają szybko wyłapać największe problemy z czasem ładowania. Warto też pamiętać, że optymalizacja wydajności to nie tylko lepsze wrażenia użytkownika, ale bardzo wymierne oszczędności na transferze i infrastrukturze. Dobry zwyczaj to cyklicznie monitorować te wskaźniki, nawet gdy wydaje się, że wszystko działa OK – bo sytuacja może się szybko zmienić po wdrożeniu nowych funkcjonalności lub zmianach w kodzie.
W analizowanym przykładzie pojawia się kilka pojęć, które mogą wprowadzać w błąd, jeśli ktoś nie pracował wcześniej z testami stron internetowych. Sugerowanie, że prezentowany diagram dotyczy testów ochrony, funkcjonalności albo użyteczności, to całkiem powszechne nieporozumienie. Testy ochrony skupiają się na sprawdzaniu zabezpieczeń aplikacji, takich jak podatność na ataki XSS, SQL Injection, czy poprawność autoryzacji i uwierzytelniania – tutaj nie znajdziemy informacji o żadnych czasach ładowania czy transferach danych. Z kolei testowanie funkcjonalności to klasyczne sprawdzanie, czy dana funkcja robi, co powinna, zgodnie ze specyfikacją; typowe pytania to tu 'czy użytkownik może zarejestrować konto' albo 'czy przycisk działa'. W prezentowanym diagramie nie ma żadnych opisów związanych z zachowaniem funkcji czy elementów interfejsu. Użyteczność natomiast, choć ważna, dotyczy komfortu korzystania z serwisu, przejrzystości nawigacji, intuicyjności – czyli czy użytkownik łatwo znajdzie potrzebne informacje, jak ocenia czytelność itp. To analizuje się przez badania z użytkownikami, ankiety, testy A/B, a nie przez pomiary czasów ładowania czy liczby zapytań HTTP. Typowy błąd w rozumowaniu bierze się z mylenia ogólnego pojęcia testowania z konkretnymi typami testów i ich celami – a każda z wymienionych kategorii ma zupełnie inne wskaźniki i metody pomiaru. W praktyce warto nauczyć się szybko rozpoznawać, do której kategorii należy dany raport lub wykres, bo pozwala to lepiej diagnozować problemy i dobrać właściwe narzędzia do ich rozwiązania.