Czym jest TTFB i jak skrócić czas oczekiwania na odpowiedź serwera?

Klikasz adres strony, ale przez chwilę nie pojawia się żadna treść. Przyczyną może być wysoki TTFB, czyli długie oczekiwanie na początek odpowiedzi. Wyjaśnię, co oznacza ten wskaźnik, jak go sprawdzić i od czego zacząć poprawę szybkości witryny.

TTFB pokazuje, jak długo czekam na początek odpowiedzi

TTFB to skrót od Time to First Byte, czyli czasu do pierwszego bajtu. W pomiarze wejścia na stronę opisuje okres od rozpoczęcia nawigacji do nadejścia pierwszego bajtu odpowiedzi. Nie oznacza czasu pobrania całej witryny. W tej chwili przeglądarka dopiero zaczyna odbierać odpowiedź, a wyświetlenie zawartości może wymagać dalszej pracy. web.dev

Najprościej porównałbym to do rozmowy telefonicznej. Wybierasz numer i czekasz, aż ktoś odbierze. Samo odebranie połączenia nie oznacza jeszcze załatwienia sprawy, ale bez niego rozmowa nie ruszy. Podobnie niski TTFB pozwala szybciej rozpocząć kolejne etapy ładowania. Nie gwarantuje jednak, że zdjęcia i pozostałe elementy pojawią się natychmiast.

Dlatego rozdzielam dwa pytania. Czy strona długo czeka na odpowiedź? Czy odpowiedź przychodzi szybko, ale później długo trwa wyświetlanie zawartości? Te sytuacje mogą wyglądać podobnie dla odwiedzającego. Wymagają jednak innych działań. W tym poradniku skupiam się przede wszystkim na odpowiedzi dokumentu HTML, który stanowi podstawę wyświetlanej strony.

Dlaczego określenie „czas reakcji serwera” jest uproszczeniem?

TTFB często przedstawia się jako czas potrzebny serwerowi na przygotowanie strony. To przydatny skrót, ale niepełny opis. Przy pomiarze całej nawigacji dochodzą między innymi przekierowania, ustalenie adresu serwera oraz zestawienie połączenia. Znaczenie ma również odległość i jakość sieci. Nie mogę więc zobaczyć wysokiego wyniku i od razu uznać, że hosting działa źle.

Ustalenie adresu odbywa się przez DNS, czyli system przypisujący domenie informacje potrzebne do połączenia. Przy HTTPS przeglądarka uzgadnia też szyfrowane połączenie. Dopiero część całego oczekiwania przypada na przygotowanie odpowiedzi przez aplikację. Poszczególne narzędzia mogą jednak pokazywać różne fragmenty tego procesu pod podobnymi nazwami. web.dev

Z tego powodu porównuję wyniki wykonane tą samą metodą. Nie zestawiam bezpośrednio czasu pracy aplikacji z pełnym czasem wejścia na stronę. Jeśli test pochodzi z odległego kraju, uwzględniam lokalizację pomiaru. Najpierw ustalam, co właściwie zostało zmierzone. Dopiero później szukam przyczyny opóźnienia.

Jaki TTFB uznaję za dobry?

W dokumentacji web.dev orientacyjny dobry wynik to maksymalnie 0,8 sekundy, czyli 800 milisekund. Wartość powyżej 1,8 sekundy jest uznawana za słabą. Pomiędzy tymi granicami znajduje się zakres wymagający poprawy. Traktuję te wartości jako wskazówkę diagnostyczną, a nie sztywną ocenę każdego rodzaju strony. web.dev

Nie porównuję bezrefleksyjnie prostego poradnika z widokiem konta klienta. Pierwszy może zostać wysłany z gotowej kopii. Drugi często wymaga sprawdzenia uprawnień i pobrania indywidualnych danych. Oba powinny działać sprawnie, ale nie muszą osiągać identycznych wyników. Ważne jest również to, co dzieje się po otrzymaniu odpowiedzi.

Nie zadowalam się pojedynczym bardzo szybkim testem. Wolę wiedzieć, czy strona odpowiada stabilnie w zwykłych warunkach. Jeśli większość prób wygląda dobrze, lecz regularnie pojawiają się długie opóźnienia, nadal szukam problemu. Użytkownik trafiający na taki moment nie odczuje korzyści z najlepszego wyniku zapisanego w raporcie.

Jak sprawdzam TTFB w PageSpeed Insights?

Zaczynam od PageSpeed Insights, ponieważ pozwala połączyć ogólną ocenę strony z informacjami o doświadczeniach odwiedzających. Rozróżniam jednak dane rzeczywistych użytkowników i test laboratoryjny. Pierwsze pochodzą z raportu Chrome UX Report i obejmują okres ostatnich 28 dni. Drugie opisują próbę przeprowadzoną w określonych warunkach. Rozbieżność między nimi nie musi oznaczać błędu narzędzia.

W części z danymi użytkowników sprawdzam dodatkowe wskaźniki, wśród których może być widoczny TTFB. Zwracam uwagę, czy raport dotyczy konkretnego adresu, czy całego źródła, czyli danego połączenia protokołu, domeny i portu. Przy niedostatecznej ilości danych wynik dla pojedynczej podstrony może nie być dostępny. Nie traktuję wtedy wyniku zbiorczego jako dokładnego pomiaru wskazanego artykułu.

Dane terenowe są prezentowane między innymi jako 75. percentyl. W uproszczeniu oznacza to wartość, której nie przekracza 75% uwzględnionych pomiarów. Po optymalizacji nie oczekuję natychmiastowej zmiany całego raportu historycznego. Bieżące testy mogą już pokazywać poprawę, podczas gdy wcześniejsze wizyty nadal wpływają na zestawienie. developers.google.com

Jak sprawdzam, na którym etapie pojawia się opóźnienie?

Gdy potrzebuję dokładniejszego obrazu, otwieram narzędzia deweloperskie Chrome i przechodzę do zakładki Network, czyli Sieć. Następnie odświeżam stronę i wybieram żądanie głównego dokumentu, zwykle oznaczone jako document. W sekcji Timing widzę podział czasu na etapy. Dzięki temu mogę odróżnić zestawianie połączenia od oczekiwania na odpowiedź.

Pozycja Waiting for server response obejmuje oczekiwanie związane z odpowiedzią serwera oraz komunikacją sieciową. Nie jest czystym pomiarem wykonywania kodu strony. Nie stanowi też pełnego czasu nawigacji obejmującego wszystkie wcześniejsze etapy. To ważne, gdy próbuję porównać ten odczyt z wynikiem innego narzędzia. developer.chrome.com

Przy porównywaniu prób zapisuję warunki pomiaru. Sprawdzam, czy jestem zalogowany i czy przeglądarka korzysta z lokalnej pamięci podręcznej. Wyłączenie cache w narzędziach przeglądarki nie wyłącza automatycznie cache hostingu ani CDN. Dlatego sam przycisk odświeżania nie wystarcza do sprawdzenia, jak szybko aplikacja generuje stronę od początku.

Zanim coś zmienię, porównuję kilka rodzajów stron

Nie diagnozuję całej witryny wyłącznie na podstawie strony głównej. Sprawdzam także artykuł, kategorię i ważną podstronę oferty. W sklepie dokładam produkt oraz koszyk. Szukam powtarzalnego wzorca. Jeżeli wolno działa tylko jeden typ widoku, zaczynam od funkcji charakterystycznych dla tego miejsca.

Załóżmy, że zwykły artykuł odpowiada szybko, a wyszukiwarka produktów wyraźnie zwalnia. W pierwszej kolejności sprawdziłbym sposób wyszukiwania i zapytania do bazy. Jeśli opóźnienia dotyczą całej strony o podobnych porach, przyjrzałbym się obciążeniu serwera. To wskazówki do dalszej analizy, a nie gotowy dowód winy konkretnego elementu.

Porównuję też pierwsze wejście i kolejne odwiedziny tego samego adresu. Duża różnica może sugerować znaczenie pamięci podręcznej, ale wymaga potwierdzenia. Zapisuję wyniki przed zmianami, żeby mieć punkt odniesienia. Bez tego łatwo pomylić poprawę z chwilowo mniejszym ruchem albo korzystniejszym połączeniem.

Pamięć podręczna strony ogranicza powtarzanie tej samej pracy

W dynamicznej witrynie serwer może przy każdym wejściu uruchamiać kod i pobierać informacje z bazy. Dopiero potem przygotowuje dokument dla przeglądarki. Cache strony pozwala zachować gotową odpowiedź i wykorzystać ją ponownie. Przy publicznych treściach bywa to bardzo skuteczny sposób skrócenia oczekiwania. Nie trzeba za każdym razem odtwarzać identycznego rezultatu. web.dev

Na WordPressie sprawdzam, czy hosting albo odpowiednia wtyczka zapewniają taki mechanizm. Samo zainstalowanie dodatku nie oznacza jeszcze, że kopie są prawidłowo wykorzystywane. Przykładowo LiteSpeed Cache wymaga odpowiedniego środowiska dla swojej funkcji buforowania stron. Pozostałe funkcje optymalizacyjne wtyczki nie są dowodem działania tego cache. WordPress.org

Po konfiguracji porównuję odpowiedź bez gotowej kopii oraz kolejne odpowiedzi z pamięci podręcznej. Sprawdzam też aktualizowanie treści po zmianach. Nie dokładam kilku konkurujących mechanizmów bez poznania ich działania. Wolę jeden poprawnie skonfigurowany proces niż zestaw dodatków, po którym trudno ustalić źródło nieaktualnej strony.

Potrzebujesz wsparcia z SEO dla wordpressa? Napisz do mnie a spróbuje Ci pomóc.

W sklepie nie zapisuję każdej odpowiedzi do wspólnego cache

Koszyk, konto klienta i finalizacja zamówienia zawierają dane zależne od konkretnej osoby. Nie powinny trafiać do wspólnej kopii udostępnianej wszystkim odwiedzającym. W WooCommerce te widoki należy odpowiednio wyłączyć z cache strony. Dokumentacja wskazuje także znaczenie sesji i plików cookie związanych z zakupami. WooCommerce developer docs

Dlatego optymalizując sklep, testuję nie tylko szybkość publicznej karty produktu. Sprawdzam dodawanie do koszyka, zmianę ilości i logowanie. Kontroluję również ceny oraz zawartość widoczną dla różnych klientów. Dobry wynik testu nie rekompensuje błędnego działania zamówień. Najpierw muszę mieć pewność, że każda osoba otrzymuje właściwe informacje.

Widoki dynamiczne nadal można przyspieszać. Wymagają jednak ograniczenia pracy aplikacji i usprawnienia dostępu do danych. Nie próbuję rozwiązywać każdego problemu przez dłuższe przechowywanie gotowego HTML. Właśnie tutaj znaczenia nabierają jakość integracji, wydajność bazy i odpowiednie zasoby serwera.

Redis i OPcache pomagają inaczej niż cache całej strony

Redis może służyć jako zaplecze trwałej pamięci obiektowej. W WordPressie wymaga to odpowiedniej integracji. Dzięki niej wybrane wyniki operacji mogą zostać wykorzystane przy kolejnych żądaniach. Samo udostępnienie Redisa przez hosting nie oznacza jeszcze, że witryna z niego korzysta. Domyślna pamięć obiektowa WordPressa nie zachowuje danych pomiędzy żądaniami bez dodatkowego rozwiązania. Developer.WordPress.org

Nie traktuję Redisa jako zamiennika gotowej kopii strony. Może ograniczać powtarzane operacje, ale aplikacja nadal wykonuje część pracy. Efekt zależy od tego, co faktycznie zajmuje czas. Jeśli problemem jest oczekiwanie na zewnętrzną usługę, dołożenie pamięci obiektowej nie musi usunąć przyczyny.

OPcache działa jeszcze inaczej. Przechowuje przygotowany kod pośredni PHP, ograniczając potrzebę jego ponownego przetwarzania. O konfigurację tego mechanizmu pytam administratora lub hosting. Nie musisz znać wszystkich szczegółów technicznych. Warto jednak rozumieć, że pod słowem „cache” kryją się różne rozwiązania, które mogą się uzupełniać. Manual

CDN może skrócić drogę do użytkownika, ale nie naprawi wszystkiego

CDN to sieć serwerów pośredniczących w dostarczaniu treści. Może udostępniać je bliżej odwiedzającego, ograniczając znaczenie odległości od właściwego hostingu. Sprawdzam jednak, jakie zasoby faktycznie przechowuje. Przyspieszenie zdjęć nie oznacza automatycznie skrócenia oczekiwania na główny dokument HTML.

Dobrym przykładem jest Cloudflare, który domyślnie nie buforuje dokumentów HTML. Samo podłączenie domeny nie daje więc gwarancji odpowiedzi strony z gotowej kopii. Potrzebna może być odpowiednia konfiguracja lub przeznaczone do tego rozwiązanie. Muszę przy tym zachować wyjątki dla treści prywatnych i dynamicznych. Cloudflare Cache (CDN) docs

W odpowiedziach Cloudflare sprawdzam nagłówek CF-Cache-Status. Wartość HIT oznacza odpowiedź z cache, a MISS brak pasującej kopii podczas danego żądania. Inne wartości mogą wskazywać odmienne zachowanie. Interpretuję je zgodnie z dokumentacją usługi. Jeśli dokument za każdym razem trafia do aplikacji, szukam przyczyny, zamiast zakładać, że CDN już rozwiązał problem. Cloudflare Cache (CDN) docs

Sprawdzam kod, bazę danych i połączenia z innymi usługami

Na WordPressie nie oceniam obciążenia wyłącznie po liczbie wtyczek. Jeden dodatek wykonujący kosztowne operacje może powodować większe opóźnienie niż kilka prostych rozszerzeń. Patrzę na faktyczny czas pracy i sposób pobierania danych. Do analizy zapytań może pomóc Query Monitor, który pokazuje między innymi powiązanie zapytań z komponentami strony. Query Monitor

Osobno sprawdzam połączenia wykonywane przez serwer do zewnętrznych usług. Jeśli strona czeka na ich odpowiedź przed wysłaniem HTML, opóźnienie może zwiększać TTFB. Nie mylę tego ze skryptem uruchamianym dopiero w przeglądarce. Reklama lub czat doładowywane po otrzymaniu dokumentu mogą spowalniać dalsze działanie, ale zwykle nie opóźniają jego pierwszego bajtu.

Przy bazie danych szukam konkretnych wolnych zapytań, zamiast zaczynać od przypadkowego usuwania rekordów. Porządki wykonuję z kopią bezpieczeństwa i znajomością przeznaczenia danych. Zmiany testuję poza działającym sklepem. Wyłączenie potrzebnej integracji na stronie produkcyjnej może wprawdzie poprawić wynik, ale jednocześnie zatrzymać ważny proces biznesowy.

Kiedy sprawdzam hosting i przekierowania?

Hosting analizuję szczególnie wtedy, gdy witryna zwalnia pod obciążeniem albo osiąga limity przydzielonych zasobów. Proszę administratora o sprawdzenie procesora, pamięci i kolejek żądań. Pytam również o czas wykonywania aplikacji. Sama informacja o szybkim dysku nie opisuje całego środowiska. Nie zakładam też, że zmiana dostawcy naprawi nieefektywny kod. Developer.WordPress.org

Przed migracją chciałbym zobaczyć porównanie tej samej strony na docelowym środowisku. Zachowuję podobną konfigurację i warunki pomiaru. W przeciwnym razie mogę przypisać hostingowi poprawę wynikającą jedynie z włączonego cache. Dobieram również lokalizację serwera do odbiorców i planowanego sposobu dostarczania treści.

Sprawdzam przy okazji, czy adres nie prowadzi przez zbędny łańcuch przekierowań. Odnośniki wewnętrzne powinny wskazywać od razu właściwy adres docelowy. Zachowuję potrzebne przekierowania dla starych linków oraz poprawnego działania HTTPS. Skracam niepotrzebną drogę, zamiast usuwać mechanizmy, które pełnią ważną funkcję. web.dev

Czy poprawa TTFB wystarczy, żeby strona była szybka i lepiej widoczna?

TTFB nie należy do Core Web Vitals. W tej grupie znajdują się LCP, INP oraz CLS. Opisują odpowiednio wyświetlenie największego elementu treści, reakcję na interakcje i stabilność układu. Wysokie TTFB może opóźniać wyświetlanie zawartości, dlatego ma znaczenie diagnostyczne. Nie traktuję go jednak jako samodzielnej oceny jakości strony ani gwarancji pozycji w Google. developers.google.com

Jeżeli odpowiedź przychodzi szybko, a główny obraz pojawia się późno, szukam przyczyn na dalszych etapach. Wtedy istotne mogą być wielkość pliku, sposób jego ładowania i zasoby blokujące wyświetlanie. Kompresja zdjęć zwykle nie usuwa oczekiwania na wygenerowanie głównego dokumentu. To osobne zadania, choć oba wpływają na odczuwalną szybkość.

Po zmianach wracam więc do całej ścieżki użytkownika. Sprawdzam czytelność, działanie przycisków i przebieg zakupów. Interesuje mnie użyteczna strona, a nie wyłącznie niższa liczba przy jednym parametrze. Wyniki wyszukiwania zależą również od wielu innych czynników, w tym przydatności treści.

Od czego zacząłbym skracanie TTFB na Twojej stronie?

Najpierw zapisałbym wyniki kilku ważnych adresów w porównywalnych warunkach. Oddzieliłbym odwiedziny anonimowe od zalogowanych i sprawdził działanie cache. Następnie ustaliłbym, czy opóźnienie powstaje podczas połączenia, czy przede wszystkim przy przygotowywaniu odpowiedzi. Dopiero na tej podstawie wybrałbym zmianę do wdrożenia. Nie zaczynałbym od kupowania mocniejszego serwera ani instalowania kolejnej wtyczki.

Po każdej istotnej zmianie powtórzyłbym pomiary i sprawdził działanie strony. Zachowałbym też informacje o konfiguracji, żeby móc wyjaśnić uzyskany rezultat. Jeśli problem pojawia się tylko okresowo, dołączyłbym obserwację obciążenia w dłuższym czasie. Takie podejście pozwala przejść od ogólnego „strona wolno działa” do konkretnego zadania. A wtedy znacznie łatwiej ocenić, za co warto zapłacić i czy wykonana praca rzeczywiście pomogła.