TTFB – co to jest i jak zmniejszyć Time To First Byte? 10 sposobów

TTFB (Time To First Byte) to czas od rozpoczęcia przejścia na stronę do otrzymania przez przeglądarkę pierwszego bajtu odpowiedzi serwera. Według Google dobry wynik to maksymalnie 0,8 s, a powyżej 1,8 s TTFB uznaje się za słaby. Najszybciej obniżysz go cache stron, CDN-em, aktualnym PHP i odchudzeniem WordPressa – a jeśli to nie wystarcza, problemem jest zwykle hosting.

Na czas wczytywania strony internetowej wpływa wiele rzeczy. Może chodzić o zbyt dużą liczbę skryptów JavaScript, które blokują renderowanie strony, może chodzić o zbyt duże zdjęcia. Coraz częściej zwraca się uwagę na wartości Podstawowych Wskaźników Internetowych (Core Web Vitals). Jedną z najrzadziej branych pod uwagę przy optymalizacji strony kwestii są działania mające na celu poprawę TTFB, czyli czasu potrzebnego na otrzymanie pierwszego bajta danych. Zapraszam do przeczytania poradnika przygotowanego przez Mateusza Mazurka z jakwybrachosting.pl, który w październiku 2026 r. zaktualizowałem o aktualne progi, sposoby pomiaru i przykład z mojej strony.

---

Długi czas reakcji serwera często sprawia, że strona internetowa ładuje się powoli lub z opóźnieniami. Kwestia TTFB – czyli czasu potrzebnego na rozpoczęcie ładowania strony – jest związana przede wszystkim z parametrami hostingu i tym, ile pracy serwer musi wykonać, zanim odpowie. Zobacz, na co zwrócić uwagę, aby móc liczyć na niskie TTFB.

Co to jest TTFB?

TTFB (czyli Time To First Byte) to parametr określający czas reakcji serwera. Odnosi się on do czasu pomiędzy kliknięciem w link (rozpoczęciem nawigacji) a pierwszą reakcją ze strony serwera – a dokładniej otrzymaniem pierwszego bajtu odpowiedzi.

Według definicji z web.dev na TTFB składa się kilka etapów: czas przekierowań (jeśli występują), uruchomienie service workera (jeśli strona go używa), zapytanie DNS, nawiązanie połączenia i negocjacja TLS, a na końcu wysłanie żądania i oczekiwanie, aż serwer wygeneruje odpowiedź i zacznie ją wysyłać.

Warto pamiętać, że TTFB to czynnik, na który ogromny wpływ mają parametry serwera i oprogramowanie strony. Ale które dokładnie? I jak w praktyce możesz zmniejszyć TTFB?

Jakie TTFB jest dobre?

Google (web.dev) podaje następujące progi dla TTFB, mierzone dla 75. percentyla wizyt:

Ocena	TTFB
Dobry	≤ 0,8 s
Wymaga poprawy	0,8–1,8 s
Słaby	> 1,8 s

Google zaznacza, że są to wartości orientacyjne – strona renderowana po stronie serwera (np. klasyczny WordPress) może mieć nieco wyższy TTFB i nadal szybko pokazywać treść, bo w pierwszej odpowiedzi dostaje gotowy HTML.

TTFB a Core Web Vitals

TTFB nie jest jednym z Core Web Vitals. Obecnie są nimi LCP (Largest Contentful Paint), INP (Interaction to Next Paint – od 12 marca 2024 r. zastąpił FID) oraz CLS (Cumulative Layout Shift). TTFB poprzedza jednak wszystkie metryki ładowania: każda milisekunda oczekiwania na serwer dolicza się do FCP i LCP. Jeśli serwer odpowiada po 2 sekundach, zmieszczenie się w dobrym progu LCP (2,5 s) staje się bardzo trudne. Dlatego wysoki TTFB to często pierwsza rzecz do sprawdzenia, gdy LCP jest słabe.

Jak zmierzyć TTFB?

Najlepiej mierzyć TTFB na kilka sposobów, bo każdy pokazuje coś innego:

curl – szybki test z terminala: curl -o /dev/null -s -w '%{time_starttransfer}\n' https://twojadomena.pl/. Wynik (w sekundach) to czas do pierwszego bajta odpowiedzi. Warto powtórzyć pomiar kilka razy, bo pierwszy może trafić na pusty cache.

Chrome DevTools – zakładka Network, kliknij dokument HTML i przejdź do Timing. Pozycja „Waiting for server response” pokazuje czas oczekiwania na serwer.

PageSpeed Insights / CrUX – w danych od rzeczywistych użytkowników (Chrome User Experience Report) PageSpeed Insights pokazuje TTFB obok Core Web Vitals. To najlepsze źródło, jeśli strona ma wystarczający ruch. Lighthouse (dane laboratoryjne) również ostrzega przed zbyt długim czasem odpowiedzi serwera.

Nagłówek Server-Timing – serwer może dołączyć do odpowiedzi np. Server-Timing: db;dur=120, app;dur=340, a DevTools pokaże te czasy w zakładce Timing. Dzięki temu widzisz, czy czas „zjada” baza danych, czy generowanie strony.

Mierz zarówno strony z cache, jak i bez niego (np. jako zalogowany użytkownik albo z parametrem omijającym cache) – dopiero wtedy widać, jak szybki jest sam serwer.

#1 Włącz cache stron

Cache to temat na tyle istotny, że od niego zaczyna się ta lista. Jeśli strona za każdym razem jest generowana od zera, nawet szybki hosting nie da bardzo niskiego TTFB.

Cache to pamięć podręczna, w której zapisywana jest „statyczna” wersja strony WWW, aby wykorzystać ją ponownie przy kolejnych odwiedzinach. Dzięki temu serwer nie musi przy każdych odwiedzinach od nowa pytać bazy danych o wszystkie informacje, wykonywać skryptów i „generować” strony w locie, co znacznie wydłuża TTFB. Jeśli dana strona się nie zmienia, można wygenerować jej statyczną kopię i to właśnie ją serwować kolejnym odwiedzającym. Google w poradniku optymalizacji TTFB zwraca uwagę, że nawet krótki czas cache’owania daje zauważalny efekt na często odwiedzanych stronach.

W przypadku WordPressa sprawa cache jest prosta, bo wystarczy skorzystać z jednej z wielu wtyczek, które tworzą i przechowują kopię każdej podstrony. Popularne są m.in. LiteSpeed Cache (na serwerach LiteSpeed), W3 Total Cache, WP Fastest Cache czy WP Super Cache. Jeszcze szybszy bywa cache na poziomie serwera (np. nginx, Varnish) lub CDN – wtedy żądanie w ogóle nie dociera do PHP.

#2 Wybierz serwer blisko odbiorców lub użyj CDN

Warto mieć świadomość, że umiejscowienie serwera ma wpływ na czas reakcji. Kluczowa jest odległość pomiędzy przeglądarką użytkownika a serwerem, na którym umieszczona jest strona – zanim padnie pierwsze żądanie, trzeba wymienić kilka komunikatów (DNS, połączenie, TLS), a każdy z nich „podróżuje” tam i z powrotem. Gdy serwer jest w tym samym kraju, opóźnienie sieci to zwykle kilka–kilkanaście milisekund na każdą taką wymianę; przy serwerze na innym kontynencie może to być już ponad sto milisekund.

Zatem lokalizacja serwera niedostosowana do grupy docelowej może być przyczyną wydłużonego TTFB. Jeżeli chcesz ograniczyć opóźnienia w tej kwestii, warto zadbać o to, aby strona przeznaczona dla polskich odbiorców była umieszczona na serwerze zlokalizowanym w Polsce (lub chociaż w Europie).

A jeżeli odbiorcy Twojej strony pochodzą z całego świata – w takiej sytuacji zdecyduj się na CDN, czyli Content Delivery Network. Taki system serwerów rozproszonych po całym świecie ma za zadanie zminimalizowanie opóźnień w ładowaniu strony internetowej użytkownikom bez względu na ich lokalizację. CDN zwykle zapewnia też szybki DNS, nowoczesne wersje TLS i HTTP oraz – jeśli go skonfigurujesz – cache całych stron HTML na brzegu sieci. Jednym z rozwiązań może być częściowo darmowy Cloudflare.

#3 Korzystaj z aktualnej wersji PHP i OPcache

Gdy mowa o PHP, istotna jest wersja interpretera zainstalowanego na serwerze. Aby TTFB był jak najmniejszy, powinna to być aktualna, wspierana odsłona języka.

Dlaczego? Otóż kolejne wersje przynoszą poprawki nie tylko w zakresie bezpieczeństwa, ale także wydajności. Benchmarki poszczególnych odsłon pokazują, że serwery z nowszym PHP po prostu reagują szybciej.

To porównanie (z 2021 r.) pokazuje, jak nowe wersje PHP zwiększały wydajność na serwerze. (openbenchmarking.org)

Pamiętaj, że każda wersja PHP ma swój „cykl życia”. Obecnie każda gałąź ma 2 lata aktywnego wsparcia, a potem jeszcze 2 lata wyłącznie poprawek bezpieczeństwa. W październiku 2026 r. aktywnie wspierane są PHP 8.4 i 8.5, a WordPress zaleca PHP w wersji 8.3 lub nowszej.

Upewnij się też, że na serwerze działa OPcache – moduł, który przechowuje skompilowany kod PHP w pamięci, więc skrypty nie są kompilowane przy każdym żądaniu. Na większości hostingów jest włączony domyślnie, ale warto to sprawdzić w panelu lub w „Zdrowiu witryny” WordPressa.

WordPress w najnowszej wersji wspiera aktualne wersje PHP, jednak problem może pojawić się z niektórymi wtyczkami czy starszymi motywami, które nie są już rozwijane. W takim wypadku warto skorzystać z najnowszej wersji PHP, pod którą wszystkie motywy i wtyczki nadal działają prawidłowo. W dłuższej perspektywie warto jednak zmienić wtyczki czy motyw, aby nadążały za aktualizacjami.

#4 Zadbaj o bazę danych i autoload w WordPressie

Przy każdym wywołaniu strony WordPress wczytuje z tabeli wp_options wszystkie opcje oznaczone jako autoload. Wtyczki często zostawiają tam dane także po odinstalowaniu, więc z czasem ta porcja rośnie i spowalnia każde żądanie, które nie trafia w cache. Od WordPressa 6.6 narzędzie „Zdrowie witryny” zgłasza krytyczny problem, gdy autoładowane opcje przekraczają 800 KB. Warto też regularnie usuwać rewizje, wygasłe transienty i spam w komentarzach oraz sprawdzić wolne zapytania np. wtyczką Query Monitor.

Pomocne są także silniki pamięci podręcznej obiektów – Redis oraz Memcached. Dzięki nim interpreter PHP nie musi każdorazowo wysyłać zapytania do bazy MySQL i oczekiwać na zwrócenie wyniku – może korzystać z danych, które ma „pod ręką”, w pamięci szybkiego dostępu. Odciążony serwer reaguje szybciej, szczególnie na stronach, których nie da się w całości cache’ować (sklepy, panele klienta).

Aby skorzystać z Redisa lub Memcached, nie wystarczy jednak sam serwer, który obsługuje którąś z tych technologii. Trzeba także odpowiednio dostosować stronę WWW. W przypadku WordPressa wystarczy do tego celu wtyczka taka jak np. Redis Object Cache. Opcję włączenia Redisa znajdziesz także w niektórych wtyczkach do cache czy optymalizacji WordPressa.

#5 Wyłącz zbędne wtyczki i dodatki

Według danych W3Techs (październik 2026) WordPress napędza ok. 40% wszystkich stron WWW i ok. 59% stron, których CMS da się rozpoznać. A jedną z największych zalet WordPressa jest ogromna liczba darmowych dodatków i wtyczek, które pozwalają rozbudować stronę WWW i dodać do niej nowe funkcje.

Niestety, każda wtyczka czy dodatek to dodatkowy kod, który serwer musi przetworzyć, zanim wyśle stronę do przeglądarki użytkownika. A to zajmuje czas.

Walcząc o niższy TTFB, zrób uczciwy przegląd używanych wtyczek i wyłącz oraz usuń te, które nie są absolutnie niezbędne do działania strony WWW. Efekty zauważysz często gołym okiem – zwłaszcza na podstronach, które nie trafiają w cache.

#6 Używaj HTTP/2 i HTTP/3

Trzeba pamiętać nie tylko o aktualizacji PHP, ale także o korzystaniu z nowych wersji protokołu HTTP. Od niego zależy m.in. szybkość nawiązania połączenia.

HTTP/2 to dziś absolutna podstawa dla nowoczesnej strony internetowej – wersję HTTP/1.1 śmiało można uznać za przestarzałą. Jednak, jeżeli zależy Ci na zminimalizowaniu TTFB, warto korzystać także z HTTP/3 – opartego na protokole QUIC, który skraca nawiązywanie połączenia i lepiej radzi sobie z utratą pakietów. Razem z TLS 1.3 oznacza to mniej wymian komunikatów przed wysłaniem pierwszego żądania.

Najważniejsze przeglądarki obsługują już HTTP/3, więc musisz tylko zadbać o to, aby Twój hosting lub CDN obsługiwał ten protokół.

#7 Wykorzystaj 103 Early Hints

103 Early Hints to wstępna odpowiedź HTTP, którą serwer (lub CDN) wysyła, zanim skończy generować właściwą stronę. Zawiera wskazówki typu preconnect i preload dla kluczowych zasobów – np. arkusza CSS czy fontu. Przeglądarka wykorzystuje czas „myślenia” serwera, żeby zacząć je pobierać.

Uczciwie trzeba dodać, że Early Hints nie przyspiesza samego generowania strony – pomaga za to szybciej wyświetlić treść (FCP, LCP), gdy TTFB jest wysoki. Preconnect obsługują Chrome, Edge, Firefox i Safari, preload – Chrome, Edge i Firefox. Najprościej włączyć tę funkcję w CDN (np. Cloudflare ma ją w ustawieniach).

#8 Ogranicz przekierowania

Czas przekierowań wlicza się do TTFB, a każde przekierowanie to kolejne żądanie, czasem do innej domeny (nowe DNS, połączenie i TLS). Linkuj wewnętrznie bezpośrednio do docelowych adresów, unikaj łańcuchów (http → https → www → adres z ukośnikiem) i włącz HSTS, żeby przeglądarka od razu łączyła się przez HTTPS bez przekierowania z HTTP.

#9 Wybierz wydajny hosting: CPU, RAM, dysk i limity PHP

Google w poradniku o TTFB pisze wprost, że hosting to pierwsza rzecz, którą trzeba rozważyć. Podobnie jak w przypadku komputera, także wybierając serwer, trzeba przyjrzeć się jego najważniejszym parametrom – procesorowi oraz pamięci operacyjnej. Niestety rzadko który dostawca usług hostingowych przedstawia, na jakiej maszynie postawiony jest serwer.

Nie oznacza to, że masz związane ręce. Możesz wybrać serwer, który zapewnia Ci minimalny przydział mocy obliczeniowej i pamięci operacyjnej. Oznacza to, że nawet w momencie zwiększonego obciążenia serwera, możesz liczyć na określone zasoby. Aby zadbać o niski TTFB, wybierz hosting, na którym możesz liczyć przynajmniej na 1 rdzeń procesora oraz 1 GB pamięci operacyjnej RAM.

Także dysk jest jednym z najważniejszych parametrów serwera. To właśnie na nim znajdują się pliki Twojej strony i baza danych. Jeżeli dysk będzie wolny – TTFB się wydłuży. W związku z tym warto odejść od klasycznych dysków talerzowych typu HDD. Decydując się na nośniki SSD – a w szczególności SSD NVMe – możesz liczyć na wielokrotnie szybszy odczyt plików.

Różnice w szybkości poszczególnych generacji dysków są naprawdę zauważalne. (photographylife.com)

Zwróć też uwagę na limit jednoczesnych procesów PHP. To, że hosting ma rozmaite limity, jest zupełnie normalne. Gorzej, jeżeli są one zbyt uciążliwe. Jeżeli limit procesów PHP jest zbyt niski – np. poniżej 10 – to gdy kilkanaście lub kilkadziesiąt osób korzysta jednocześnie z Twojej strony, zapytania muszą czekać w kolejce na realizację. Dlatego 10 jednoczesnych procesów PHP to rozsądne minimum, a przy większym ruchu lepiej rozejrzeć się za pakietem z wyższym limitem.

#10 Używaj szybkiego oprogramowania serwerowego

Wybierając hosting, przyjrzyj się także samemu oprogramowaniu serwerowemu. Ono także ma wpływ na TTFB. Popularnym programem serwerowym jest Apache. To rozwiązanie stabilne, o bardzo szerokich możliwościach rozbudowy (dzięki dodatkowym modułom), jednak gdy chodzi o wydajność, ustępuje innym typom oprogramowania.

Nginx lub LiteSpeed to oprogramowanie serwerowe, które cechuje znacznie wyższa wydajność. Wystarczy spojrzeć na poniższe zestawienie.

Ile żądań na sekundę są w stanie przetworzyć poszczególne programy serwerowe. (wpspeedmatters.com)

Mniejsze obciążenie zasobów serwera sprawia, że hosting reaguje szybciej na zapytania generowane przez użytkowników. W konsekwencji maleje także TTFB.

W przypadku hostingu opartego na LiteSpeed można też znacznie zmniejszyć TTFB poprzez instalację wtyczki LiteSpeed Cache for WordPress (LSCWP). Zapewnia ona cache na poziomie serwera, a także optymalizację obrazów i kodu strony (HTML/CSS/JS). Więcej o tym, kiedy to się opłaca, przeczytasz w tekście LiteSpeed i WordPress – czy warto?. Podobne dodatki od twórców LiteSpeed dostępne są także dla PrestaShop, Magento, Joomla czy Drupal.

Przykład: jak obniżyłem TTFB na semurai.pl

Dopisek Tomasza Stopki (październik 2026). Semurai.pl działa na WordPressie na hostingu MyDevil, gdzie przed Apache stoi nginx. Bez cache stron TTFB wynosił u mnie ok. 2–4 s, czyli wyraźnie w strefie „słaby”. Włączyłem cache w nginx sterowany nagłówkami: anonimowi odwiedzający dostają odpowiedź z Cache-Control: s-maxage=600 (kopia ważna 10 minut), a zalogowani omijają cache. Po tej zmianie TTFB stron z cache spadł w pomiarach curl do ok. 50 ms.

Przy okazji usunąłem zbędne wtyczki i zrobiłem porządki w bazie – rozmiar autoładowanych opcji zmniejszył się z ok. 271 KB do 170 KB. To przyspiesza te żądania, które nie trafiają w cache (np. pierwsze wejście po wygaśnięciu kopii czy panel administracyjny). Jeśli chcesz, żebym przyjrzał się Twojej stronie, zobacz, na czym polega optymalizacja strony.

Najczęściej zadawane pytania o TTFB

Co to jest TTFB?

TTFB (Time To First Byte) to czas od rozpoczęcia nawigacji do otrzymania pierwszego bajtu odpowiedzi serwera. Obejmuje przekierowania, DNS, połączenie z TLS oraz czas, w którym serwer przygotowuje odpowiedź.

Jaki TTFB jest dobry?

Według Google dobry TTFB to maksymalnie 0,8 s (dla 75% wizyt). Wynik od 0,8 do 1,8 s wymaga poprawy, a powyżej 1,8 s jest słaby.

Czy TTFB jest częścią Core Web Vitals?

Nie. Core Web Vitals to LCP, INP i CLS. TTFB wpływa jednak bezpośrednio na LCP, bo wszystko, co dzieje się na stronie, zaczyna się dopiero po otrzymaniu pierwszego bajta.

Jak najszybciej zmniejszyć TTFB w WordPressie?

Zwykle największy efekt daje cache całych stron (wtyczka, cache serwera lub CDN). Dopiero potem warto zająć się PHP, bazą danych, wtyczkami i ewentualną zmianą hostingu.

Przedstawiłem Ci najważniejsze elementy wpływające na czas reakcji serwera. Jak widzisz, wiele z nich możesz dostrzec już na etapie wyboru pakietu hostingowego. Gdy zatem zależy Ci na niskim TTFB, najlepiej od razu przejść do analizy oferty serwera i wdrożyć niezbędne zmiany na stronie WWW.

Autor: Mateusz Mazurek. Przedsiębiorca internetowy. Kiedyś freelancer SEO i właściciel agencji SEO/SEM. Dziś głównie wydawca i autor blogów i stron internetowych. Twórca projektu Jak Wybrać Hosting, w ramach którego testuje, sprawdza i recenzuje usługi hostingowe.

Wpis gościnny. Aktualizacja (październik 2026): Tomasz Stopka.