Jaki TTFB jest dobry?

Dokumentacja Google o budżecie nie podaje progu w milisekundach. Mówi, że limit wydajności rośnie, gdy czasy odpowiedzi są stabilne albo się poprawiają, i spada, gdy rosną. Porównuj więc własne wyniki w czasie, a nie z arbitralną liczbą.

Czy TTFB to to samo co czas odpowiedzi serwera?

Nie całkiem. Czas odpowiedzi serwera to czas generowania strony po stronie serwera. TTFB dodaje do tego DNS, nawiązanie połączenia i TLS, więc jest zawsze równy albo większy.

Czy wolny TTFB usuwa strony z indeksu?

Nie bezpośrednio. Skutkiem jest mniej żądań robota, bo według dokumentacji Google obniża limit wydajności przy rosnących czasach odpowiedzi. Mniej żądań oznacza wolniejsze odkrywanie i odświeżanie stron.

Dlaczego TTFB w narzędziach jest inny niż w curl?

Bo mierzą z różnych miejsc i w różnym momencie. Lokalizacja, cache CDN, rozgrzany serwer i pora dnia zmieniają wynik. Mierz kilka razy, z tej samej lokalizacji, i porównuj medianę.

Czy CDN zawsze poprawia TTFB?

Dla treści z pamięci podręcznej CDN tak, bo odpowiedź idzie z bliskiego serwera brzegowego. Dla stron generowanych dynamicznie, których CDN nie buforuje, dochodzi dodatkowy skok, więc TTFB może nawet wzrosnąć.

Co IndexRise zapisuje jako czas odpowiedzi?

Czas od wysłania żądania do otrzymania odpowiedzi dla każdego monitorowanego adresu, mierzony co noc z tego samego miejsca. Służy do porównań noc do nocy: ostrzeżenie pojawia się, gdy czas wzrośnie trzykrotnie względem mediany ostatnich pomiarów.

TTFB (czas do pierwszego bajtu)

TTFB, czyli czas do pierwszego bajtu, to czas od wysłania żądania do chwili, gdy przeglądarka albo robot dostaje pierwszy bajt odpowiedzi. Obejmuje DNS, nawiązanie połączenia, negocjację TLS i czas, w którym serwer generuje stronę. Google w przewodniku o budżecie indeksowania wymienia czas do pierwszego bajtu wśród sygnałów, od których zależy, ile połączeń robot może utrzymać z Twoim serwerem.

TTFB to czas od wysłania żądania do pierwszego bajtu odpowiedzi serwera. Składa się z DNS, połączenia, TLS i czasu generowania strony. Google wymienia czas do pierwszego bajtu wśród sygnałów, które podnoszą albo obniżają limit skanowania witryny.

Jak wygląda

Pomiar z linii poleceń rozbity na etapy:

curl -s -o /dev/null -w "dns: %{time_namelookup}\nconnect: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n" https://example.com/

Przykładowy wynik dla strony generowanej bez pamięci podręcznej:

dns: 0.021

connect: 0.045

tls: 0.098

ttfb: 1.412

total: 1.530

Różnica między tls a ttfb to czas, który serwer spędził na wygenerowaniu odpowiedzi. Tu to ponad sekunda, czyli problem leży w aplikacji albo bazie, nie w sieci.

Jak traktuje to Google

Przewodnik o budżecie (optymalizacja budżetu indeksowania) opisuje limit wydajności indeksowania jako łączny czas, przez jaki serwer utrzymuje otwarte połączenia z Google. Według tego dokumentu, jeśli witryna reaguje spójnie, a czasy odpowiedzi, w tym opóźnienie i czas do pierwszego bajtu, pozostają stabilne lub się poprawiają, limit rośnie i robot może używać więcej połączeń. Jeśli czas reakcji się wydłuża albo pojawiają się błędy 5xx, na przykład błąd 503, i sygnały ograniczania, limit spada i Google skanuje mniej.

Ten sam dokument wśród sprawdzonych metod wymienia szybkie wczytywanie stron: gdy wczytywanie i renderowanie odbywa się szybciej, Google może odczytać z witryny więcej treści. Zaleca optymalizację czasu odpowiedzi serwera i obsługę kodu 304 (Not Modified), który pozwala Google ponownie użyć wersji z pamięci podręcznej i oszczędza zasoby serwera. Jak to przekłada się na skanowanie, opisuje hasło o crawl budget.

W Search Console czas odpowiedzi widać w raporcie Statystyki indeksowania. Według dokumentacji (raport Statystyki indeksowania) „Średni czas odpowiedzi” to średnia dla wszystkich zasobów pobranych z witryny w danym okresie, gdzie każdy zasób, do którego strona linkuje, liczy się jako osobna odpowiedź. To nie jest TTFB jednej strony, ale wykres pokazuje ten sam trend: wzrost po wdrożeniu albo w godzinach szczytu.

Google nie publikuje progu w milisekundach, po którego przekroczeniu robot zwalnia. Każda liczba, którą zobaczysz w poradnikach, jest założeniem autora, nie dokumentacją.

Typowe przyczyny wolnego TTFB

hosting współdzielony z limitem procesów i wolnym dyskiem,
brak pamięci podręcznej stron, przez co każde żądanie uruchamia pełne generowanie w PHP i bazie,
wolne zapytania do bazy danych, zwłaszcza na listingach z filtrami i sortowaniem,
wtyczki wykonujące zapytania zewnętrzne przy każdym żądaniu,
brak CDN albo CDN, który nie buforuje stron, tylko dodaje skok,
wolny DNS albo brak keep-alive, co wydłuża połączenie przy każdym żądaniu,
przekierowania przed stroną docelową, bo każdy skok to osobne żądanie z własnym TTFB.

Ostatni punkt często umyka. Łańcuch z HTTP na HTTPS i z wersji bez www na www podwaja albo potraja czas do pierwszego bajtu z perspektywy robota.

Najczęstsze błędy

Błąd	Skutek
Pomiar jednorazowy z rozgrzanej pamięci podręcznej	Wynik nie pokazuje, co dostaje robot przy pierwszym żądaniu
Porównywanie TTFB z arbitralnym progiem	Decyzje oparte na liczbie, której Google nie podaje
Optymalizacja front-endu przy wolnym serwerze	Skrypty i obrazy ładują się szybciej, ale pierwszy bajt dalej czeka
Cache tylko dla zalogowanych albo tylko dla przeglądarek	Robot dostaje wersję bez pamięci podręcznej
Przekierowania liczone osobno od TTFB strony	Realny czas robota jest sumą wszystkich skoków
Wolny TTFB w nocy ignorowany, bo „użytkownicy wtedy nie wchodzą”	Robot skanuje także w nocy, często właśnie wtedy

Jak sprawdzić

Polecenie z sekcji wyżej uruchom kilka razy i zapisz medianę. Dodaj -H "Cache-Control: no-cache", żeby zobaczyć czas bez pamięci podręcznej, i porównaj z żądaniem zwykłym. Dla łańcucha przekierowań dodaj -L i mierz time_total, bo pojedyncze time_starttransfer pokaże tylko pierwszy skok.

W przeglądarce otwórz narzędzia deweloperskie, zakładkę Sieć, i kliknij pierwsze żądanie dokumentu. Zakładka Czas pokazuje etapy: oczekiwanie na odpowiedź serwera to TTFB. Pomiar z przeglądarki uwzględnia Twoją lokalizację i połączenie, więc różni się od pomiaru z serwera.

W Search Console sprawdź raport Statystyki indeksowania: wykres średniego czasu odpowiedzi obok liczby żądań. Jeśli czas rośnie, a żądania spadają, limit wydajności właśnie się obniża. Skutek uboczny zobaczysz w raporcie Indeksowanie stron jako przyrost statusu Strona wykryta, obecnie niezindeksowana.

Czy przed stroną są przekierowania, pokaże sprawdzarka przekierowań z kodem każdego kroku. Znaczenie kodów, w tym 304 i 503, opisuje hasło o kodach odpowiedzi HTTP.

Monitorowanie

IndexRise co noc zapisuje czas odpowiedzi każdego monitorowanego adresu, mierzony z tego samego miejsca i o podobnej porze, razem z kodem odpowiedzi. Nie ocenia go względem stałej liczby milisekund, bo Google takiego progu nie podaje. Porównuje go z medianą ostatnich nocy i ostrzega, gdy czas wzrośnie trzykrotnie (mnożnik zmienisz w progach projektu), więc skok po wdrożeniu nowej wtyczki, po zmianie hostingu albo po wyłączeniu pamięci podręcznej widać jako zmianę, a nie jako pojedynczą liczbę bez kontekstu.

TTFB nie ma jednej dobrej wartości. Ma trend. Jeśli od wczoraj czas wzrósł kilkukrotnie, coś się zmieniło na serwerze i warto wiedzieć co, zanim zauważy to Googlebot.