TTFB (Time To First Byte) to czas, jaki upływa od wysłania żądania HTTP przez przeglądarkę do odebrania pierwszego bajtu odpowiedzi od serwera. Innymi słowy: to czas, przez który użytkownik patrzy na biały ekran, zanim strona w ogóle zacznie się ładować. Google oficjalnie rekomenduje TTFB poniżej 800 ms, ale strony, które serio walczą o pozycje, celują w poniżej 200 ms.
Na świeżym WordPressie z kilkoma wtyczkami TTFB potrafi wynosić 300–600 ms. Na rozbudowanym sklepie WooCommerce z 30 wtyczkami i niezoptymalizowaną bazą — 2–5 sekund. W tym poradniku pokazuję 8 konkretnych poprawek, które realnie obniżają TTFB — posortowanych od najłatwiejszych i najskuteczniejszych do bardziej zaawansowanych.
Jak zmierzyć TTFB?
Zanim zaczniesz optymalizować, musisz wiedzieć, jaki TTFB masz teraz i móc porównać wyniki po zmianach. Trzy najlepsze narzędzia:
- PageSpeed Insights (web.dev/measure) — Google’owy audyt, pokazuje TTFB w sekcji „Server Response Time”. Testuje z serwerów Google, więc symuluje odwiedziny z zewnątrz.
- GTmetrix (gtmetrix.com) — pokazuje TTFB w zakładce „Waterfall” przy pierwszym żądaniu HTTP. Pozwala wybrać lokalizację testową.
- DevTools w przeglądarce — naciśnij F12, przejdź do zakładki „Network”, odśwież stronę (Ctrl+Shift+R), kliknij na pierwszy request (dokument HTML). W prawym panelu znajdziesz „Waiting for server response” (TTFB). Najdokładniejszy test, bo mierzysz z Twojej lokalizacji.
Wykonaj 3 pomiary i uśrednij wynik — TTFB potrafi się wahać o 50–100 ms między kolejnymi żądaniami.
Poprawka 1. Włącz page cache (największy impact)
Bez cache’a WordPress przy każdej wizycie odpala PHP, łączy się z bazą, zbiera posty, menu, widgety, komentarze, przetwarza shortcody i generuje HTML od zera. Z page cache’em — serwer zwraca gotowy plik HTML ze swojej pamięci, omijając PHP i MySQL całkowicie.
Efekt: TTFB spada z 800–2000 ms do 50–200 ms. To pojedynczo największa poprawa, jaką możesz osiągnąć.
Dla serwerów LiteSpeed (cyber_Folks, seohost, zenbox, mydevil)
Zainstaluj wtyczkę LiteSpeed Cache. Jest darmowa, zintegrowana z serwerem, i działa „out of the box” po instalacji. Sprawdź, czy w ustawieniach jest włączony „Page Cache: ON”.
Dla serwerów Apache/Nginx
Zainstaluj WP Super Cache (darmowy, prosty) lub WP Rocket (płatny, najlepszy). Po aktywacji upewnij się, że cache jest włączony i sprawdź TTFB — powinieneś zobaczyć spadek o 60–90%.
Poprawka 2. Włącz OPcache
OPcache to rozszerzenie PHP, które trzyma skompilowany bytecode w pamięci — zamiast kompilować pliki PHP przy każdym żądaniu. WordPress to tysiące plików PHP ładowanych przy każdej stronie; OPcache eliminuje kosztowną kompilację.
Na większości hostingów OPcache jest włączony domyślnie — ale warto to sprawdzić. Utwórz plik phpinfo.php, otwórz go w przeglądarce i szukaj sekcji „Zend OPcache”. Jeżeli jest „Enabled” — masz go. Jeżeli nie — w panelu hostingu znajdź opcję włączenia rozszerzeń PHP i aktywuj opcache. Po teście usuń plik phpinfo.
Jeżeli masz VPS, dodaj do php.ini:
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60Efekt: TTFB spada o 20–40% nawet bez page cache’a (a z page cache’em OPcache przyspiesza generowanie cache dla nowych stron).
Poprawka 3. Zoptymalizuj bazę danych
WordPress z każdym miesiącem użytkowania zbiera w bazie „śmieci”: rewizje wpisów (każdy zapis to nowa wersja), transienty (tymczasowe dane wtyczek, które wygasają ale nie są usuwane), spam, komentarze w koszu, osierocone metadane. Na blogu, który działa 2 lata, potrafi być 50 000+ zbędnych wierszy w bazie.
Zainstaluj WP-Optimize i uruchom jednorazowe czyszczenie:
- Usuń rewizje wpisów (zostaw ostatnie 2–3 per wpis)
- Usuń automatyczne szkice
- Usuń wygasłe transienty
- Usuń spam i komentarze z kosza
- Zoptymalizuj tabele (OPTIMIZE TABLE)
Po czyszczeniu ustaw w WP-Optimize automatyczne czyszczenie co tydzień — wtyczka ma taką opcję w „Ustawienia → Automatyczne czyszczenie”.
Dodatkowo ogranicz liczbę rewizji na przyszłość. W wp-config.php:
define( 'WP_POST_REVISIONS', 3 );WordPress będzie trzymał maksymalnie 3 ostatnie wersje każdego wpisu zamiast nieskończonej liczby.
Poprawka 4. Wyłącz WP-Cron
WP-Cron sprawdza zadania cykliczne przy każdym page view. To dodatkowe zapytanie do bazy i dodatkowy overhead do TTFB — na stronach z dużym ruchem potrafi dodać 50–200 ms. Wyłącz WP-Cron i zastąp go systemowym CRONem — pełna instrukcja jest w poradniku Jak wyłączyć WP-Cron i uruchomić systemowy CRON.
Poprawka 5. Zaktualizuj wersję PHP
Różnica między PHP 7.4 a PHP 8.2+ w benchmarkach WordPressa to 20–30% szybsze przetwarzanie. Jeżeli Twój hosting nadal serwuje PHP 7.x — aktualizacja do 8.2 lub 8.3 to darmowe przyspieszenie.
Zmianę wersji PHP znajdziesz w panelu hostingu (sekcja „PHP” / „Konfiguracja PHP”). Po zmianie sprawdź stronę — jeżeli pojawią się błędy lub WSOD, prawdopodobnie któraś z wtyczek jest niekompatybilna z nowszym PHP. W takim przypadku wróć do poprzedniej wersji, zaktualizuj wtyczki i powtórz próbę.
Poprawka 6. Zredukuj liczbę wtyczek
Każda aktywna wtyczka to dodatkowy kod ładowany przy każdym żądaniu. 10 wtyczek więcej to 10 dodatkowych plików plugin.php do załadowania, 10 hooków init, 10 potencjalnych zapytań do bazy. Na testach: usunięcie 10 mało używanych wtyczek potrafi obniżyć TTFB o 100–300 ms.
Zrób audyt: wejdź do Wtyczki → Zainstalowane wtyczki i dla każdej zadaj sobie pytanie: „czy ta wtyczka jest naprawdę potrzebna?” Typowe kandydaty do usunięcia:
- Wtyczki „hello world” / testowe (Hello Dolly, Akismet jeśli nie używasz komentarzy)
- Wtyczki wyłączone, ale wciąż zainstalowane — nawet nieaktywne wtyczki mogą spowalniać skanowanie katalogu
- Wtyczki duplikujące funkcje (dwie wtyczki SEO, dwa systemy cache, dwa firewall-e)
- Wtyczki „do jednej rzeczy”, która da się zrobić w 3 liniach kodu (np. dodanie Google Analytics — zamiast wtyczki wstaw tag w motywie)
Poprawka 7. Włącz Object Cache (Redis/Memcached)
Page cache przyspiesza frontend (stronę widoczną dla gości). Object cache przyspiesza backend i każde żądanie, które nie może być serwowane z page cache’a (zalogowani użytkownicy, koszyk WooCommerce, panel admina, AJAX). Zamiast za każdym razem odpytywać MySQL, WordPress przechowuje wyniki zapytań w pamięci RAM (Redis lub Memcached).
Efekt: TTFB dla zalogowanych użytkowników spada o 30–60%. Na sklepach WooCommerce, gdzie koszyk i sesja użytkownika uniemożliwiają page cache, to jedyny sposób na szybki TTFB.
Jak włączyć:
- Sprawdź, czy Twój hosting obsługuje Redis lub Memcached (większość lepszych hostingów tak — cyber_Folks, zenbox, mydevil na pewno).
- Zainstaluj wtyczkę Redis Object Cache (darmowa).
- W ustawieniach wtyczki kliknij „Enable Object Cache”.
- Sprawdź status — powinno być „Connected”.
Poprawka 8. Zmień hosting
Jeżeli przeszedłeś przez 7 poprawek wyżej, a TTFB nadal wynosi 1+ sekundy — problem jest po stronie serwera. Najtańsze plany współdzielone (10–15 zł/miesiąc) trzymają na jednym serwerze setki kont, dzielą RAM, CPU i dysk. W godzinach szczytu Twój WordPress dosłownie czeka w kolejce za innymi stronami.
Zmiana hostingu na plan z gwarantowanymi zasobami (VPS, CloudHosting, dedykowane kontenery) potrafi obniżyć TTFB o 50–70%. Polscy dostawcy, którzy konsekwentnie dają dobre wyniki w testach TTFB dla WordPressa:
- cyber_Folks — CloudHosting z LiteSpeed, Redis, SSD NVMe
- zenbox.pl — plany z Redis i SSD
- mydevil.net — tanie, ale z pełnym dostępem SSH i Redis
- seohost.pl — zoptymalizowany pod SEO i szybkość
Jeżeli Twoja strona generuje przychód (sklep, serwis z reklamami), różnica między hostingiem za 15 zł/mc a hostingiem za 60 zł/mc jest groteskowo mała w porównaniu z wartością, jaką daje 3x szybszy TTFB.
Cheat sheet — podsumowanie poprawek
| # | Poprawka | Szacowany spadek TTFB | Trudność |
|---|---|---|---|
| 1 | Page cache | 60–90% | Łatwe |
| 2 | OPcache | 20–40% | Łatwe |
| 3 | Optymalizacja bazy | 10–30% | Łatwe |
| 4 | Wyłącz WP-Cron | 5–15% | Łatwe |
| 5 | Nowszy PHP | 20–30% | Łatwe |
| 6 | Mniej wtyczek | 10–30% | Średnie |
| 7 | Object cache | 30–60% (zalogowani) | Średnie |
| 8 | Lepszy hosting | 50–70% | Średnie |
Procenty nie sumują się liniowo — jeżeli page cache dał Ci TTFB 100 ms, to OPcache nie obniży go dalej do 60 ms, bo cache i tak nie odpala PHP. Ale razem te poprawki dają Ci pewność, że zarówno cached (goście), jak i uncached (zalogowani, AJAX, koszyk) żądania odpowiadają szybko.
Najczęściej zadawane pytania
Jaki TTFB jest „dobry” dla WordPressa?
Google rekomenduje poniżej 800 ms. Realny cel dla zoptymalizowanego WordPressa na przyzwoitym hostingu: 100–300 ms z page cache’em, 300–800 ms bez cache’a (dla zalogowanych). Poniżej 100 ms wchodzisz w strefę CDN / edge cache, co wymaga Cloudflare APO lub podobnej usługi.
Czy CDN obniża TTFB?
CDN (np. Cloudflare, KeyCDN) obniża TTFB dla statycznych zasobów (obrazki, CSS, JS), ale nie dla samego dokumentu HTML — chyba że włączysz pełny page cache na CDN (Cloudflare APO, ~$5/mc). Bez APO: CDN pomaga w LCP i ogólnym ładowaniu, ale TTFB dokumentu pozostaje taki sam.
Czy TTFB wpływa na pozycje w Google?
Bezpośrednio — nie (TTFB nie jest osobnym sygnałem rankingowym). Pośrednio — tak, bo TTFB wpływa na Largest Contentful Paint (LCP), które jest sygnałem Core Web Vitals. Wysoki TTFB = wolny LCP = gorsze oceny CWV = potencjalna strata pozycji. Dlatego optymalizacja TTFB to fundament, na którym stoi cała reszta wydajności.
Czy mogę mieć niski TTFB na współdzielonym hostingu?
Tak — z page cache’em nawet tani hosting może dawać TTFB poniżej 200 ms. Problem pojawia się w godzinach szczytu (kiedy inne strony na tym samym serwerze obciążają zasoby) i dla żądań uncached (zalogowani, koszyk). Na dłuższą metę: jeżeli strona zarabia, zainwestuj w lepszy hosting.
Podsumowanie
TTFB to pierwszy element w łańcuchu ładowania strony — jeżeli serwer odpowiada wolno, żadna optymalizacja frontendu tego nie nadrobi. Zacznij od page cache’a (poprawka #1) — to jedna wtyczka, zero konfiguracji, i spadek TTFB o 60–90%. Potem OPcache, PHP 8.x, czyszczenie bazy. Jeżeli po tych zmianach TTFB nadal jest powyżej 800 ms, problem jest po stronie hostingu — i najlepszą inwestycją jest migracja na lepszy plan.
A jeżeli migracja brzmi groźnie — mamy do tego dedykowany poradnik: Jak przenieść WordPress na inny serwer bez utraty danych.
