Czas do pierwszego bajtu (TTFB)

TL;DR — Time to First Byte to czas, jaki przeglądarka czeka, po wysłaniu zapytania o stronę, zanim pierwszy bajt odpowiedzi wróci. To miara responsywności serwera. Dobry TTFB to 0,8 sekundy lub mniej. Nie jest to Core Web Vital — ale wolny TTFB obniża metryki, które nim są, bo nic na stronie nie może się rozpocząć, dopóki nie pojawi się pierwszy bajt.

Czym jest TTFB

Kiedy klikasz link, Twoja przeglądarka wysyła zapytanie do serwera i czeka. Time to First Byte (TTFB) to długość tego oczekiwania — od momentu rozpoczęcia zapytania do momentu, gdy pierwszy bajt odpowiedzi zaczyna docierać.

To nie jest tylko „jak szybko myśli serwer”. Dużo dzieje się zanim Twoja przeglądarka w ogóle porozmawia z właściwą maszyną: może nastąpić przekierowanie, wyszukanie domeny w DNS, otwarcie połączenia i negocjacja bezpiecznego (TLS) uzgadniania. TTFB obejmuje to wszystko razem, a następnie dodaje czas przetwarzania serwera i zatrzymuje stoper przy pierwszym bajcie odpowiedzi.

Co uznaje się za dobry wynik

Wytyczne Google web.dev są proste: celuj w TTFB na poziomie 0,8 sekundy lub mniej. Powyżej 1,8 sekundy uznaje się za słaby wynik. Większość witryn powinna być w stanie osiągnąć dobry wynik — a wiele nie osiąga, co jest właśnie powodem, dla którego warto to sprawdzić.

Dlaczego to ma znaczenie, mimo że nie jest to metryka „core”

Usłyszysz dużo o Core Web Vitals — LCP, INP i CLS. TTFB nie jest jedną z nich. Ale leży pod tymi dotyczącymi ładowania: zarówno First Contentful Paint, jak i Largest Contentful Paint uwzględniają TTFB w swoim pomiarze. Przeglądarka nie może nic wyrenderować, dopóki bajty nie zaczną docierać. Więc wolny TTFB nakłada sufit na to, jak szybka może się wydawać Twoja strona.

Praktyczny wniosek: TTFB sam w sobie nie wpływa na pozycję w rankingu, ale zły wynik cicho hamuje metryki, które na to wpływają.

Typowe rozwiązania, w prostych słowach

• Użyj CDN. Umieszcza kopię Twojej witryny na serwerach fizycznie bliżej Twoich odwiedzających, więc czas podróży w obie strony jest krótszy.
• Cache’uj swoje strony. Jeśli serwer może zwrócić gotową kopię zamiast odbudowywać stronę za każdym razem, pierwszy bajt pojawia się znacznie szybciej.
• Zainwestuj w lepszy hosting. Szybszy serwer i baza danych to najbardziej bezpośrednie rozwiązanie.
• Ogranicz przekierowania. Każde przekierowanie to dodatkowa podróż w obie strony, zanim właściwa strona w ogóle zacznie się ładować.

Chcesz pełną wersję — dokładne progi, związek z LCP, zamieszanie z progami Lighthouse vs. CrUX, Early Hints i sposób pomiaru? Przełącz się na zakładkę Advanced.

TL;DR — TTFB to czas od rozpoczęcia zapytania do momentu, gdy pierwszy bajt odpowiedzi dociera — suma czasu przekierowania, uruchomienia service workera, wyszukiwania DNS, negocjacji połączenia + TLS oraz samego zapytania, aż do tego pierwszego bajtu. Nie jest to Core Web Vital; to podstawowa, diagnostyczna metryka, która zasila FCP i LCP. web.dev: dobry wynik to ≤0,8 s, słaby to >1,8 s (75. percentyl). Jest to zarówno metryka terenowa, jak i laboratoryjna. Audyt Lighthouse „Reduce server response times” jest węższy — wskazuje czas serwera powyżej ~600 ms, a nie pełny TTFB, a od Lighthouse 13 znajduje się w ramach wglądu „Document request latency”. Rozwiąż to za pomocą CDN, cache’owania brzegowego/HTML, szybszego hostingu, mniejszej liczby przekierowań, 103 Early Hints i wydajnego TLS. A wysoki TTFB nie zawsze oznacza wolną witrynę.

Co dokładnie mierzy TTFB

TTFB mierzy czas między rozpoczęciem nawigacji do strony a momentem, gdy pierwszy bajt odpowiedzi zaczyna docierać. Rzeczą, którą ludzie mylą, jest traktowanie go jako czystego czasu przetwarzania backendu. Tak nie jest. To suma wszystkiego, co musi się zakończyć, zanim ten pierwszy bajt może wrócić:

1. Czas przekierowania
2. Czas uruchomienia service workera (jeśli ma zastosowanie)
3. Wyszukiwanie DNS
4. Negocjacja połączenia i TLS
5. Zapytanie — aż do momentu, gdy pierwszy bajt odpowiedzi dotrze

Przetwarzanie po stronie serwera jest tam, ale także cały narzut związany z konfiguracją połączenia. To rozróżnienie ma znaczenie, gdy tylko zaczniesz czytać narzędzia, ponieważ nie wszystkie mierzą ten sam wycinek (więcej o tym poniżej).

To nie jest Core Web Vital

Powiem to wprost, bo to najczęstsze nieporozumienie: TTFB nie jest Core Web Vital. Trzy Core Web Vitals to LCP (ładowanie), INP (interaktywność) i CLS (stabilność wizualna). TTFB to podstawowa, diagnostyczna metryka — według Google jest to “podstawowa metryka do mierzenia czasu konfiguracji połączenia i responsywności serwera zarówno w laboratorium, jak i w terenie.”

Google wyraźnie stwierdza również, że nie musisz ściśle osiągać dobrego progu TTFB: ponieważ nie jest to Core Web Vital, “nie jest absolutnie konieczne, aby witryny spełniały próg ‘dobrego’ TTFB, pod warunkiem że nie utrudnia to ich zdolności do osiągania dobrych wyników w metrykach, które mają znaczenie.” Ten ostatni fragment jest kluczowy — dla większości witryn zły TTFB zdecydowanie utrudnia osiąganie metryk, które mają znaczenie.

Jak ogranicza FCP i LCP

TTFB poprzedza każdą metrykę ładowania skoncentrowaną na użytkowniku. Zarówno First Contentful Paint, jak i Largest Contentful Paint zawierają TTFB w swoim pomiarze — zegar dla tych metryk już działa, gdy czekasz na pierwszy bajt. web.dev dzieli LCP na podczęści, a TTFB jest pierwszą z nich, dlatego nie możesz mieć szybkiego LCP opartego na wolnym TTFB.

To również miejsce, gdzie wskazują dane ze świata rzeczywistego. Web Almanac z HTTP Archive wykazał, że na stronach ze słabym LCP sam TTFB pochłaniał około 2,27 sekundy — prawie cały budżet 2,5 sekundy na “dobre LCP” — zanim jakikolwiek obraz lub tekst zaczął się renderować. Jeśli Twoje LCP jest złe, a treść na stronie wygląda na zoptymalizowaną, TTFB to pierwsze miejsce, na które bym spojrzał.

Więc historia z rankingiem jest pośrednia, ale realna: TTFB nie jest sygnałem rankingowym Google (sygnały rankingowe to LCP, INP i CLS — TTFB nie jest w tym zestawie wymieniony). Ale jest wbudowany w LCP, które jest sygnałem rankingowym. Ścieżka prowadzi przez LCP, a nie bezpośrednio przez TTFB.

Progi: dobry, wymaga poprawy, słaby

Wytyczne web.dev, mierzone na 75. percentylu rzeczywistych obciążeń użytkowników:

• Dobry: ≤ 0,8 s
• Słaby: > 1,8 s

“Większość witryn powinna dążyć do TTFB wynoszącego 0,8 sekundy lub mniej.” Warto znać historię: Google przesunął linię “dobrego” z 500 ms na 800 ms w 2022 roku, a starsze dane zostały przeliczone według nowego standardu — więc nie porównuj surowych historycznych wartości TTFB bez sprawdzenia, którego progu użyto.

Zamieszanie 600 ms vs 800 ms

To myli wiele osób, więc warto być precyzyjnym. Istnieją dwie różne liczby, które się pojawiają:

• Próg TTFB w CrUX / web.dev: 800 ms. To próg terenowy dla pełnego TTFB (DNS + połączenie + TLS + przekierowania + czas serwera).
• Audyt Lighthouse “Zmniejsz czasy odpowiedzi serwera”: ~600 ms. To audyt laboratoryjny, który flaguje, gdy przeglądarka czeka ponad około 600 ms na odpowiedź serwera na żądanie głównego dokumentu. Co kluczowe, mierzy tylko czas odpowiedzi serwera — nie obejmuje DNS, konfiguracji połączenia ani TLS.

Więc liczba Lighthouse wygląda na bardziej rygorystyczną, ale mierzy węższy wycinek. Jak mówi dokumentacja, “czas odpowiedzi serwera to tylko część pełnego Time to First Byte (TTFB).” Nie traktuj pozytywnego audytu Lighthouse jako dowodu na dobry terenowy TTFB i nie panikuj, że 600 < 800 oznacza, że progi są ze sobą sprzeczne — mierzą różne rzeczy.

Jedna uwaga dotycząca wersji: od Lighthouse 13 ten audyt nie jest już samodzielny — został włączony do szerszego wglądu “Opóźnienie żądania dokumentu”. Podstawowa kontrola odpowiedzi serwera ~600 ms jest taka sama; jest tylko inaczej prezentowana w zależności od wersji Lighthouse, która wygenerowała Twój raport.

Teren i laboratorium — oba

TTFB to jedna z metryk, które możesz odczytać w obu światach. W polu pochodzi z CrUX (prawdziwi użytkownicy Chrome), widoczna w PageSpeed Insights i Search Console. W laboratorium Chrome DevTools oznacza ją jako „Waiting (TTFB)” w panelu Network („przeglądarka czeka na pierwszy bajt odpowiedzi”), a narzędzia takie jak WebPageTest i Lighthouse również ją raportują. Jedna uwaga dotycząca pola: w CrUX TTFB jest nadal traktowana jako nieco eksperymentalna — wyklucza niektóre zaawansowane typy nawigacji, takie jak prerenderowane i nawigacje z pamięci podręcznej wstecz/do przodu, więc średnie z pola mogą być odczytywane jako nieco pesymistyczne w porównaniu z tym, co użytkownicy faktycznie odczuwają.

Wysoki TTFB nie zawsze oznacza wolno działającą witrynę

Oto niuans, który kryje się za liczbami progów. Strona renderowana po stronie serwera może mieć wyższy TTFB niż strona renderowana po stronie klienta i nadal zapewniać lepsze FCP i LCP — ponieważ gdy w końcu nadejdzie pierwszy bajt, jest to kompletny HTML, który przeglądarka może natychmiast wyrenderować, a nie cienka powłoka, która musi najpierw pobrać i uruchomić pakiet JavaScript, zanim cokolwiek się pojawi. Google mówi to wprost: „a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience.” (tłumaczenie) „witryna renderowana po stronie serwera, która nie wymaga tak dużej pracy po stronie klienta, może mieć wyższy TTFB, ale lepsze wartości FCP i LCP niż doświadczenie w całości renderowane po stronie klienta.”

Odwrotna strona: w przypadku aplikacji jednostronicowej renderowanej po stronie klienta TTFB decyduje o tym, kiedy pakiet JavaScript w ogóle zacznie się ładować, więc niski TTFB ma tam większe znaczenie, a nie mniejsze. Nie optymalizuj TTFB w próżni — optymalizuj cały łańcuch ładowania i oceniaj TTFB na podstawie tego, co robi dla FCP i LCP.

Jak poprawić TTFB

Z grubsza w kolejności priorytetów:

• Zacznij od hostingu. Wolne backend lub zapytanie do bazy danych to podatek od każdego żądania i żadna praca po stronie frontendu go nie usunie. To pierwsza rzecz, którą należy wziąć pod uwagę.
• Użyj CDN. CDN rozwiązuje problem bliskości — rozproszona sieć serwerów brzegowych buforuje zasoby fizycznie bliżej Twoich użytkowników, skracając koszt prędkości światła połączenia i uzgadniania TLS. To naprawa o najwyższym ROI dla większości witryn, ponieważ odległość geograficzna od Twojego origin to strukturalny podatek, którego żaden backend nie wymaże. Zastrzeżenie: w przypadku w pełni dynamicznych, spersonalizowanych treści, których nie można buforować, CDN dodaje przeskok bez zysku z trafienia w pamięć podręczną — tam odpowiedzią jest optymalizacja backendu, przetwarzanie brzegowe lub strumieniowanie.
• Buforuj swój HTML, nawet na krótko. Nawet krótki czas buforowania pomaga ruchliwej witrynie zauważalnie: tylko pierwszy odwiedzający w tym oknie płaci pełne opóźnienie z powrotem do origin; wszyscy inni otrzymują skopiowaną wersję.
• Wyeliminuj przekierowania. Przekierowania są częstym czynnikiem wysokiego TTFB — każde z nich to podróż w obie strony, zanim zacznie się prawdziwa odpowiedź. Wytnij te, które masz pod kontrolą.
• Strumieniuj znaczniki do przeglądarki. Przeglądarki wydajnie przetwarzają znaczniki, gdy są strumieniowane w fragmentach w miarę ich docierania. Wiele frameworków SSR obsługuje strumieniowanie, ale jest ono wyłączone; włączenie go może obniżyć TTFB na dynamicznych stronach bez żadnych zmian w infrastrukturze.
• Użyj 103 Early Hints. Kod statusu 103 to wstępna odpowiedź, którą serwer może wysłać gdy backend wciąż przygotowuje znaczniki, sugerując przeglądarce wcześniejsze rozpoczęcie pobierania zasobów krytycznych dla renderowania. Nie obniża samego TTFB — w rzeczywistości 103 może liczyć się jako „pierwszy bajt” — ale zmniejsza wpływ wysokiego TTFB. Shopify i Cloudflare zgłosiły poprawę LCP o kilkaset milisekund dzięki temu, w niektórych przypadkach blisko sekundy.
• Negocjuj TLS efektywnie i optymalizuj uruchamianie service workera. Service worker, który jeszcze nie wystartował, dodaje swój czas uruchamiania do TTFB; gdy już działa, jego pamięć podręczna (stale-while-revalidate lub model app-shell dla SPA) może dramatycznie zmniejszyć TTFB.

Gdzie faktycznie stoją witryny

Powód, dla którego warto zwrócić na to uwagę: to uporczywy problem w całej sieci. Wskaźnik dobrego TTFB dla urządzeń mobilnych według Web Almanac ledwo się zmienił w ciągu pięciu lat – oscylując wokół 41–42 % – co oznacza, że większość mobilnych witryn nadal nie ma „dobrego” TTFB. Ta stagnacja jest, szczerze mówiąc, okazją. W przypadku witryny o dużym obciążeniu serwera, która nie zdaje LCP, TTFB jest zwykle poprawką o największym wpływie.

Ta strona jest częścią klastra web-performance, który znajduje się pod Core Web Vitals. Aby poznać metryki, na które wpływa TTFB, zobacz Largest Contentful Paint i First Contentful Paint; aby zmierzyć go na prawdziwych użytkownikach i w laboratorium, zobacz CrUX, PageSpeed Insights i Lighthouse.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• TTFB = czas oczekiwania na pierwszy bajt. Czas od rozpoczęcia żądania do momentu, gdy dotrze pierwszy bajt odpowiedzi – suma czasu przekierowań, uruchamiania service workera, wyszukiwania DNS, negocjacji połączenia + TLS oraz samego żądania. To nie tylko przetwarzanie po stronie serwera.
• To NIE jest Core Web Vital. Core Web Vitals to LCP, INP i CLS. TTFB to podstawowa, diagnostyczna metryka.
• Ogranicza FCP i LCP. Oba obejmują TTFB, więc wolny TTFB ustanawia górny limit tego, jak szybko strona może się załadować. Na stronach ze słabym LCP sam TTFB wynosił ~2,27 s – prawie cały budżet 2,5 s na dobry LCP.
• Rankingi: pośrednie. TTFB nie jest sygnałem rankingowym Google, ale jest wbudowany w LCP, który nim jest. Ścieżka prowadzi przez LCP.
• Progi (75. percentyl): dobry ≤ 0,8 s, słaby > 1,8 s. Linia „dobrego” przesunęła się z 500 ms do 800 ms w 2022 r.
• 600 ms vs 800 ms: audyt Lighthouse „Reduce server response times” oznacza ~600 ms tylko czasu serwera – węższy niż próg 800 ms dla pełnego TTFB. „Server response time is only part of the full TTFB.” Od Lighthouse 13 ten audyt znajduje się w ramach insightu „Document request latency”.
• Pole i laboratorium: CrUX/PSI/Search Console (pole); DevTools „Waiting (TTFB)”, WebPageTest, Lighthouse (laboratorium).
• Wysoki TTFB ≠ wolna witryna: strona SSR może mieć wyższy TTFB, ale lepsze FCP/LCP niż strona renderowana po stronie klienta, ponieważ pierwszy bajt to kompletny HTML.
• Poprawki (priorytet): hosting najpierw, potem CDN, buforowanie HTML, mniej przekierowań, strumieniowanie, 103 Early Hints, wydajny TLS, uruchamianie service workera.
• Stan sieci: dobry TTFB dla urządzeń mobilnych utrzymuje się na stałym poziomie ~41–42 % od pięciu lat – to prawdziwa okazja.

Oficjalna dokumentacja

Dokumentacja źródłowa od zespołów Google Chrome i web.dev.

• Time to First Byte (TTFB) — definicja, pięć komponentów, progi 0,8 s / 1,8 s, dlaczego to nie jest Core Web Vital oraz jego związek z FCP i LCP.
• Optimize TTFB — przewodnik optymalizacji: hosting najpierw, potem CDN, buforowanie, przekierowania, strumieniowanie, 103 Early Hints i service workery.
• Reduce server response times — audyt Lighthouse (próg ~600 ms czasu serwera) i czym różni się od pełnego TTFB. Od Lighthouse 13 jest włączony do insightu „Document request latency”.
• Web Vitals — gdzie TTFB znajduje się w taksonomii metryk: metryka uzupełniająca/diagnostyczna, z LCP, INP i CLS jako Core Web Vitals.
• Largest Contentful Paint (LCP) — potwierdza, że LCP obejmuje opóźnienia TTFB.
• First Contentful Paint (FCP) — potwierdza, że FCP obejmuje TTFB i wymienia „reduce server response times (TTFB)” jako poprawkę.
• Core Web Vitals (Google Search Central) — dokumenty dotyczące sygnałów rankingowych wymieniają tylko LCP, INP i CLS; TTFB nie jest wymieniony.
• 103 Early Hints — wczesny kod odpowiedzi, wsparcie przeglądarek/serwerów i wyniki z rzeczywistego świata.

Cytaty ze źródła

Oświadczenia na piśmie od zespołów web.dev i Chrome w Google. Każdy link to link bezpośredni, który przeskakuje do cytowanego fragmentu na stronie źródłowej, gdzie został zweryfikowany.

web.dev — czym jest TTFB

• “TTFB is a metric that measures the time between starting navigating to a page and when the first byte of a response begins to arrive.” (tłumaczenie) „TTFB to metryka mierząca czas między rozpoczęciem nawigacji do strony a momentem, w którym pierwszy bajt odpowiedzi zaczyna docierać.” Przejdź do cytatu
• “Time to First Byte (TTFB) is a foundational metric for measuring connection setup time and web server responsiveness in both the lab and the field.” (tłumaczenie) „Czas do pierwszego bajtu (TTFB) to podstawowa metryka do pomiaru czasu nawiązywania połączenia i responsywności serwera WWW zarówno w laboratorium, jak i w terenie.” Przejdź do cytatu

web.dev — progi

• “Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.” (tłumaczenie) „Dobre wartości TTFB to 0,8 sekundy lub mniej, a słabe wartości to ponad 1,8 sekundy.” Przejdź do cytatu

web.dev — nie jest to Core Web Vital

• “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold, provided that it doesn’t impede their ability to score well on the metrics that matter.” (tłumaczenie) „Ponieważ TTFB nie jest metryką Core Web Vitals, nie jest absolutnie konieczne, aby witryny spełniały próg „dobry” TTFB, pod warunkiem że nie utrudnia im to osiągania dobrych wyników w metrykach, które mają znaczenie.” Przejdź do cytatu

web.dev — związek z FCP i LCP

• “Because TTFB precedes user-centric metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP)…” (tłumaczenie) „Ponieważ TTFB poprzedza metryki skoncentrowane na użytkowniku, takie jak First Contentful Paint (FCP) i Largest Contentful Paint (LCP)…” Przejdź do cytatu
• Na stronie renderowanej po stronie serwera: “a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience.” (tłumaczenie) „witryna renderowana po stronie serwera, która nie wymaga tak dużej pracy po stronie klienta, może mieć wyższy TTFB, ale lepsze wartości FCP i LCP niż doświadczenie w całości renderowane po stronie klienta.” (web.dev, „Time to First Byte”)

Lighthouse — czas odpowiedzi serwera a pełny TTFB

• “Server response time is only part of the full Time to First Byte (TTFB).” (tłumaczenie) „Czas odpowiedzi serwera to tylko część pełnego czasu do pierwszego bajtu (TTFB).” (Lighthouse, „Reduce server response times.”)

Patrick Stox — o statusie TTFB (z mojego przewodnika po Core Web Vitals w Ahrefs)

• “There are additional Web Vitals that serve as proxy measures or supplemental metrics but are not used in the ranking calculations. The Web Vitals metrics for visual load include Time to First Byte (TTFB) and First Contentful Paint (FCP).” (tłumaczenie) „Istnieją dodatkowe Web Vitals, które służą jako miary zastępcze lub metryki uzupełniające, ale nie są używane w obliczeniach rankingowych. Metryki Web Vitals dla wizualnego ładowania obejmują Time to First Byte (TTFB) i First Contentful Paint (FCP).” Przeczytaj przewodnik

Lista kontrolna triage TTFB

Gdy PageSpeed Insights, Search Console lub Lighthouse zgłasza wolny czas odpowiedzi serwera, przejdź przez tę listę:

• Potwierdź, na co patrzysz — pełny TTFB z pola (≤0,8 s dobry) czy audyt Lighthouse „Reduce server response times” (~600 ms, tylko czas serwera). To nie są te same liczby.
• Sprawdź pole, nie tylko laboratorium — pobierz TTFB z CrUX przez PageSpeed Insights lub raport Core Web Vitals w Search Console, na 75. percentylu.
• Sprawdź, czy TTFB ogranicza Twój LCP — jeśli LCP jest słabe, a treść strony jest zoptymalizowana, TTFB jest pierwszym podejrzanym.
• Policz przekierowania — wyeliminuj łańcuchy przekierowań, które kontrolujesz, na kluczowych adresach wejściowych.
• Potwierdź, że CDN obsługuje Twoich użytkowników (punkty PoP blisko odbiorców) i że buforowanie HTML/edge faktycznie działa, nie tylko w przypadku zasobów statycznych.
• Zprofiliuj backend — wolne zapytania do bazy danych lub ciężka praca po stronie serwera przy głównym żądaniu dokumentu.
• Zweryfikuj, że TLS jest wydajny (nowoczesny protokół, wznawianie sesji), a DNS jest szybki.
• Jeśli strona jest dynamicznym SSR, sprawdź, czy streaming jest włączony w Twoim frameworku — często jest domyślnie wyłączony.
• Rozważ 103 Early Hints dla zasobów krytycznych dla renderowania, jeśli Twój serwer/CDN to obsługuje.
• Jeśli używasz service workera, sprawdź, czy jego uruchamianie nie wydłuża TTFB przy pierwszym ładowaniu i czy strategia buforowania pomaga przy kolejnych ładowaniach.

Ściągawka TTFB

Z czego składa się TTFB

1. Czas przekierowania
2. Uruchamianie service workera (jeśli jest)
3. Wyszukiwanie DNS
4. Nawiązywanie połączenia + negocjacja TLS
5. Żądanie — do pierwszego bajtu odpowiedzi

Progi (75. percentyl rzeczywistych ładowań użytkowników)

Dwa progi, dwa zakresy

Szybkie fakty

• TTFB nie jest Core Web Vital. Core Web Vitals to LCP, INP, CLS.
• To metryka zarówno polowa, jak i laboratoryjna.
• Zarówno FCP, jak i LCP obejmują TTFB — wyznacza on ich górną granicę.
• Wpływ na ranking jest pośredni, poprzez LCP — sam TTFB nie jest sygnałem rankingowym.
• DevTools oznacza go jako „Waiting (TTFB)” w panelu Network.
• Granica „dobrego” przesunęła się z 500 ms → 800 ms w 2022 roku.

Priorytet napraw: hosting → CDN → buforowanie HTML/edge → ograniczenie przekierowań → streaming znaczników → 103 Early Hints → wydajny TLS → uruchamianie service workera.

Narzędzia do pomiaru TTFB

• PageSpeed Insights — najłatwiejszy odczyt z pola: pokazuje Twój TTFB z CrUX (rzeczywistych użytkowników Chrome) wraz z przebiegiem laboratoryjnym, dla adresu URL lub origin.
• Search Console — raport Core Web Vitals — dane z pola pogrupowane według wzorca URL; miejsce do wykrywania problemów z TTFB na dużą skalę.
• CrUX (Chrome User Experience Report) — bazowy zbiór danych z pola; można go odpytywać bezpośrednio przez API CrUX lub BigQuery w celu analizy trendów historycznych.
• Chrome DevTools — panel Network — najedź na główne żądanie dokumentu i odczytaj czas „Waiting (TTFB)”, aby uzyskać precyzyjny podział laboratoryjny na czas połączenia i czas serwera.
• Lighthouse — uruchamia audyt „Reduce server response times” (~600 ms flaga czasu serwera); wbudowany w DevTools i PageSpeed Insights. Od Lighthouse 13 ta kontrola pojawia się w ramach insightu „Document request latency”.
• WebPageTest — szczegółowe wodospady z TTFB rozbitym na fazy połączenia oraz testowanie wielu lokalizacji/połączeń w celu wyizolowania opóźnień geograficznych.
• Biblioteka JS web-vitals — zbieraj TTFB (i resztę) od własnych rzeczywistych użytkowników w polu i wysyłaj do swojej analityki.

Błędy TTFB prowadzące do złej naprawy

Nazywanie każdego opóźnienia problemem serwera

TTFB obejmuje przekierowania, DNS, nawiązywanie połączenia, TLS, uruchamianie service workera i przetwarzanie po stronie serwera. Rozbij żądanie na fazy, zanim zmienisz kod aplikacji lub hosting.

Porównywanie audytu Lighthouse 600 ms z progiem polowym 800 ms

Audyt Lighthouse to węższa diagnostyka laboratoryjna, natomiast wytyczna 0,8 sekundy opisuje pełny TTFB. Podaj źródło i zakres, gdy raportujesz którąkolwiek z tych wartości.

Testowanie tylko z lokalizacji blisko origin

Laboratorium w pobliżu może ukryć opóźnienia geograficzne. Porównaj regiony lub użyj danych od prawdziwych użytkowników, zanim założysz, że to samo doświadczenie dotyczy całej grupy odbiorców.

Ściganie TTFB, gdy strona jest już szybka

Wysoki TTFB może współistnieć z szybkim strumieniowanym lub buforowanym doświadczeniem. Sprawdź, czy faktycznie ogranicza FCP lub LCP, zanim uznasz go za większy problem niż inne wąskie gardło.

Diagnozuj wolny TTFB według objawów

Pierwsze żądanie jest wolne, ale powtórne są szybkie

Prawdopodobna przyczyna: zimne pamięci podręczne, nawiązywanie połączenia lub rozgrzewanie aplikacji. Naprawa: sprawdź nagłówki pamięci podręcznej i oddziel testy zimne od ciepłych. Potwierdzenie: waterfall pokazuje, która faza połączenia lub serwera znika przy powtórnym żądaniu.

TTFB jest wolny tylko w odległych regionach

Prawdopodobna przyczyna: fizyczna odległość do origin lub brak trafienia w pamięci podręcznej CDN. Naprawa: serwuj buforowalny HTML bliżej użytkowników i zweryfikuj zachowanie pamięci podręcznej na brzegu sieci. Potwierdzenie: testy regionalne pokazują krótszy czas oczekiwania bez zmiany treści odpowiedzi.

URL ma znacznie gorszy TTFB niż podobne szablony

Prawdopodobna przyczyna: przekierowania, niebuforowana ścieżka lub kosztowna praca backendu specyficzna dla strony. Naprawa: porównaj łańcuch przekierowań, status pamięci podręcznej i czasy serwera ze zdrowym odpowiednikiem. Potwierdzenie: żądanie dokumentu dla odstającego adresu wraca do poziomu bazowego szablonu.

DevTools i CrUX się różnią

Prawdopodobna przyczyna: jedno żądanie laboratoryjne nie może reprezentować urządzeń, lokalizacji, stanów pamięci podręcznej i 75. percentyla z danych terenowych. Naprawa: użyj żądania laboratoryjnego do diagnozy, a danych terenowych do oceny skali problemu. Potwierdzenie: Twój rozkład RUM wyjaśnia, który segment generuje wolniejszą wartość zagregowaną.

Zmierz TTFB z wiersza poleceń

Użyj zmiennych czasowych curl, aby oddzielić pierwszy bajt od DNS, połączenia i konfiguracji TLS.

curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s starttransfer=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/

time_starttransfer to pomiar w stylu TTFB w tym poleceniu. Wykonaj kilka zimnych i ciepłych żądań z więcej niż jednego istotnego regionu; pojedyncza lokalna próbka nie jest benchmarkiem terenowym.

Czytaj Navigation Timing w przeglądarce

const nav = performance.getEntriesByType('navigation')[0];
console.table({
  ttfb: Math.round(nav.responseStart - nav.requestStart),
  dns: Math.round(nav.domainLookupEnd - nav.domainLookupStart),
  connect: Math.round(nav.connectEnd - nav.connectStart),
});

Udowodnij, że zmiana TTFB przyniosła efekt

Test pamięci podręcznej na brzegu sieci

Test do wykonania: wyślij to samo żądanie dokumentu dwa razy za pomocą curl -sS -D - -o /dev/null, a następnie sprawdź nagłówki cache-status i age CDN. Oczekiwany wynik: powtórne żądanie jest obsługiwane z pamięci podręcznej zgodnie z udokumentowanym nagłówkiem CDN. Interpretacja błędu: ścieżka omija pamięć podręczną lub natychmiast ją wygasza. Okno monitorowania: natychmiastowe. Wyzwalacz wycofania: spersonalizowany, uwierzytelniony lub nieaktualny HTML jest serwowany do niewłaściwego żądania.

Test usunięcia przekierowania

Test do wykonania: użyj curl -sS -I na finalnym publicznym URL i sprawdź osobno łańcuch przekierowań. Oczekiwany wynik: zamierzony adres wejściowy dociera do dokumentu bez zbędnego przeskoku. Interpretacja błędu: reguły routingu lub kanonicznego hosta nadal dodają dodatkową rundę. Okno monitorowania: natychmiastowe. Wyzwalacz wycofania: zmiana łamie wymaganą normalizację HTTP-to-HTTPS lub nazwy hosta.

Test TTFB w terenie

Test do wykonania: porównaj po wydaniu Navigation Timing lub TTFB z web-vitals według regionu i szablonu z bazą przed wydaniem. Oczekiwany wynik: p75 poprawia się w dotkniętych segmentach bez wzrostu liczby błędów. Interpretacja błędu: zysk laboratoryjny nie dotarł do prawdziwych użytkowników lub przeniósł pracę gdzie indziej. Okno monitorowania: w miarę napływu ruchu RUM; CrUX w swoim ruchomym oknie. Wyzwalacz wycofania: wskaźnik błędów, poprawność pamięci podręcznej lub widoczne dla użytkownika opóźnienie pogarszają się.

Metryki TTFB, które warto śledzić

TTFB prawdziwych użytkowników na poziomie p75

Metryka: 75. percentyl TTFB według szablonu, regionu i klasy urządzenia. Co Ci mówi: jak długo opóźnienie żądania dokumentu wpływa na większość rzeczywistych wizyt, zanim rozpocznie się renderowanie. Jak to pobrać: Navigation Timing, biblioteka web-vitals, CrUX lub PageSpeed Insights. Benchmark / realistyczny zakres: 0,8 sekundy lub mniej to dobry cel opisany w tym artykule; interpretuj segmenty osobno. Częstotliwość: co tydzień w RUM i co miesiąc dla trendu publicznego.

TTFB przy trafieniu w pamięć podręczną a TTFB przy braku trafienia

Metryka: p75 TTFB podzielone według wyniku pamięci podręcznej CDN. Co Ci mówi: czy opóźnienie wynika z pracy originu, czy z dostarczania na brzegu sieci. Jak to pobrać: połącz nagłówki statusu pamięci podręcznej odpowiedzi z RUM lub logami CDN. Benchmark / realistyczny zakres: użyj własnej regionalnej linii bazowej witryny, ponieważ dostawca, trasa i personalizacja się różnią. Częstotliwość: co tydzień i po zmianach reguł pamięci podręcznej.

Udział TTFB w LCP

Metryka: TTFB podzielone przez czas trwania LCP dla tej samej wizyty. Co Ci mówi: czy czas serwera i połączenia jest ograniczającą częścią doświadczenia ładowania. Jak to pobrać: zbieraj TTFB i LCP razem w RUM. Benchmark / realistyczny zakres: żaden uniwersalny procent nie jest uczciwy; priorytetyzuj TTFB, gdy konsekwentnie pochłania dużą część LCP. Częstotliwość: co miesiąc według szablonu.

Zasoby warte Twojego czasu

Moje powiązane artykuły

• Core Web Vitals: A Beginner’s Guide — gdzie TTFB wpisuje się w metryki ładowania i dlaczego jest metryką uzupełniającą, a nie sygnałem rankingowym.
• The Beginner’s Guide to Technical SEO — szerszy obraz wydajności witryny, w którym to się mieści.

Oficjalne

• web.dev TTFB i Optimize TTFB — dwie definitywne strony.
• Artykuł zespołu Chrome 103 Early Hints z wynikami Shopify/Cloudflare.

Dane

• HTTP Archive Web Almanac — rozdział o wydajności — długoterminowe dane terenowe TTFB i LCP dla całej sieci.

Z branży

• Cloudflare blog: Early Hints — artykuł Cloudflare o wdrażaniu 103 Early Hints, w tym wyniki z rzeczywistego świata i szczegóły implementacji CDN.
• web-vitals JS library (GitHub) — kanoniczna biblioteka do zbierania TTFB (i wszystkich Web Vitals) od prawdziwych użytkowników; użyj jej, aby wysyłać terenowe TTFB do własnej analityki.
• HTTP Archive Web Almanac 2022 — Performance — historyczna linia bazowa pokazująca 40% mobilnych dobrych TTFB przy ówczesnym progu 800 ms; przydatna do kontekstu trendów wieloletnich.
• Fastly — HTTP/2 Server Push vs Early Hints — perspektywa CDN na temat tego, dlaczego Early Hints zastępuje Server Push w redukcji wpływu TTFB.

Statystyki, które warto cytować

• ~42 % mobilnych witryn ma „dobry” TTFB — i to prawie nie zmieniło się od pięciu lat. Współczynnik dobrego TTFB dla urządzeń mobilnych w Web Almanac oscyluje wokół 41–42 % w danych z pięciu lat: uporczywa stagnacja w całej sieci. Źródło
• Na stronach z słabym LCP sam TTFB pochłaniał ~2,27 sekundy — prawie cały próg „dobrego LCP” wynoszący 2,5 sekundy, zanim wyrenderowano jakąkolwiek treść. TTFB jest największą składową LCP dla stron, które go nie osiągają. Źródło
• 103 Early Hints przyniosło kilkaset milisekund poprawy LCP w testach Shopify i Cloudflare — w niektórych przypadkach blisko sekundę szybciej. Źródło
• Linia „dobrego” TTFB przesunęła się z 500 ms do 800 ms w 2022 roku, a dane historyczne zostały przeliczone według nowego standardu — warto o tym wiedzieć przed porównywaniem starych liczb TTFB. Źródło

Sprawdź się: Time to First Byte

Pięć szybkich pytań o to, co mierzy TTFB i jak go poprawić. Wybierz odpowiedź na każde, a następnie sprawdź.

Dziennik zmian