Największą poprawę TTFB w WordPressie daje optymalizacja backendu, a nie kompresja obrazów czy minifikacja CSS. Zacznij od hostingu, page cache, wersji PHP i zapytań do bazy danych. Dopiero później zajmij się dodatkowymi warstwami, takimi jak Redis lub CDN.
Czym jest TTFB w WordPressie?
TTFB, czyli Time to First Byte, to czas od wysłania żądania HTTP do chwili otrzymania pierwszego bajtu odpowiedzi. W WordPressie obejmuje między innymi uruchomienie PHP, wykonanie kodu motywu i wtyczek, zapytania do bazy danych oraz wygenerowanie HTML.
To parametr backendowy. Obrazy, arkusze CSS i skrypty JavaScript mogą wydłużać pełne ładowanie strony, ale nie skrócą czasu, w którym serwer zaczyna odpowiadać. Dlatego przy wysokim TTFB trzeba analizować hosting, konfigurację cache, PHP, bazę danych i kod WordPressa.
Jak zmierzyć TTFB?
Wykonaj kilka pomiarów dla strony głównej, wpisu i podstrony. Sprawdzaj wyniki w różnych porach oraz z podobnej lokalizacji, z której korzystają odbiorcy. Przydatne narzędzia to:
- Google PageSpeed Insights pozwala sprawdzić TTFB w danych laboratoryjnych i, gdy są dostępne, porównać je z doświadczeniami rzeczywistych użytkowników.
- WebPageTest pokazuje szczegółowy przebieg żądania i ułatwia odróżnienie opóźnienia sieci od czasu pracy serwera.
- Chrome DevTools mierzy czas oczekiwania dla dokumentu w zakładce Network, w sekcji Timing.
- Query Monitor pomaga znaleźć wolne zapytania SQL, błędy PHP i wtyczki obciążające generowanie strony.
Orientacyjna interpretacja wyniku wygląda następująco:
| Czas TTFB | Ocena | Co sprawdzić? |
|---|---|---|
| Poniżej 200 ms | Bardzo dobry | Utrzymuj konfigurację i monitoruj zmiany. |
| 200–500 ms | Akceptowalny | Wynik jest poprawny dla większości stron WordPress. |
| 500–800 ms | Wymaga optymalizacji | Sprawdź cache, obciążenie serwera i zapytania do bazy. |
| Powyżej 800 ms | Słaby | Przeanalizuj hosting, PHP, wtyczki i sposób generowania HTML. |
Zakresy są orientacyjne. Sklep WooCommerce z koszykiem i logowaniem ma inne wymagania niż statyczny wpis blogowy. Warto też rozróżnić pomiar z działającym cache, który pokazuje szybkość obsługi typowego użytkownika, od pomiaru bez cache, który lepiej ujawnia wydajność backendu.
Co powoduje wysoki TTFB?
Najczęściej problem wynika z kilku nakładających się czynników. Najważniejsze wąskie gardła to:
- Przeciążony hosting z ograniczonym CPU, pamięcią RAM lub liczbą procesów PHP.
- Brak page cache, przez który WordPress generuje stronę od początku przy każdym żądaniu.
- Zbyt wiele wtyczek wykonujących kod PHP, zapytania SQL lub połączenia z zewnętrznymi usługami.
- Nieoptymalne zapytania do MySQL lub MariaDB, szczególnie przy dużej liczbie wpisów, produktów i metadanych.
- Nieaktualna wersja PHP, ciężki motyw albo page builder rozbudowujący logikę generowania strony.
Hosting ma większe znaczenie niż sama wtyczka cache. Wtyczka może przygotować i obsłużyć cache aplikacji, ale nie naprawi trwale przeciążonego serwera ani wolnych zapytań wykonywanych podczas generowania niezbuforowanych stron.
Jak poprawić TTFB w WordPressie krok po kroku?
- Zacznij od hostingu. Wybierz środowisko przygotowane do pracy z WordPressem, z szybkimi dyskami SSD lub NVMe, aktualnym PHP, odpowiednimi limitami procesów i sprawną bazą danych. Serwer LiteSpeed może być dobrym wyborem, ponieważ obsługuje cache na poziomie serwera i współpracuje z LSCache. Apache lub Nginx także mogą działać szybko, ale wymagają właściwej konfiguracji cache i PHP.
- Włącz page cache. Dla serwera LiteSpeed użyj LiteSpeed Cache. Na Apache lub Nginx bez LSCache możesz wykorzystać rozwiązanie takie jak WP Rocket albo WP Super Cache. Cache HTML pozwala zwrócić gotową stronę bez ponownego uruchamiania PHP i odpytywania bazy danych. To zwykle daje większą poprawę niż optymalizowanie pojedynczych skryptów.
- Dodaj cache obiektowy. Redis przechowuje często używane dane w pamięci RAM, dzięki czemu WordPress nie musi za każdym razem pobierać ich z bazy. Jest szczególnie przydatny przy WooCommerce, rozbudowanych wyszukiwarkach, systemach członkowskich i stronach wykonujących wiele zapytań. Redis nie zastępuje page cache, lecz uzupełnia go przy treściach dynamicznych.
- Zaktualizuj PHP i sprawdź kompatybilność. Nowsza stabilna wersja PHP zwykle sprawniej wykonuje kod, ale przed zmianą wykonaj kopię zapasową i sprawdź motyw oraz wtyczki. Wersję PHP możesz zweryfikować w WordPressie w sekcji Narzędzia, Stan witryny, Informacje, Serwer.
- Ogranicz zapytania do bazy. Uruchom Query Monitor i znajdź najwolniejsze zapytania, powtarzające się operacje oraz wtyczki działające na każdej podstronie. Usuń nieużywane dodatki, a funkcje potrzebne tylko w sklepie, formularzu lub panelu klienta ogranicz do tych miejsc.
- Skonfiguruj CDN, gdy użytkownicy są rozproszeni geograficznie. CDN skraca dystans sieciowy i może przejąć obsługę zasobów statycznych. Przy stronach o w dużej mierze statycznej treści możliwe jest także buforowanie HTML, ale dla WooCommerce, logowania i personalizacji trzeba ustawić wykluczenia. Sam darmowy CDN, który buforuje wyłącznie pliki statyczne, nie musi znacząco obniżyć TTFB generowanego przez serwer źródłowy.
- Testuj po każdej zmianie. Zapisz wynik początkowy, zmień jeden element i ponów pomiar. Sprawdzaj zarówno wersję z cache, jak i niezbuforowaną. Dzięki temu dowiesz się, czy poprawę przyniosła migracja, cache, Redis, aktualizacja PHP czy usunięcie konkretnej wtyczki.
Uwaga: nie instaluj dwóch wtyczek page cache jednocześnie, na przykład LiteSpeed Cache i WP Rocket. Mogą nadpisywać reguły serwera, tworzyć różne wersje cache i powodować błędy wyświetlania. Wybierz jedno główne rozwiązanie. W sklepie WooCommerce wyklucz z cache koszyk, checkout, konto użytkownika i inne strony zależne od sesji.
Jak wtyczki wpływają na TTFB?
Każda aktywna wtyczka może podpinać własne funkcje do mechanizmu WordPressa. Nie oznacza to, że sama liczba dodatków przesądza o szybkości. Większe znaczenie ma to, ile operacji wykonują i czy działają globalnie.
Ciężkie page buildery, rozbudowane filtry produktów, systemy statystyk, wyszukiwarki live, wtyczki członkowskie i integracje z zewnętrznymi API mogą wydłużać generowanie odpowiedzi. Wtyczka formularza potrzebna wyłącznie na stronie kontaktowej nie powinna inicjować całej logiki na blogu. Do kontroli zasobów można wykorzystać Perfmatters z funkcją Script Manager lub Asset CleanUp, ale wyłączanie plików wymaga testów. Błędne odcięcie zależności może zepsuć formularz, koszyk albo nawigację.
Nie myl TTFB z czasem ładowania obrazów. Kompresja grafiki może poprawić LCP, lecz nie rozwiązuje wolnej odpowiedzi PHP. Przy TTFB powyżej 800 ms najpierw zajmij się hostingiem, cache i backendem.
Najważniejsza kolejność działań
Najpierw zmierz TTFB, potem sprawdź hosting i włącz jeden system page cache. Następnie zaktualizuj PHP, uruchom Redis dla treści dynamicznych i przeanalizuj zapytania oraz wtyczki. CDN dołóż wtedy, gdy potrzebujesz ograniczyć opóźnienia geograficzne lub odciążyć serwer. Jeśli po tych zmianach wynik nadal przekracza 800 ms, przyczyną może być nieoptymalny motyw, wtyczka albo kod wymagający analizy programistycznej.
TTFB jest fundamentem szybkości odpowiedzi WordPressa. Gdy serwer długo przygotowuje pierwszy bajt, późniejsza optymalizacja frontendu nie usunie początkowego opóźnienia. Największy efekt daje uporządkowanie infrastruktury, cache i kodu backendu.
