Czas odpowiedzi serwera (TTFB): jaki powinien być i jak go zmierzyć

Czas odpowiedzi serwera (TTFB) powinien być niższy niż 800 milisekund, a na stronie z działającym cache realnie osiągalne jest 200 do 400 milisekund. To pierwszy odcinek ładowania strony i jedyny, za który odpowiada wyłącznie hosting. Jeśli tu tracisz sekundę, każda kolejna optymalizacja startuje z tym opóźnieniem na karku. Poniżej tłumaczymy, co dokładnie mierzy ten wskaźnik, jak go sprawdzić i co robić, gdy wynik jest zły.

Co to jest TTFB

TTFB (time to first byte) to czas od wysłania żądania przez przeglądarkę do odebrania pierwszego bajtu odpowiedzi serwera. Składają się na niego cztery elementy: czas na połączenie sieciowe z serwerem, czas oczekiwania w kolejce na wolny proces, czas wykonania kodu PHP wraz z zapytaniami do bazy i czas wysłania odpowiedzi. Dopiero po tym wszystkim przeglądarka może zacząć rysować cokolwiek na ekranie.

Sam TTFB nie jest jednym z trzech Core Web Vitals, ale jest wskaźnikiem pomocniczym, który wprost wpływa na LCP, czyli na czas wyświetlenia największego elementu. Ponieważ dobry LCP to 2,5 sekundy lub mniej, a TTFB wchodzi w tę wartość w całości, sekunda zmarnowana na odpowiedzi serwera zjada prawie połowę budżetu, zanim pobierze się choćby jedno zdjęcie.

Jakie wartości są dobre

Przyjmowane w praktyce progi wyglądają tak:

• Poniżej 200 ms. Bardzo dobrze. Typowe dla strony statycznej albo dobrze zcache'owanej na szybkim serwerze blisko odbiorcy.
• 200 do 500 ms. Dobry wynik dla WordPressa z działającym cache. Do tego przedziału warto celować w firmowej stronie.
• 500 do 800 ms. Akceptowalnie, ale jest co poprawiać. Zwykle brakuje cache albo baza pracuje na wolnym dysku.
• Powyżej 800 ms. Wynik uznawany za słaby. Prawie zawsze oznacza przeciążony serwer, brak cache lub ciężkie zapytania do bazy.
• Powyżej 1,5 s. Poziom, przy którym odwiedzający zaczynają wychodzić przed zobaczeniem treści, a w sklepie widać to w porzuconych koszykach.

Ważne zastrzeżenie: mierz z lokalizacji swoich klientów. Strona serwowana z Warszawy do odbiorcy w Polsce ma z natury krótszą trasę niż ta sama strona serwowana z innego kontynentu, a różnica na samym opóźnieniu sieciowym potrafi wynieść ponad sto milisekund w każdą stronę.

Jak zmierzyć czas odpowiedzi serwera

Najprostszy sposób nie wymaga żadnego narzędzia. Otwórz stronę w oknie prywatnym, włącz narzędzia deweloperskie przeglądarki, przejdź do zakładki Sieć i odśwież. Kliknij pierwszy wiersz z dokumentem HTML i znajdź pozycję opisaną jako oczekiwanie na odpowiedź serwera. To jest Twój TTFB. Powtórz pomiar trzy razy i o różnych porach dnia, bo pojedynczy wynik nic nie mówi.

Drugi sposób to wiersz poleceń, jeśli wolisz liczby bez interfejsu. Polecenie curl -w "%{time_starttransfer}\n" -o /dev/null -s https://twojadomena.pl/ zwraca czas do pierwszego bajtu w sekundach. Trzeci sposób to PageSpeed Insights, gdzie w sekcji z danymi od realnych użytkowników znajdziesz uśredniony czas odpowiedzi serwera dla Twojej witryny, o ile ma ona wystarczający ruch.

Co najczęściej psuje TTFB

Diagnoza sprowadza się do kilku typowych przyczyn. Przeciążony serwer współdzielony ustawia Twoje żądanie w kolejce po innych stronach na tej samej maszynie, więc czas rośnie wieczorem i w szczycie. Brak cache oznacza, że przy każdym wejściu WordPress od nowa wykonuje kilkadziesiąt zapytań do bazy. Wolny dysk pod bazą danych zamienia operacje trwające milisekundy w setki milisekund, dlatego NVMe robi tu największą różnicę. Stara wersja PHP wykonuje ten sam kod dłużej niż wersja aktualna. Wreszcie zapytania do zewnętrznych API wykonywane w trakcie generowania strony uzależniają Twój czas odpowiedzi od cudzego serwera.

Jest jeszcze jeden powód, o którym łatwo zapomnieć: przeciążony serwer pocztowy albo zaplanowane zadania cron uruchamiane co minutę na tej samej maszynie. Na stronie z niewielkim ruchem to właśnie one potrafią cyklicznie podbijać czas odpowiedzi, co w pomiarach wygląda na przypadkowe skoki.

Jak poprawić czas odpowiedzi

Kolejność działań od najtańszych do najdroższych wygląda tak. Najpierw upewnij się, że cache faktycznie działa (dwa odświeżenia w oknie prywatnym, drugie powinno być wyraźnie szybsze). Potem podnieś PHP do wspieranej wersji, po kopii zapasowej i teście. Następnie posprzątaj bazę: dane ładowane automatycznie z tabeli wp_options, stare rewizje wpisów i pozostałości po odinstalowanych wtyczkach. Dopiero gdy to nie wystarczy, problemem jest sam serwer i wtedy zmiana hostingu bez przestoju jest jedynym realnym ruchem. Warto wtedy od razu wybrać środowisko przygotowane pod szybki hosting WordPress, bo przenosiny na kolejny przeciążony serwer współdzielony niczego nie zmienią.

Ma to znaczenie także dla budżetu marketingowego. Jeśli płacisz za ruch, opóźnienie serwera dotyka każdego kliknięcia, za które zapłaciłeś, a nie tylko wyników organicznych. Firmy, które prowadzą stałe kampanie i publikacje w kanałach marketingowych, tracą tu realne pieniądze każdego dnia, bo część kupionego ruchu wychodzi przed zobaczeniem oferty.

Czego TTFB nie powie

Dobry czas odpowiedzi nie gwarantuje szybkiej strony. Można mieć 180 milisekund do pierwszego bajtu i cztery sekundy do wyświetlenia treści, jeśli szablon ładuje osiem czcionek, trzy biblioteki JavaScript i nieskompresowane zdjęcie w nagłówku. TTFB mówi wyłącznie o kondycji serwera, a nie o jakości frontendu. Dlatego pomiar zaczyna się od niego, ale się na nim nie kończy: po uporządkowaniu serwera przechodzi się do obrazów, czcionek i skryptów.

Jeśli chcesz porównać swój wynik z tym, co daje serwer stojący blisko polskich odbiorców, zajrzyj na stronę szybkiego hostingu WordPress, a przy diagnozie przyczyn pomoże artykuł o tym, dlaczego strona WordPress ładuje się wolno. Jeśli rozważasz przeprowadzkę, warto wiedzieć, że przy zachowaniu adresów jest ona dla wyszukiwarki neutralna, co opisujemy we wpisie o tym, czy zmiana hostingu wpływa na pozycje w Google.