Jak mierzyć wydajność hostingu — narzędzia i metryki

Opublikowano: 9 kwietnia 2026 · Kategoria: Wydajność, Hosting

"Szybki hosting" to jedno z najczęściej nadużywanych pojęć w marketingu dostawców. Zamiast wierzyć obietnicom, zmierz wydajność samodzielnie — za pomocą narzędzi dostępnych bezpłatnie. Ten artykuł przeprowadzi Cię przez metryki, które naprawdę mają znaczenie (TTFB, Core Web Vitals), oraz narzędzia do ich mierzenia (ab, wrk, k6, GTmetrix, PageSpeed Insights).

TTFB — najważniejsza metryka serwera

Time to First Byte (TTFB) mierzy czas od wysłania żądania HTTP do otrzymania pierwszego bajtu odpowiedzi. To metryka najbliżej samego serwera — eliminuje zmienne takie jak renderowanie przeglądarki czy JavaScript.

Szybki pomiar TTFB przez curl:

# Pomiar TTFB przez curl (5 pomiarów)
for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://twoja-domena.pl/
done

# Jeden pomiar z pełnymi metrykami
curl -o /dev/null -s -w "
DNS lookup:      %{time_namelookup}s
TCP connect:     %{time_connect}s
TLS handshake:   %{time_appconnect}s
TTFB:            %{time_starttransfer}s
Total:           %{time_total}s
" https://twoja-domena.pl/

Apache Bench (ab) — podstawowy test obciążenia

ab (Apache Benchmark) jest wbudowany w pakiet apache2-utils na Ubuntu. Prosty w użyciu, dobry do pierwszych testów.

apt install -y apache2-utils

# Podstawowy test: 1000 żądań, 10 jednoczesnych połączeń
ab -n 1000 -c 10 https://twoja-domena.pl/

# Kluczowe wyniki w raporcie:
# Requests per second: X [#/sec] — przepustowość
# Time per request:    X [ms]    — średni czas odpowiedzi
# Time per request (across all concurrent requests): X [ms]
# Transfer rate:       X [Kbytes/sec]
#
# Percentage of the requests served within a certain time (ms):
#   50%    120    <-- mediana
#   90%    250    <-- 90. percentyl
#   99%    800    <-- ogon (tail latency)

# Test z niestandardowym nagłówkiem (symuluj prawdziwą przeglądarkę)
ab -n 500 -c 20 -H "Accept-Encoding: gzip" https://twoja-domena.pl/

Interpretacja wyników ab: Requests per second to przepustowość serwera przy danym concurrency. Percentyle latency (50%, 90%, 99%) pokazują rozkład — uwagę zwracaj na 99. percentyl, który reprezentuje najgorsze doświadczenie użytkownika. Wysoki 99. percentyl przy niskim 50. oznacza sporadyczne problemy (np. garbage collection, lock contention w DB).

wrk — wielowątkowy test obciążenia

wrk generuje znacznie większe obciążenie niż ab, używając wielu wątków i asynchronicznych połączeń. Dobry do testów pod realnym obciążeniem.

# Instalacja wrk
apt install -y wrk

# Podstawowy test: 12 wątków, 400 połączeń, 30 sekund
wrk -t12 -c400 -d30s https://twoja-domena.pl/

# Przykładowy wynik:
# Running 30s test @ https://twoja-domena.pl/
#   12 threads and 400 connections
#   Thread Stats   Avg    Stdev    Max   +/- Stdev
#     Latency    45.23ms  12.11ms  280.4ms  89.12%
#     Req/Sec    852.34   102.45   1.21k    72.00%
#   Latency Distribution
#     50%   40.12ms
#     75%   52.34ms
#     90%   67.89ms
#     99%   120.45ms
#   305,234 requests in 30.10s, 2.89GB read
# Requests/sec:  10141.56
# Transfer/sec:   98.23MB

# Lżejszy test (nie przeciążaj hostingu współdzielonego!)
wrk -t4 -c50 -d15s https://twoja-domena.pl/

Uwaga dla hostingu współdzielonego: Nie używaj wrk z dużym concurrency na shared hostingu — dostawca może zawiesić konto za "nadmierne obciążenie". Test z -c50 to bezpieczne maksimum. Na VPS możesz testować z wyższymi wartościami.

k6 — nowoczesne load testing

k6 to nowoczesne narzędzie do testów obciążenia z obsługą JavaScript do pisania scenariuszy. Idealne gdy chcesz testować sekwencje żądań (login → przeglądaj produkty → dodaj do koszyka).

# Instalacja k6 (Ubuntu)
gpg -k
gpg --no-default-keyring \
    --keyring /usr/share/keyrings/k6-archive-keyring.gpg \
    --keyserver hkp://keyserver.ubuntu.com:80 \
    --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] \
    https://dl.k6.io/deb stable main" \
    | tee /etc/apt/sources.list.d/k6.list
apt update && apt install k6

// test-hosting.js — scenariusz k6
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 20 },   // ramp-up do 20 VU
    { duration: '1m',  target: 20 },   // utrzymaj 20 VU przez 1 min
    { duration: '30s', target: 0 },    // ramp-down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],  // 95% żądań < 500ms
    http_req_failed:   ['rate<0.01'],  // max 1% błędów
  },
};

export default function () {
  const res = http.get('https://twoja-domena.pl/');
  check(res, {
    'status 200': (r) => r.status === 200,
    'TTFB < 500ms': (r) => r.timings.waiting < 500,
  });
  sleep(1);
}

k6 run test-hosting.js

GTmetrix i PageSpeed Insights — real-world pomiary

Narzędzia syntetyczne (ab, wrk) mierzą sam serwer. GTmetrix i Google PageSpeed Insights mierzą doświadczenie użytkownika — włącznie z renderowaniem przeglądarki, JavaScript i zasobami zewnętrznymi.

• GTmetrix (gtmetrix.com) — bezpłatny, raport Waterfall (co ładuje się kiedy), ocena A–F, pomiar z różnych lokalizacji. Pokazuje TTFB, Fully Loaded Time, rozmiar strony, liczbę żądań.
• Google PageSpeed Insights (pagespeed.web.dev) — oficjalne narzędzie Google, mierzy Core Web Vitals na podstawie danych Field Data (rzeczywistych użytkowników Chrome). Wynik 0–100 dla mobile i desktop.
• WebPageTest (webpagetest.org) — najbardziej szczegółowy, filmuje ładowanie strony, filmstrip view, pomiar z wielu lokalizacji i przeglądarek.

Core Web Vitals

Hosting bezpośrednio wpływa na LCP i FCP przez TTFB — im szybciej serwer wygeneruje odpowiedź, tym wcześniej przeglądarka zacznie renderować stronę. CLS i INP zależą głównie od kodu frontendu i JavaScript — zmiana hostingu ich nie poprawi.

Jak porównać dwa hostingi przed migrację

Metodologia fair comparison:

1. Postaw identyczną instalację WordPress na obu hostingach — ten sam motyw, te same wtyczki, te same dane testowe (importuj XML z WP Exporter)
2. Wyłącz cache dla fair comparison — sprawdź wydajność generowania dynamicznego, nie cache'a
3. Zmierz TTFB przez curl z 10 pomiarów, wylicz medianę
4. Uruchom ab -n 200 -c 10 na obu, porównaj req/s i 99. percentyl latency
5. Sprawdź GTmetrix Score dla obu hostingów z tej samej lokalizacji i o tej samej porze dnia
6. Włącz cache (W3 Total Cache lub LiteSpeed Cache) i powtórz pomiary — to realna wydajność w produkcji

Najczęstsze pytania