Jak skrócić TTFB w WordPressie – praktyczny przewodnik

TTFB (Time to First Byte) – czas do pierwszego bajtu – to jeden z fundamentalnych wskaźników wydajności serwera. Według web.dev dobry TTFB powinien wynosić poniżej 800 ms, a idealny – poniżej 200 ms. Jeśli Twoja strona WordPress przekracza tę granicę, tracisz zarówno pozycje w Google, jak i potencjalnych klientów, którzy nie czekają na wolno ładującą się stronę.

Wysoki TTFB to nie przypadek – wynika z konkretnych, możliwych do naprawienia problemów: braku cache’owania, niezoptymalizowanej bazy danych, wolnego serwera lub zbędnych zapytań PHP. W tym przewodniku przejdziemy przez każdy z tych obszarów krok po kroku.

Co znajdziesz w tym artykule:

• Jak mierzyć TTFB i interpretować wyniki
• 7 technicznych przyczyn wysokiego TTFB w WordPressie
• Konkretne kroki optymalizacji – od cache po serwer
• Porównanie rozwiązań cache dla WordPressa
• FAQ z najczęstszymi pytaniami

Czym jest TTFB i dlaczego ma znaczenie dla SEO?

TTFB mierzy czas od wysłania żądania HTTP przez przeglądarkę do momentu odebrania pierwszego bajtu odpowiedzi serwera. Składają się na niego trzy etapy: rozwiązanie DNS, połączenie TCP (w tym TLS handshake przy HTTPS) oraz czas przetwarzania po stronie serwera.

Google uwzględnia TTFB jako sygnał w ocenie Core Web Vitals. Bezpośrednio wpływa na LCP (Largest Contentful Paint) – jeśli serwer odpowiada po 2 sekundach, LCP nie może być dobry, nawet jeśli sama strona jest lekka. Według Web Almanac 2024 mediana TTFB dla stron mobilnych wynosi 1,8 s – a to już przekracza próg „wymaga poprawy”.

Dla stron firmowych wysokie TTFB oznacza wyższy bounce rate. Badania Google pokazują, że opóźnienie odpowiedzi serwera o 100 ms zwiększa liczbę odrzuceń o kilka procent – efekt kumulatywny przy tysiącach wizyt jest znaczący.

Jak zmierzyć TTFB w WordPressie?

Zanim zaczniesz optymalizować, musisz wiedzieć, jaki masz aktualny TTFB. Dostępne narzędzia:

Google PageSpeed Insights

Odwiedź pagespeed.web.dev i wklej adres strony. W sekcji „Diagnostics” znajdziesz „Reduce server response times (TTFB)” z dokładnym pomiarem. Narzędzie testuje z serwera Google – wyniki mogą różnić się od Twoich użytkowników.

Chrome DevTools

Otwórz DevTools (F12), zakładka „Network”, odśwież stronę. Kliknij żądanie dokumentu HTML – w panelu „Timing” zobaczysz rozbicie na DNS Lookup, Initial Connection, SSL, TTFB i Content Download. To najdokładniejsza metoda dla Twojej lokalizacji.

curl z pomiarem czasu

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s
Total: %{time_total}s
" https://twojadomena.pl/

Uruchom test 3-5 razy i uśrednij wyniki – pierwsze żądanie może być wolniejsze przez brak cache w Nginx/Apache.

7 przyczyn wysokiego TTFB w WordPressie

1. Brak cache’owania stron

WordPress domyślnie generuje każdą stronę dynamicznie – PHP odpytuje bazę danych, zbiera dane z pluginów i składa HTML przy każdym żądaniu. Bez cache każdy odwiedzający czeka na ten proces od nowa. To najczęstsza i najłatwiejsza do naprawienia przyczyna.

2. Wolna baza danych MySQL

Niezoptymalizowane tabele, brak indeksów, nadmiar wpisów w `wp_options` (szczególnie autoload) oraz przestarzałe dane z usuniętych pluginów mogą spowalniać zapytania o setki milisekund. WordPress wykonuje dziesiątki zapytań SQL przy każdym ładowaniu strony.

3. Zbyt wiele pluginów

Każdy aktywny plugin dodaje kod PHP do ładowania przy każdym żądaniu. 40+ aktywnych pluginów to norma na wielu stronach – i poważny problem wydajnościowy. Pluginy hookujące się do `init` lub `wp_head` wykonują się niezależnie od tego, czy są potrzebne na danej podstronie.

4. Słaba konfiguracja serwera

Współdzielony hosting (shared hosting) to najczęstszy powód chronicznego wysokiego TTFB. Serwer obsługuje setki innych stron, zasoby CPU i RAM są limitowane, a PHP uruchamiane w wersji starszej niż 8.x. Brak opcache PHP to kolejna strata.

5. Brak CDN lub błędna konfiguracja

Jeśli Twój serwer stoi w USA, a klienci są z Polski, każde żądanie pokonuje tysiące kilometrów. CDN (Content Delivery Network) rozwiązuje ten problem przez serwowanie plików statycznych z węzłów bliżej użytkownika.

6. Niezoptymalizowane autoloaded options

WordPress ładuje przy każdym uruchomieniu wszystkie opcje z flagą `autoload=yes`. Porzucone pluginy zostawiają setki takich wpisów – w ekstremalnych przypadkach tabela `wp_options` waży kilka MB i jest ładowana w całości do pamięci.

7. Brak HTTP/2 lub HTTP/3

Stare serwery działające na HTTP/1.1 serializują żądania – przeglądarka czeka na odpowiedź przed wysłaniem kolejnego. HTTP/2 i HTTP/3 obsługują wielokrotne żądania równolegle, co skraca odczuwalny czas ładowania strony.

Optymalizacja TTFB – praktyczne kroki

Krok 1: Wdróż cache stron

Cache stron to najszybszy sposób na obniżenie TTFB z kilku sekund do kilkudziesięciu milisekund. Serwer zamiast generować stronę dynamicznie, serwuje gotowy plik HTML z dysku.

Plugin cache	Typ cache	Darmowy?	Zalety
WP Rocket	Plikowy + Redis	Nie (ok. 59$/rok)	Kompletny, łatwy w konfiguracji
W3 Total Cache	Plikowy, DB, Object	Tak (wersja podstawowa)	Wiele opcji, integracja CDN
LiteSpeed Cache	Serwer LiteSpeed	Tak	Najszybszy na LiteSpeed, Redis
WP Super Cache	Plikowy	Tak	Prosty, stabilny, od Automattic
Nginx FastCGI	Serwer Nginx	Tak (wymaga VPS)	Najniższy TTFB możliwy

Dla stron na hostingu VPS najlepszym wyborem jest cache na poziomie Nginx (FastCGI cache) – serwer odpowiada w 5-15 ms bez uruchamiania PHP w ogóle.

Krok 2: Optymalizuj bazę danych

Sprawdź rozmiar tabeli autoload:

SELECT SUM(LENGTH(option_value)) as autoload_size
FROM wp_options
WHERE autoload='yes';

Jeśli wynik przekracza 1 MB, masz problem. Zidentyfikuj największe wpisy:

SELECT option_name, LENGTH(option_value) as size
FROM wp_options
WHERE autoload='yes'
ORDER BY size DESC
LIMIT 20;

Usuń wpisy z porzuconych pluginów i przestaw niepotrzebne na `autoload=no`. Plugin WP-Optimize robi to przez interfejs graficzny.

Krok 3: Włącz PHP OPcache

PHP OPcache przechowuje skompilowane bajtkody PHP w pamięci RAM – eliminuje kompilację przy każdym żądaniu. Na VPS dodaj do `php.ini`:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60

Na hostingu współdzielonym zapytaj providera o status OPcache – większość dostawców ma go włączonego domyślnie.

Krok 4: Dodaj object cache (Redis lub Memcached)

Object cache przechowuje wyniki zapytań do bazy danych w pamięci RAM. WordPress z pluginem Redis Object Cache i działającym serwerem Redis potrafi skrócić czas generowania strony o 30-60%.

Instalacja Redis na Ubuntu/Debian:

apt install redis-server php-redis
systemctl enable redis-server

Następnie w `wp-config.php`:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);

Krok 5: Użyj CDN z cache na brzegu sieci

Cloudflare to darmowe rozwiązanie CDN, które poza przyspieszeniem serwowania plików statycznych może cache’ować całe strony HTML. Według Cloudflare blog ich infrastruktura odpowiada z węzłów oddalonych o mniej niż 50 ms od 95% internautów.

Konfiguracja Cloudflare dla WordPressa:

• Włącz „Cache Rules” dla statycznych URL-i (nie loguj się do panelu przez Cloudflare)
• Ustaw „Browser Cache TTL” na minimum 4 godziny dla stron statycznych
• Włącz „Rocket Loader” dla odroczenia skryptów JS
• Używaj „Page Rules” do wykluczenia `/wp-admin/*` z cache

Krok 6: Zaktualizuj PHP do wersji 8.3+

PHP 8.3 jest nawet 3x szybsze od PHP 7.4 w testach syntetycznych. Jeśli Twój hosting wciąż używa PHP 7.x, to jeden z najprostszych sposobów na poprawę TTFB – zmiana wersji PHP w panelu hostingowym zajmuje minutę. Sprawdź aktualną wersję w WordPress Admin – Narzędzia – Stan witryny.

Krok 7: Zoptymalizuj zapytania SQL z Query Monitor

Plugin Query Monitor (darmowy, z WordPress.org) pokazuje wszystkie zapytania SQL na stronie, ich czas wykonania i skąd pochodzą. Szukaj zapytań trwających ponad 10 ms – to kandydaci do optymalizacji lub zastąpienia cache’owaniem.

TTFB a wybór hostingu – praktyczne porównanie

Rodzaj hostingu ma fundamentalne znaczenie dla osiągalnego TTFB. W projektach dla klientów z regionu Piaseczna i Warszawy obserwujemy dramatyczne różnice:

Typ hostingu	Typowy TTFB	Koszt/mies.	Rekomendacja
Shared hosting (tani)	1500-4000 ms	10-30 zł	Tylko dla portfolio/wizytówek z minimalnym ruchem
Shared hosting (premium)	400-900 ms	50-150 zł	Akceptowalny start dla małych firm
VPS (bez optymalizacji)	200-500 ms	40-100 zł	Dobra baza, wymaga konfiguracji
VPS + Nginx cache	20-80 ms	40-100 zł	Optymalne rozwiązanie
Managed WordPress (Kinsta, WP Engine)	100-300 ms	200-500 zł	Wygoda bez zaawansowanej techniki

Jeśli planujesz profesjonalną stronę firmową, zapoznaj się z naszą ofertą hostingu dla WordPressa i przeczytaj szczegółowe porównanie w artykule o wyborze między projektowaniem stron a gotowymi rozwiązaniami.

Checklist optymalizacji TTFB – co zrobić dzisiaj

• Zmierz aktualny TTFB przez Google PageSpeed Insights lub Chrome DevTools
• Zainstaluj plugin cache (WP Rocket, W3 Total Cache lub LiteSpeed Cache)
• Sprawdź wersję PHP – zaktualizuj do 8.2 lub 8.3 jeśli na starszej
• Sprawdź rozmiar autoload w `wp_options` – wyczyść niepotrzebne wpisy
• Dodaj Cloudflare jako CDN (darmowy plan wystarczy na start)
• Zainstaluj Query Monitor i zidentyfikuj wolne zapytania SQL
• Sprawdź czy PHP OPcache jest włączony (Admin – Narzędzia – Stan witryny)
• Rozważ migrację na VPS z Nginx + FastCGI cache jeśli TTFB > 1 s

Ważne: Po każdej zmianie konfiguracji wyczyść cache i ponów pomiar TTFB z co najmniej 3 prób. Pierwsze żądanie po wyczyszczeniu cache jest zawsze wolniejsze – porównuj wyniki „warm cache”.

Najczęstsze błędy przy optymalizacji TTFB

Błąd 1: Cache’owanie bez wykluczania stron dynamicznych. Strony koszyka WooCommerce, panel logowania i strony z personalizowaną treścią nie powinny być cache’owane. Każdy dobry plugin cache ma opcję wykluczeń – skonfiguruj je od razu.

Błąd 2: Kilka pluginów cache naraz. Instalowanie WP Super Cache i WP Rocket jednocześnie powoduje konflikty. Zostaw jeden plugin.

Błąd 3: Pomijanie TTFB na rzecz samego LCP. LCP możesz poprawić lazy loadingiem obrazków, ale jeśli serwer odpowiada po 3 sekundach, LCP nigdy nie będzie dobry. TTFB to fundament.

Błąd 4: Testowanie tylko z jednej lokalizacji. Jeśli testujesz z Warszawy a klienci są z Wrocławia, wyniki mogą się różnić. Używaj WebPageTest z różnych lokalizacji testowych.

Jeśli szukasz profesjonalnej pomocy przy optymalizacji wydajności, sprawdź naszą ofertę i cennik lub skontaktuj się bezpośrednio przez formularz kontaktowy.

FAQ – najczęstsze pytania o TTFB w WordPressie

Jaki TTFB jest dobry dla WordPressa?

Według wytycznych Google dobry TTFB to poniżej 800 ms, a idealny – poniżej 200 ms. Dla WordPressa z aktywnym cache na poziomie serwera (Nginx FastCGI) osiągalne jest 20-80 ms. Większość poprawnie skonfigurowanych stron na VPS powinna mieścić się w 150-400 ms bez zaawansowanej optymalizacji.

Czy Cloudflare faktycznie poprawia TTFB?

Cloudflare może zarówno poprawić, jak i pogorszyć TTFB – zależy od konfiguracji. Bez cache’owania HTML Cloudflare dodaje jeden skok sieciowy. Z włączonymi Cache Rules lub pluginem Cloudflare APO (Automatic Platform Optimization dla WordPressa) TTFB spada dramatycznie, bo treść serwowana jest z węzłów edge blisko użytkownika.

Plugin cache czy cache na poziomie serwera – co lepsze?

Cache na poziomie serwera (Nginx FastCGI Cache, Varnish) jest szybszy – serwer odpowiada przed uruchomieniem PHP. Pluginy cache działają w warstwie PHP i są wolniejsze, ale łatwiejsze w konfiguracji. Dla hostingu współdzielonego plugin to jedyna opcja; dla VPS kombinacja Nginx cache + Redis object cache daje najlepsze wyniki.

Dlaczego mój TTFB jest wysoki tylko przy pierwszym żądaniu?

To normalne zachowanie – „cold cache”. Pierwsze żądanie generuje stronę i zapisuje ją w cache. Kolejne serwują gotowy plik. Jeśli cache wygasa zbyt szybko lub jest zbyt często czyszczony, efekt cold cache jest odczuwalny częściej. Sprawdź ustawienia TTL cache i czy nie ma pluginów resetujących cache przy każdej zmianie wpisu.

Jak TTFB wpływa na pozycję w Google?

Google używa Core Web Vitals jako sygnału rankingowego. TTFB bezpośrednio wpływa na LCP (Largest Contentful Paint) – im wyższy TTFB, tym trudniej osiągnąć LCP poniżej 2,5 s. Google Search Central dokumentuje, że szybkość strony jest czynnikiem rankingowym od 2010 roku, a od 2021 Core Web Vitals są oficjalnie uwzględniane w algorytmie.

Czy warto inwestować w droższy hosting, żeby poprawić TTFB?

Tak, jeśli Twoja strona generuje ruch i konwersje. Badania pokazują, że poprawa TTFB z 2 s do 200 ms może obniżyć bounce rate o kilkanaście procent. Dla e-commerce każda sekunda opóźnienia to realna strata sprzedaży. Koszt VPS z dobrą konfiguracją (40-80 zł/mies.) zwraca się szybko przy nawet kilkuset wizytach dziennie. Sprawdź też nasze plany hostingowe zoptymalizowane pod WordPress.

Podsumowanie

TTFB w WordPressie to nie przypadek – to wynik konfiguracji. Każdy z opisanych kroków samodzielnie może obniżyć TTFB o 20-60%. Razem, w szczególności połączenie cache na poziomie serwera, Redis object cache i CDN, pozwalają zejść poniżej 100 ms nawet na skromnym VPS.

Zacznij od pomiaru aktualnego TTFB i instalacji pluginu cache – to jednorazowe działania z natychmiastowym efektem. Jeśli po tych krokach TTFB nadal przekracza 500 ms, rozważ migrację na VPS lub audyt wydajności z nami.

Potrzebujesz pomocy z optymalizacją strony WordPress lub migracją na szybszy hosting? Specjalizujemy się w przyspieszaniu stron firmowych – opisz swój problem przez formularz kontaktowy, a wrócimy z diagnozą i wyceną w ciągu 24 godzin. Sprawdź też nasz cennik usług, żeby wiedzieć czego się spodziewać.