Kliknęli Państwo w link, a przeglądarka myśli. Nie ładuje strony, nie pokazuje wskaźnika, tylko biały ekran i oczekiwanie. To nie prędkość internetu ani nie powolny JavaScript. To TTFB: czas, w którym serwer odpowiada na pierwsze żądanie.

TTFB decyduje o tym, kiedy użytkownik w ogóle zobaczy cokolwiek na ekranie. Przy wolnym TTFB odwiedzający odchodzi już na etapie, gdy Pana/Pani strona nawet nie zaczęła się wyświetlać. A Google od 2025 roku włącza responsywność serwera do sygnałów rankingowych Core Web Vitals.

Poniżej o tym, czym naprawdę jest TTFB, z jakich czterech komponentów się składa i jak doprowadzić go do poziomu, w którym strona oddaje pierwszy bajt szybciej, niż użytkownik mrugnie.

💡 Szybki przegląd:

• Proszę zrozumieć, czym jest TTFB i dlaczego każda sekunda tego opóźnienia mnoży się przez każde działanie odwiedzającego.
• Proszę przejść przez łańcuch czterech czynników: DNS, serwer, wtyczki WordPress i cache'owanie HTML.
• Proszę porównać cztery scenariusze na rzeczywistych pomiarach Pingdom, od 150 ms do katastrofalnych 4,2 sekundy.
• Proszę włączyć cache'owanie HTML, a zobaczą Państwo, jak jedna wtyczka obniża TTFB wielokrotnie bez zmiany hostingu.

Czym jest TTFB i dlaczego wpływa na wszystko

Formalna definicja z Wikipedii: TTFB to czas od wysłania żądania HTTP do otrzymania pierwszego bajta odpowiedzi przez przeglądarkę klienta. Obejmuje on opóźnienie połączenia socket, czas przesłania żądania i czas przetwarzania na serwerze.

Mówiąc prościej: TTFB to pauza między „przejściem do linku" a momentem, gdy „na stronie coś zaczęło się dziać". W terminologii gier: latency, ping, opóźnienie do pierwszej odpowiedzi. Użytkownik nie widzi ani nagłówka, ani menu, ani spinnera, tylko pustą kartę. A im dłuższa ta pauza, tym większa szansa, że kartę zamknie.

Ważny niuans: TTFB wpływa nie tylko na pierwsze ładowanie. Każde wewnętrzne przejście, każde kliknięcie linku w menu, każde kliknięcie obrazka wewnątrz wpisu, wszystko to jest osobnym żądaniem HTTP z własnym TTFB. Słaby wskaźnik mnoży się przez każde działanie czytelnika.

Cztery czynniki, z których składa się TTFB

TTFB to nie jedna metryka, lecz suma opóźnień na każdym etapie łańcucha „użytkownik → strona". Wszystkie cztery ogniwa działają sekwencyjnie: jeśli jedno zwalnia, zwalnia też wynik końcowy. Proszę przeanalizować każde z nich.

DNS: pierwsza linia

Przeglądarka nie wie, gdzie fizycznie znajduje się Pana/Pani serwer, dopóki DNS nie przekształci domeny na adres IP. Dobre serwery DNS z rozproszoną siecią węzłów robią to w milisekundy, złe dodają dziesiątki i setki milisekund do każdego ładowania.

Praktyczne minimum: korzystanie z Cloudflare lub analogicznej usługi z globalnym cache'owaniem DNS. Po pierwszym żądaniu adres pozostaje w cache'u i dla kolejnych wywołań opóźnienie DNS znika całkowicie.

Serwer i PHP: co dzieje się na hostingu

Każde żądanie do niezacache'owanej strony WordPress uruchamia interpreter PHP. Serwer ładuje rdzeń, motyw i aktywne wtyczki, wykonuje ich kod i dopiero wtedy oddaje HTML. Współczesne wersje PHP przetwarzają ten cykl wielokrotnie szybciej niż wydania sprzed dziesięciu lat, nie mówiąc już o całkowicie przestarzałych gałęziach.

Dwa parametry hostingu decydują o szybkości: wersja PHP i czas procesora przydzielony do Pana/Pani taryfy. Tani hosting współdzielony z dziesiątkami stron na jednym serwerze i przestarzałym PHP to gwarantowana droga do TTFB > 1 sekundy. Specjalistyczny hosting WordPress z PHP 8.2+ i wbudowanym cache'owaniem na poziomie serwera daje zasadniczo inne liczby.

Wtyczki i motyw WordPress

WordPress składa stronę z dziesiątek plików PHP, a każda aktywna wtyczka dodaje swój kod do tego procesu. Dziesięć dobrej jakości wtyczek od znanych deweloperów może prawie nie wpływać na TTFB. Jedna źle napisana wtyczka, która przy każdym żądaniu wykonuje trzy zbędne zapytania do bazy danych, jest w stanie zrujnować szybkość całej strony.

Oto przykład rozsądnego zestawu wtyczek, wszystko, co niezbędne, nic zbędnego:

A to już potencjalnie problematyczna konfiguracja. Kilkadziesiąt aktywnych wtyczek i serwer musi przetwarzać każdą z nich podczas generowania strony:

W praktyce ponad 30 aktywnych wtyczek niemal gwarantuje wysoki TTFB, nawet na dobrym hostingu. Zasada jest prosta: każda wtyczka ma realizować konkretne zadanie, którego nie da się rozwiązać inaczej. Wszystko, co wisi „na wszelki wypadek", podlega usunięciu.

Cache'owanie HTML: główna dźwignia

Najpotężniejszy czynnik ze wszystkich. Wtyczka buforująca, taka jak wtyczka Cache Enabler, zapisuje gotowe kopie HTML stron na dysku serwera. Gdy nadchodzi żądanie, serwer WWW zwraca statyczny plik, omijając cały stos PHP i WordPressa.

Rezultat: serwer nie musi już ładować rdzenia, motywu i wtyczek dla każdego odwiedzającego. Tylko sam serwer WWW (nginx lub Apache) obsługuje treść bezpośrednio. Właśnie dlatego buforowanie daje największe obniżenie TTFB, w razy, a nie o procenty. Szerzej o tym, dlaczego nginx jest wydajniejszy od Apache'a w tym zadaniu, pisaliśmy w osobnym artykule.

TTFB w praktyce: cztery scenariusze

Przejdźmy do rzeczywistych pomiarów. Poniżej przedstawiono wyniki testów na różnych kombinacjach witryny i serwera, uzyskane za pomocą Pingdom Tools. Każdy scenariusz pokazuje TTFB dla wersji niebuforowanej i buforowanej.

Wolna witryna na wolnym serwerze

Najgorsza z możliwych kombinacji: witryna z dziesiątkami wtyczek i bez buforowania na starym hostingu współdzielonym z PHP 5.4.

Jeśli przyjrzymy się szczegółom pierwszego żądania, widać, że serwer myśli całą wieczność:

TTFB wynosi 4,2 sekundy. Cztery sekundy użytkownik patrzy na pusty ekran, zanim przeglądarka otrzyma jakiekolwiek dane. Proszę dodać do tego czas renderowania strony, a całkowite oczekiwanie na gotowość witryny z łatwością sięga siedmiu sekund. Cloudflare na wejściu już tu nie pomaga: problem jest głębszy, na poziomie hostingu i kodu witryny.

Szybka witryna na średnim serwerze

Zmieniamy warunki: witryna z minimum wtyczek, serwer na Apache ze standardową wersją PHP, bez buforowania.

Wynik, 521 ms. Już 8 razy lepiej niż w pierwszym scenariuszu. Pół sekundy do pierwszego bajta, akceptowalnie dla większości witryn. Teraz włączamy buforowanie:

TTFB spada do 152 ms. Nawet średni hosting z poprawnie skonfigurowanym buforowaniem daje doskonały rezultat.

Wolna witryna na szybkim serwerze

Sytuacja odwrotna: zoptymalizowany serwer na Plesku z nginx i standardową wersją PHP, ale witryna rozdęta wtyczkami.

Bez bufora szybki serwer i tak poświęca 1,29 sekundy na przetworzenie ciężkiej witryny. Dobry hosting łagodzi, ale nie rozwiązuje problemu źle zoptymalizowanego WordPressa.

Włączamy buforowanie, TTFB obniża się do 400 ms. Różnica ponad trzykrotna.

Szybka witryna na szybkim serwerze

Scenariusz optymalny: lekka witryna na dobrym hostingu.

Bez bufora serwer zwraca pierwszy bajt w mniej niż 500 ms. Dodajemy buforowanie:

Wynik, poniżej 150 ms. Praktycznie natychmiastowa odpowiedź.

Zestawienie wyników

Wszystkie cztery scenariusze na jednym wykresie:

Wniosek z tych pomiarów jest prosty: hosting ma znaczenie, ale to, co robią Państwo z samą witryną, wpływa na TTFB silniej. Szybki serwer z cache’owaniem wyciąga nawet problematyczną stronę do akceptowalnych 400 ms, a wolny serwer bez cache’u topi nawet lekki WordPress.

Jak poprawić TTFB: plan krok po kroku

Optymalizacja przebiega od prostych do złożonych działań, od tego, co robi się w pięć minut i daje maksymalny efekt, do bardziej subtelnych ustawień.

Krok 1: proszę włączyć cache'owanie HTML. Proszę zainstalować darmowy Cache Enabler lub podobną wtyczkę do cache'owania. To jedna operacja, która wielokrotnie obniża TTFB na każdym hostingu. Bez przesady, to najwyższy zwrot z minuty wysiłku w całej optymalizacji WordPressa.

Krok 2: proszę sprawdzić wersję PHP. W panelu administracyjnym hostingu lub w cPanelu proszę znaleźć ustawienia wersji PHP. Jeśli dostępna jest aktualna wersja (8.2 lub nowsza), proszę przełączyć. Przejście z przestarzałej gałęzi na nowoczesną zauważalnie przyspiesza przetwarzanie każdego żądania. Przed przełączeniem proszę upewnić się, że motyw i wszystkie wtyczki są kompatybilne z wybraną wersją.

Krok 3: proszę przeprowadzić audyt wtyczek. Proszę wyłączyć wszystko, co nie jest używane w tej chwili. Proszę zostawić tylko te wtyczki, które rozwiązują konkretne zadanie. Resztę proszę usunąć, a nie tylko dezaktywować. Wtyczki „na wyrost" i „może się przyda" dodają kod do każdego żądania, niezależnie od tego, czy Państwo z nich korzystają, czy nie.

Krok 4: proszę wybrać szybki motyw. Motyw określa, ile kodu PHP jest wykonywane podczas każdego ładowania strony. Ciężkie motywy z wizualnymi kreatorami stron generują znacznie więcej pracy po stronie serwera niż rozwiązania minimalistyczne. Jeśli test TTFB na czystej instalacji WordPressa (bez wtyczek i ze standardowym motywem) pokazuje dobry wynik, a po włączeniu Państwa motywu wskaźnik gwałtownie się pogarsza, problem leży właśnie w motywie.

Krok 5: proszę ocenić hosting. Jeśli po pierwszych czterech krokach TTFB wciąż przekracza 500-800 ms, ograniczenie leży po stronie hostingu. Specjalistyczny hosting WordPress z nginx, PHP 8.2+ i cache'owaniem serwerowym daje zasadniczo inny poziom responsywności. Przy wyborze proszę zwrócić uwagę na obecność wbudowanego cache'owania obiektowego (Redis lub Memcached), to kolejny poziom po cache'owaniu HTML.

Wideo: TTFB od teorii do rezultatu

Proszę obejrzeć poglądową analizę TTFB z pomiarami na żywo przed i po optymalizacji:

⁉️🤔 Często zadawane pytania

Jaki TTFB uznaje się za dobry dla WordPressa?

Proszę kierować się docelowymi wartościami Google Core Web Vitals: do 800 ms, akceptowalnie, do 500 ms, dobrze, do 200 ms, doskonale. W praktyce dla strony na WordPressie z cache'owaniem osiągalny jest zakres 100-400 ms. Bez cache'owania nawet szybka strona rzadko schodzi poniżej 400-500 ms.

Czy koniecznie trzeba zmieniać hosting, aby poprawić TTFB?

Nie zawsze. Cache'owanie HTML wielokrotnie obniża TTFB nawet na przeciętnym hostingu. Zanim Państwo przeniosą stronę, proszę włączyć cache'owanie, zaktualizować PHP do aktualnej wersji i wyczyścić wtyczki. Jeśli po tym TTFB wciąż jest wyższy niż 800 ms, hosting rzeczywiście czas zmienić.

Dlaczego TTFB skacze od pomiaru do pomiaru?

Na TTFB wpływa obciążenie procesora serwera w momencie pomiaru, opóźnienia sieciowe i geografia serwera testowego. Proszę wykonać serię 5-7 pomiarów i brać medianę, a nie pierwszą lepszą wartość. Proszę testować z kilku lokalizacji: serwer w Europie może pokazywać doskonały TTFB z Frankfurtu, ale słaby z Tokio.

Czy TTFB wpływa na pozycje w Google?

Tak, począwszy od 2025 roku responsywność serwera wchodzi do Core Web Vitals jako sygnał rankingowy. Bezpośredni wpływ jest umiarkowany, ale pośredni, znaczący: wysoki TTFB zwiększa współczynnik odrzuceń, a wysoki współczynnik odrzuceń już bezpośrednio obniża pozycje.

Czy można zmierzyć TTFB za darmo?

Tak. Proszę używać Pingdom Tools, GTmetrix, PageSpeed Insights lub WebPageTest. Ważny niuans: proszę mierzyć właśnie TTFB (czas do pierwszego bajtu), a nie całkowity czas ładowania strony. W Pingdom trzeba w tym celu rozwinąć szczegóły pierwszego żądania do strony.

Co zrobić z TTFB już teraz

Główny wniosek z powyższych pomiarów: cache'owanie HTML to najpotężniejsza i najprostsza dźwignia. Jedna wtyczka wielokrotnie obniża TTFB na każdym hostingu, a zajmuje to dokładnie pięć minut.

Kolejność działań jest następująca:

• Jeśli TTFB > 1 sekundy, proszę zacząć od cache'owania i aktualizacji PHP. Te dwa kroki dają zasadniczą część możliwej poprawy.
• Jeśli TTFB między 400 a 800 ms, audyt wtyczek i motywu zwykle usuwa pozostałe opóźnienie.
• Jeśli TTFB stabilnie poniżej 200 ms, są Państwo w optymalnej strefie, proszę utrzymywać obecny poziom.

Proszę zacząć od darmowej wtyczki do cache'owania: proszę zainstalować, aktywować i wykonać pomiar przez Pingdom Tools. Różnica będzie widoczna od razu. A jaki jest Państwa TTFB teraz, proszę podzielić się liczbami w komentarzach.