Time to First Byte (TTFB) to czas, który upływa od momentu wysłania przez przeglądarkę żądania do serwera do chwili, gdy przeglądarka otrzymuje pierwszy bajt odpowiedzi. Innymi słowy – jak długo serwer „myśli”, zanim zacznie cokolwiek odsyłać.
TTFB mierzy się w milisekundach i jest jednym z pierwszych wskaźników, które warto sprawdzić przy diagnozowaniu problemów z wydajnością strony. Zanim przeglądarka zdąży cokolwiek wyświetlić użytkownikowi, musi najpierw dostać odpowiedź od serwera – i właśnie to czekanie mierzy TTFB.
Co składa się na TTFB?
TTFB to nie jeden proces, ale suma kilku etapów, które dzieją się zanim serwer wyśle pierwszą porcję danych.
DNS lookup – przeglądarka musi zamienić nazwę domeny (np. webiti.pl) na adres IP serwera. Jeśli rekord DNS nie jest w pamięci podręcznej, ten etap może zająć kilkadziesiąt milisekund.
Nawiązanie połączenia TCP – przeglądarka i serwer muszą się „przywitać” i nawiązać połączenie. W przypadku HTTPS dochodzi do tego jeszcze negocjacja TLS, która dodaje kolejne rundy wymiany danych.
Czas odpowiedzi serwera (TTFB właściwy) – serwer odbiera żądanie, przetwarza je i zaczyna odsyłać odpowiedź. To tutaj dzieje się najważniejsza część: zapytania do bazy danych, generowanie HTML przez CMS, wykonywanie logiki aplikacji, pobieranie danych z zewnętrznych API.
W praktyce, gdy mówimy o optymalizacji TTFB, najczęściej mamy na myśli właśnie ten ostatni etap – czas przetwarzania po stronie serwera.
Jaki TTFB jest dobry?
Google w dokumentacji Core Web Vitals rekomenduje, żeby TTFB wynosił poniżej 800 milisekund. To jednak wartość, przy której strona „zalicza” próg akceptowalności – w praktyce warto dążyć do jak najniższych wartości.
Orientacyjne progi:
Poniżej 200 ms – bardzo dobry wynik, serwer odpowiada błyskawicznie.
200–500 ms – dobry wynik, akceptowalny dla większości zastosowań.
500–800 ms – przeciętny, warto sprawdzić, co można poprawić.
Powyżej 800 ms – wynik wymagający optymalizacji, może negatywnie wpływać na Core Web Vitals i odczuwalną szybkość strony.
Warto pamiętać, że TTFB zależy też od lokalizacji użytkownika względem serwera – stąd znaczenie CDN przy serwisach obsługujących ruch z różnych regionów.
TTFB a Core Web Vitals i SEO
TTFB nie jest samodzielnym sygnałem rankingowym Google, ale ma bezpośredni wpływ na metryki, które już nim są.
LCP (Largest Contentful Paint) – wysoki TTFB opóźnia cały proces ładowania strony. Jeśli serwer długo zwleka z pierwszą odpowiedzią, przeglądarka nie może zacząć pobierać zasobów, renderować HTML ani wyświetlać treści. Poprawa TTFB to często najprostszy sposób na poprawę LCP.
Ogólne wrażenie szybkości – użytkownicy na wolno ładujących się stronach są bardziej skłonni do opuszczenia jej przed załadowaniem. Wysoki bounce rate przy długim TTFB to sygnał, który Google może interpretować jako wskaźnik niskiej jakości strony.
Crawl budget – wolno odpowiadające serwery spowalniają też crawlowanie przez Googlebot. Robot Google odwiedza mniej stron w jednostce czasu, co może prowadzić do rzadszego indeksowania aktualizacji treści.
Co powoduje wysoki TTFB?
Przyczyn może być wiele i często nakładają się na siebie.
Wolny hosting lub przepełniony serwer – najtańsze plany hostingowe współdzielone często cierpią na ograniczone zasoby. Gdy serwer obsługuje zbyt wiele stron jednocześnie, czas odpowiedzi rośnie.
Brak cachowania – strony oparte na CMS (WordPress, Drupal, Joomla) generują HTML dynamicznie przy każdym żądaniu – odpytują bazę danych, wykonują kod PHP, składają szablon. Bez cachowania każde wejście użytkownika to pełny cykl generowania strony od zera.
Nieoptymalne zapytania do bazy danych – źle napisane zapytania SQL, brak indeksów w bazie, zbyt wiele zapytań przy jednym żądaniu – to częste źródło wysokiego TTFB w bardziej rozbudowanych serwisach.
Duża odległość między użytkownikiem a serwerem – fizyczna odległość ma znaczenie. Serwer w USA obsługujący polskich użytkowników będzie miał wyższe TTFB niż serwer w Warszawie.
Zewnętrzne API i zależności – jeśli strona przy każdym żądaniu odpytuje zewnętrzne serwisy (np. systemy płatności, CRM, zewnętrzne bazy danych), a te odpowiadają wolno, TTFB rośnie.
Zbyt duże zasoby PHP lub Node.js – nieoptymalna aplikacja, zbyt wiele operacji synchronicznych, wycieki pamięci – problemy po stronie kodu aplikacji bezpośrednio przekładają się na czas przetwarzania.
Jak poprawić TTFB?
Wdrożenie cachowania – to zazwyczaj największy zysk przy najmniejszym nakładzie pracy. Cache na poziomie serwera (np. Nginx FastCGI cache), cache aplikacyjny (np. Redis, Memcached) lub cache na poziomie wtyczki w CMS (WP Rocket, W3 Total Cache) sprawiają, że serwer serwuje gotowy HTML zamiast generować go od nowa przy każdym żądaniu.
CDN (Content Delivery Network) – sieć serwerów rozmieszczonych geograficznie blisko użytkowników. CDN nie tylko przyspiesza dostarczanie zasobów statycznych, ale nowoczesne rozwiązania (Cloudflare, Fastly, Vercel Edge) potrafią cache’ować całe strony na brzegu sieci, dramatycznie redukując TTFB dla użytkowników z różnych lokalizacji.
Lepszy hosting lub serwer dedykowany – migracja z hostingu współdzielonego na VPS lub serwer dedykowany z większymi zasobami często daje natychmiastową poprawę TTFB.
Optymalizacja bazy danych – przegląd i optymalizacja zapytań SQL, dodanie brakujących indeksów, regularne czyszczenie bazy danych z nieużywanych danych.
HTTP/2 lub HTTP/3 – nowsze wersje protokołu HTTP znacząco redukują narzut związany z nawiązywaniem połączeń i przesyłaniem wielu zasobów jednocześnie.
Serwer bliżej użytkowników – wybór centrum danych w Polsce lub Europie Środkowej dla serwisów skierowanych do polskich użytkowników to prosty sposób na redukcję opóźnień sieciowych.
Jak mierzyć TTFB?
Google Search Console – raport Core Web Vitals pokazuje dane TTFB zebrane z rzeczywistych wizyt użytkowników (dane z Chrome User Experience Report).
PageSpeed Insights – analizuje konkretny URL i pokazuje TTFB zarówno w danych laboratoryjnych, jak i rzeczywistych.
WebPageTest (webpagetest.org) – jedno z najbardziej szczegółowych narzędzi do analizy wydajności. Pozwala testować z różnych lokalizacji na świecie i szczegółowo rozkłada czas ładowania na poszczególne etapy.
Chrome DevTools – zakładka Network w narzędziach deweloperskich przeglądarki pokazuje TTFB dla każdego żądania w czasie rzeczywistym.
Lighthouse – narzędzie Google dostępne w Chrome DevTools i jako osobna aplikacja, mierzące wydajność strony w kontrolowanych warunkach laboratoryjnych.
