TTFB: co to jest, ile powinien wynosić i jak go poprawić

TTFB (Time to First Byte) to czas między wysłaniem żądania HTTP a otrzymaniem pierwszego bajtu odpowiedzi od serwera. To z pozoru prosta miara, ale jest jednym z najlepszych wskaźników tego, co dzieje się po stronie serwera.

Dlaczego TTFB jest ważny?

Każda strona zaczyna się od TTFB. Zanim przeglądarka może cokolwiek załadować, musi dostać odpowiedź od serwera. Jeśli TTFB wynosi 2 sekundy, Twój LCP nie może być niższy niż ~2 sekundy, nawet jeśli sam HTML jest mały i wszystkie zasoby są idealnie zoptymalizowane.

Google uwzględnia TTFB pośrednio w Core Web Vitals, głównie przez LCP. W raporcie PageSpeed Insights znajdziesz wskazówkę “Reduce server response time” jeśli TTFB jest za wysoki.

W monitoringu dostępności (takim jak RankVoyager) TTFB jest mierzony przy każdym sprawdzeniu. Nagły wzrost TTFB, nawet jeśli strona nadal zwraca 200 OK, może sygnalizować przeciążenie serwera lub problem z bazą danych zanim dojdzie do pełnej awarii.

Jakie wartości TTFB są akceptowalne?

Google rekomenduje TTFB poniżej 600 ms dla “dobrego” wyniku w audycie Lighthouse. Ale to dość ogólna wytyczna.

W praktyce:

poniżej 200 ms: doskonale, serwer odpowiada błyskawicznie
200-600 ms: OK dla większości stron, szczególnie z dynamiczną treścią
600 ms-1 s: powoli, warto zbadać przyczynę
powyżej 1 s: problem, który trzeba naprawić

Dla serwisów statycznych (generowanych przez Astro, Next.js SSG, Hugo) TTFB poniżej 100 ms jest osiągalny nawet z przyzwoitego hostingu.

Z czego składa się TTFB?

TTFB to suma kilku etapów:

DNS lookup: czas na przetłumaczenie nazwy domeny na adres IP
TCP handshake: nawiązanie połączenia z serwerem
TLS handshake (dla HTTPS): weryfikacja certyfikatu i ustalenie szyfrowania
Czas przetwarzania serwera: czas od odebrania żądania do wysłania pierwszego bajtu odpowiedzi

Etapy 1-3 zależą od lokalizacji serwera i infrastruktury sieciowej. Etap 4 to czas przetwarzania po stronie aplikacji.

Częsty błąd: ktoś optymalizuje aplikację (skraca czas generowania odpowiedzi) i jest zdziwiony, że TTFB nie spada. Powodem jest wolny DNS lub brak HTTP/2, który wymaga nowego TCP handshake dla każdego zasobu.

Jak mierzyć TTFB?

Chrome DevTools

Otwórz DevTools (F12), zakładkę Network, odśwież stronę. Kliknij na pierwszy zasób (zwykle główny HTML). W zakładce Timing zobaczysz rozbicie na TTFB i pozostałe etapy.

Narzędzie curl

curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null -s "https://example.com"

Google PageSpeed Insights

Raport PSI pokazuje TTFB w sekcji “Diagnostics”. Dane field (Chrome UX) pokazują median TTFB dla prawdziwych użytkowników.

Monitoring ciągły

Jednorazowy pomiar nie wystarczy. TTFB może być niski o 2:00 w nocy i wysoki w godzinach szczytu. Ciągły monitoring, jak w RankVoyager, mierzy TTFB przy każdym sprawdzeniu i archiwizuje historię. Dzięki temu widać trend, a nie tylko snapshot.

Najczęstsze przyczyny wysokiego TTFB

Wolne zapytania do bazy danych

Aplikacja PHP/Python/Node.js czeka na wynik zapytania do bazy przed odesłaniem odpowiedzi. Jedno wolne zapytanie (full table scan, brak indeksów) może dodać 500 ms-2 s do TTFB.

Diagnoza: włącz logowanie wolnych zapytań w MySQL/PostgreSQL i sprawdź, które zapytania trwają najdłużej.

Brak cache’owania odpowiedzi

Każde żądanie generuje odpowiedź od zera: pobiera dane z bazy, renderuje template, zwraca HTML. Przy 10 równoległych żądaniach serwer jest 10 razy bardziej obciążony.

Rozwiązanie: caching na poziomie aplikacji (Redis, Memcached), full-page cache (Varnish, wbudowany cache WordPress/WooCommerce) lub CDN z edge caching.

Przeciążony serwer współdzielony

Najtańszy hosting współdzielony dzieli zasoby CPU i RAM z dziesiątkami lub setkami innych stron. W godzinach szczytu, gdy jeden klient ma wzrost ruchu, wszyscy sąsiedzi cierpią.

Rozwiązanie: VPS lub hosting zarządzany z dedykowanymi zasobami.

Brak CDN

Serwer fizycznie stoi w Amsterdamie, a użytkownik jest w Warszawie. To kilkadziesiąt milisekund narzutu. Jeśli jednak serwer jest w USA, a użytkownicy są w Polsce, samo opóźnienie sieciowe może wynosić 100-200 ms.

CDN (np. Cloudflare, Fastly, CloudFront) umieszcza kopie zasobów bliżej użytkownika i dramatycznie skraca TTFB dla rozproszonych geograficznie odbiorców.

Wolny DNS

Domyślny DNS u rejestratora domeny bywa powolny. Zamiana na Cloudflare DNS (1.1.1.1) lub Google DNS (8.8.8.8) może skrócić czas DNS lookup z 100 ms do 10 ms.

Jak przetestować wpływ CDN?

Porównaj TTFB przed i po włączeniu CDN za pomocą narzędzi takich jak WebPageTest z różnych lokalizacji. WebPageTest umożliwia uruchomienie testu z Warszawy, Londynu, Nowego Jorku i Tokio jednocześnie i porównanie wyników.

Dobry CDN powinien skrócić TTFB o 40-70% dla użytkowników spoza fizycznej lokalizacji serwera.