Co składa się na TTFB
- Przekierowania (np. HTTP → HTTPS, domena bez www → z www).
- Rozwiązanie nazwy DNS i nawiązanie połączenia TCP + TLS.
- Czas generowania odpowiedzi przez serwer (baza danych, rendering, API).
- Odległość sieciowa między użytkownikiem a serwerem.
Jak skrócić TTFB
Najczęstsze usprawnienia to cache pełnych odpowiedzi HTML (CDN, reverse proxy), wcześniejsze generowanie stron (SSG/ISR zamiast renderowania na żądanie), optymalizacja zapytań do bazy, HTTP/2 lub HTTP/3 oraz serwowanie treści z lokalizacji bliskich użytkownikom. Cache HTML stosuj tylko po ustaleniu zasad personalizacji i unieważniania.
Przykład
Uproszczony scenariusz bez redirectów i kolejkowania: 12 + 48 + 620 = 680 ms do pierwszego bajtu; pobieranie treści jest później. Waiting obejmuje sieć i pracę serwera. Nagłówek cache poniżej dotyczy wyłącznie publicznej, niespersonalizowanej odpowiedzi; nie kopiuj go do kont, płatności ani odpowiedzi z danymi użytkownika.
DNS lookup: 12 ms
TCP + TLS: 48 ms
Waiting (TTFB): 620 ms ← sieć + praca serwera
Content download: 35 ms
─────────────────────────
Razem do 1. bajtu: 680 msCache-Control: public, max-age=60, s-maxage=3600, stale-while-revalidate=86400Dla nawigacji TTFB liczy się od początku nawigacji do początku odpowiedzi, np. responseStart − startTime w Navigation Timing. Może obejmować przekierowania, DNS, zestawienie połączenia, opóźnienie sieci i pracę serwera. Faza Waiting (TTFB) w DevTools zaczyna się później i nie jest tym samym zakresem.
Orientacyjnie dobry TTFB to maksymalnie 800 ms. To próg pomocniczy, a nie gwarancja dobrego LCP, bo wynik zależy także od renderowania, zasobów i warunków sieciowych.
Zacznij od cache HTML na CDN, ograniczenia przekierowań, optymalizacji zapytań serwera i generowania stron z wyprzedzeniem. Zmierz osobno DNS, połączenie i czas oczekiwania na odpowiedź.
Źródła i dalsza lektura
- web.dev: Time to First Byte (TTFB) dokumentacja
- MDN: Time to First Byte dokumentacja
- web.dev: Optymalizacja TTFB dokumentacja