Próg TTFB

Próg TTFB to parametr monitoringu stron internetowych, który mierzy czas do pierwszego bajtu odpowiedzi serwera (ang. Time to First Byte) i porównuje go z ustaloną wartością graniczną w kolejnych pomiarach. Wynik to czas w milisekundach, a przekroczenie progu w serii pomiarów wskazuje na utrwalone spowolnienie, a nie chwilowe zakłócenie. TTFB mierzy czas od rozpoczęcia nawigacji do strony do chwili, w której zaczyna docierać pierwszy bajt odpowiedzi ^[1].

Jak działa

TTFB jest sumą kilku faz żądania: czasu przekierowań, uruchomienia service workera (jeśli występuje), zapytania DNS, nawiązania połączenia i negocjacji TLS oraz samego żądania aż do nadejścia pierwszego bajtu odpowiedzi ^[1]. MDN opisuje TTFB jako czas między wysłaniem żądania przez przeglądarkę a otrzymaniem pierwszego bajtu od serwera, obejmujący zapytanie DNS, uzgadnianie TCP i, przy HTTPS, uzgadnianie TLS ^[2].

RYS. 1.1Fazy do pierwszego bajtu

Na czas po stronie serwera składa się wszystko, co dzieje się między przyjęciem żądania a wysłaniem początku odpowiedzi: wykonanie aplikacji, zapytania do bazy danych, odczyt z pamięci podręcznej. Nagłówek Server-Timing pozwala zmierzyć takie odrębne procesy zaplecza, na przykład zapytania do bazy danych ^[6]. Każde przekierowanie dokłada opóźnienie, a łańcuch przekierowań prowadzących do kolejnych przekierowań powiększa je dalej ^[6].

RYS. 1.2Składowe TTFB

TTFB poprzedza wszystkie dalsze miary ładowania strony ^[1]. Nic nie może się wydarzyć po stronie przeglądarki, zanim zaplecze dostarczy pierwszy bajt treści, dlatego skrócenie TTFB poprawia każdą kolejną miarę ładowania ^[7].

Standardy i specyfikacje

• Navigation Timing Level 2 (W3C, szkic roboczy) definiuje responseStart jako moment tuż po otrzymaniu przez przeglądarkę pierwszego bajtu odpowiedzi z serwera, pamięci podręcznej HTTP lub zasobów lokalnych ^[3]. Model przetwarzania ustawia fazy w kolejności: przekierowanie, zapytanie DNS, połączenie, zabezpieczenie połączenia, żądanie, odpowiedź ^[3].
• PerformanceResourceTiming udostępnia responseStart w API przeglądarki; różnica responseStart i requestStart mierzy czas trwania samego żądania ^[4]. Dla zasobu z innego źródła bez nagłówka Timing-Allow-Origin wartość wynosi 0 ^[4].
• Server Timing (W3C) pozwala serwerowi przekazać przeglądarce metryki cyklu żądanie–odpowiedź, np. Server-Timing: db;dur=53, app;dur=47.2 ^[5]. Dostęp do tych danych jest domyślnie ograniczony regułą tego samego źródła, a serwer decyduje, które metryki ujawnia ^[5].
• Progi web.dev. web.dev zaleca, by serwer odpowiadał na tyle szybko, żeby 75. percentyl użytkowników mieścił się w dobrym progu FCP; jako orientację podaje TTFB do 0,8 s jako dobry i powyżej 1,8 s jako słaby ^[1]. TTFB nie należy do Core Web Vitals ^[1], ale jest pierwszą z czterech składowych LCP; web.dev sugeruje, by odpowiadał za około 40% tego czasu ^[7].
• 103 Early Hints. Przy odpowiedziach tymczasowych 103 za pierwsze bajty uznaje się właśnie tę odpowiedź ^[1]. Czas do odpowiedzi końcowej mierzy finalResponseHeadersStart, tam gdzie jest obsługiwany ^[2].

Zagrożenia i skutki

Brak pamięci podręcznej stron. Wtyczki cache w WordPressie zapisują wpisy i strony jako pliki statyczne, co zmniejsza obciążenie serwera; dla stron o mało zmiennej treści poprawa może być kilkusetkrotna ^[8]. Pamięć podręczna obiektów przenosi dane z miejsca drogiego i wolnego w odczycie do taniego i szybkiego ^[8]. Bez tych mechanizmów każde żądanie wymaga pełnego wygenerowania strony.

Wtyczki, motywy i baza danych. Wydajność WordPressa zależy od liczby i jakości wtyczek oraz od użytego motywu ^[6]. Zapytania do bazy danych są jednym z procesów zaplecza, które warto mierzyć przy wysokim opóźnieniu ^[6].

WP-Cron. Zadania WP-Cron uruchamiają się przy wczytaniu strony; dokumentacja WordPressa zaleca przeniesienie ich do systemowego harmonogramu i wyłączenie stałą DISABLE_WP_CRON, bo inaczej WP-Cron nadal działa przy każdym wczytaniu strony i dokłada zużycie zasobów serwera ^[9].

Hosting. Hosting współdzielony jest zwykle wolniejszy, a aplikacja z niewystarczającą ilością pamięci zaczyna ją intensywnie wymieniać i nie obsługuje stron tak szybko, jak mogłaby ^[6]. CDN skraca dystans do użytkownika, bo zasoby są przechowywane na serwerach fizycznie bliższych odbiorcom ^[6].

Pomiar z jednej lokalizacji. Test laboratoryjny wykonuje jedno urządzenie, w jednej sieci, z jednego miejsca, zwykle przy pustej pamięci podręcznej ^[10]. Dane z pola odzwierciedlają rzeczywiste sieci i lokalizacje użytkowników, a pojedyncza liczba raportowana przez narzędzie jest punktem rozkładu, zwykle 75. percentylem ^[10]. Jeden odczyt TTFB jest więc próbką; o stanie serwera mówi dopiero seria pomiarów.

Przykłady

Obserwacja	Co widać w pomiarze	Możliwa przyczyna
TTFB do 0,8 s	wynik w przedziale dobrym [1]	strona serwowana z pamięci podręcznej [8]
TTFB powyżej 1,8 s	wynik w przedziale słabym [1]	generowanie strony bez cache, ciężkie wtyczki [6] [8]
Wysoki TTFB, krótki czas serwera w Server-Timing	opóźnienie poza aplikacją	przekierowania, DNS, połączenie, TLS [1]
Wysoki czas db w Server-Timing	dominuje baza danych [5] [6]	wolne zapytania do bazy [6]
Pojedynczy wolny odczyt, kolejne szybkie	jedna próbka z rozkładu [10]	zimna pamięć podręczna, warunki sieci [10]
Wolne odczyty w wielu kolejnych pomiarach	spowolnienie utrwalone w serii	przeciążony hosting, brak pamięci [6]
Niski TTFB przy 103 Early Hints	liczy się odpowiedź tymczasowa [1]	odpowiedź końcowa może przyjść później [2]