Jak testujemy hostingi

1. Przegląd — cztery filary testów

Każdy hosting w rankingu testujemy tymi samymi czterema metodami, codziennie i na tych samych warunkach:

• TTFB — 20 pojedynczych żądań do strony głównej
• Test obciążeniowy — 32 równoczesne żądania do strony głównej i REST API
• Audyt techniczny — pełna diagnostyka zaplecza serwera (cache, baza danych, CPU, dysk)
• Wsparcie klienta — ręczne, cykliczne testy e-mail/czat/telefon

Wszystkie pomiary trafiają do bazy danych i są podstawą wyniku widocznego w rankingu — dokładny sposób przeliczania ich na punkty 0–100 opisujemy osobno na stronie Jak liczymy.

2. Test TTFB — pojedyncze żądania

Codziennie wysyłamy 20 kolejnych, pojedynczych żądań do strony głównej każdego hostingu. TTFB (czas do pierwszej odpowiedzi) mierzymy nie na podstawie zwykłego pomiaru czasu w kodzie, tylko realnego czasu transferu zgłaszanego przez bibliotekę cURL (starttransfer_time) — to dokładniejszy pomiar niż mierzenie czasu "na oko" od wysłania do otrzymania odpowiedzi.

Z 20 pomiarów liczymy pełny zestaw statystyk: średnią, medianę, percentyl 50. i 95., maksimum, odchylenie standardowe oraz odsetek żądań wolniejszych niż 3 i 5 sekund. Jeśli wszystkie 20 żądań zawiedzie, test kończy się błędem i nie zapisujemy żadnego wyniku za ten dzień — wolimy brak danych niż fałszywie dobry wynik.

3. Test obciążeniowy — wielu użytkowników naraz

Pojedyncze żądanie nie pokazuje, jak hosting zachowuje się pod realnym ruchem. Dlatego osobno wysyłamy 32 żądania z równoległością 8 (czyli 8 żądań jednocześnie, falami) — dwukrotnie: raz do strony głównej, raz do REST API (/wp-json/), które odpowiada za cały ruch dynamiczny, w tym operacje sklepów WooCommerce.

Kluczowy szczegół techniczny: czas każdego żądania mierzymy indywidualnie (przez ten sam mechanizm cURL co w teście TTFB), a nie jako czas trwania całej puli — inaczej każde pojedyncze żądanie "dziedziczyłoby" czas całej fali, co fałszywie zawyżałoby wynik. Osobno liczymy też odsetek błędów oraz liczbę przekroczeń czasu (timeoutów) — to one najbardziej obrazują realną niestabilność serwera pod obciążeniem.

4. Audyt techniczny zaplecza

Poza czasami odpowiedzi z zewnątrz, każdego dnia odpytujemy też wtyczkę zainstalowaną na testowej instalacji WordPress o pełną diagnostykę techniczną "od środka": obecność OPcache, Redis i Memcache, szybkość połączenia i operacji bazy MySQL, wydajność procesora (operacje całkowitoliczbowe, tekstowe, JSON, regex, hash), limit i przepustowość pamięci, szybkość odczytu/zapisu dysku (w tym losowe IOPS) oraz przepustowość transferu.

To właśnie ten audyt pokazuje różnice, których nie widać z zewnątrz — dwa hostingi mogą mieć podobny TTFB w spokojnym momencie, ale zupełnie inną konfigurację zaplecza, która ujawni się dopiero przy większym obciążeniu lub cięższych operacjach (np. duża baza produktów w sklepie).

5. Ręczne testy wsparcia klienta

Tego testu nie da się zautomatyzować — wymaga realnej rozmowy z konsultantem. Cyklicznie kontaktujemy się z każdym hostingiem tymi samymi kanałami: e-mail, czat i telefon, a wynik ocenia siedem aspektów — od czasu odpowiedzi, przez dostępność i łatwość kontaktu, po jakość merytoryczną udzielonej odpowiedzi i warunki migracji strony. Pełne wagi tych elementów opisujemy w sekcji o wsparciu na stronie Jak liczymy.

6. Realne instalacje WordPress

Na każdym testowanym hostingu utrzymujemy prawdziwą, działającą instalację WordPress — nie testujemy "z zewnątrz" losowych stron demo. Do zbierania audytu technicznego korzystamy z własnej wtyczki (mu-plugin), zainstalowanej bezpośrednio na tej instalacji, uwierzytelnionej unikalnym tokenem dla każdego hostingu — dzięki temu diagnostyka jest dokładna i pochodzi bezpośrednio z serwera, na którym faktycznie działa strona.

7. Harmonogram — jak często testujemy

Wszystkie cztery testy dla wszystkich aktywnych hostingów uruchamiamy codziennie, jedną wspólną paczką zadań, o tej samej porze. Po zakończeniu wszystkich pomiarów danego dnia, wyniki są od razu przeliczane na punkty rankingowe — dlatego ranking na stronie głównej pokazuje zawsze najświeższe dostępne dane, a historię wyników każdego hostingu (dzień po dniu) możesz zobaczyć na jego własnej podstronie.

8. Co się dzieje, gdy test się nie uda

Jeśli test danego dnia zawiedzie w 100% prób (np. hosting jest chwilowo niedostępny), świadomie nie zapisujemy wyniku za ten dzień zamiast wpisać sztucznie zerowy rekord. Taki "zerowy" wynik zaniżałby nie tylko wynik tego jednego hostingu, ale zniekształcałby też punktację wszystkich pozostałych — bo normalizacja wyników odbywa się względem najlepszego i najgorszego wyniku w danym dniu, pośród wszystkich testowanych hostingów (dokładnie opisane na stronie Jak liczymy). Brak danych za jeden dzień nie wpływa więc negatywnie na żaden hosting — jego wynik po prostu nie aktualizuje się tego konkretnego dnia.