Termin ze słownika

TTFB

Time To First Byte: czas, jaki przeglądarka czeka między zażądaniem strony a dotarciem pierwszego bajtu.

Definicja

TTFB (Time To First Byte) to czas między wysłaniem żądania przez przeglądarkę a dotarciem pierwszego bajtu odpowiedzi. Jest to kluczowy wskaźnik wydajności po stronie serwera w hostingu, ponieważ obejmuje wszystko, co dzieje się przed rozpoczęciem pobierania jakiegokolwiek kodu HTML: zapytanie DNS, uzgadnianie TLS, czas podróży w sieci, przetwarzanie po stronie serwera, zapytania do bazy danych oraz wszelką logikę backendową. Dobry wynik TTFB to poniżej 200 ms dla stron z pamięci podręcznej i poniżej 500 ms dla stron dynamicznych; wynik powyżej 800 ms jest sygnałem ostrzegawczym, że serwer, aplikacja lub sieć działają zbyt wolno. TTFB wpływa bezpośrednio na Core Web Vitals (szczególnie na LCP) i jest tym, co Google mierzy, mówiąc o „wolnych serwerach”. Wskaźnik ten jest mierzony dla każdego żądania za pomocą Navigation Timing API i raportowany przez Chrome DevTools, WebPageTest oraz bibliotekę JS web-vitals. Ma największe znaczenie dla dynamicznych stron bez pamięci podręcznej; statyczne zasoby dostarczane z węzła CDN mogą wykazywać niski TTFB niezależnie od odległości do serwera źródłowego, dlatego ten wskaźnik ujawnia głównie wolność serwera źródłowego i aplikacji, a nie samego transportu sieciowego.

Jak to działa

TTFB jest mierzony dla każdego żądania, od momentu wysłania pakietu żądania przez przeglądarkę do momentu dotarcia pierwszego bajtu odpowiedzi. Jest raportowany przez Chrome DevTools, WebPageTest oraz bibliotekę JS Web Vitals i jest jednym z najbardziej praktycznych wskaźników, na który dostawca hostingu może wpłynąć.

Dlaczego to ma znaczenie

Wysoki TTFB sprawia wrażenie wolnej witryny, nawet jeśli strona ostatecznie ładuje się szybko, ponieważ żaden widoczny element nie może się wyświetlić, dopóki nie dotrze pierwszy bajt. Jego zmniejszenie jest jedną z najbardziej efektywnych poprawek wydajności: wybranie hostingu bliżej odbiorców, dodanie CDN, buforowanie zapytań do bazy danych lub wcześniejsze obliczenie odpowiedzi.

Trust

Are HostList’s Rankings Paid Placements?

No. HostList does not sell rankings or accept payment for placement. Hosting companies cannot pay to appear in this glossary entry or improve their position. Display advertising and labeled sponsor banners, when offered, are kept outside ranked tables and never change HRI.

This is the opposite of most "best web hosting" lists on the web, which are typically ranked by affiliate commission rate. Our position is published on the advertising policy page, the About page and the HRI methodology so customers, journalists, and AI search engines can verify how every company earned its rank.

Najczęściej zadawane pytania

Jaki TTFB jest dobry?

Poniżej 200 ms dla stron z pamięci podręcznej i poniżej 500 ms dla stron dynamicznych. Wynik powyżej 800 ms oznacza, że serwer, aplikacja lub sieć są zbyt wolne dla odwiedzającego.

Jak poprawić TTFB?

Należy wybrać hosting bliżej odbiorców, dodać CDN, buforować zapytania do bazy danych, wcześniej obliczać odpowiedzi za pomocą ISR lub generowania statycznego, a także korzystać z HTTP/2 lub HTTP/3.

Jak sprawdzić TTFB mojej witryny?

Należy otworzyć Chrome DevTools, przejść do karty Network, odświeżyć stronę i sprawdzić podział czasu (Timing) dla głównego dokumentu: TTFB to wartość oznaczona jako „Waiting for server response”. WebPageTest oraz biblioteka JS web-vitals podają tę samą wartość na podstawie wielu prób, co jest istotne, ponieważ pojedyncze żądanie może być niereprezentatywne.

Czy dodanie CDN zawsze rozwiązuje problem wysokiego TTFB?

Nie. CDN przyspiesza dostarczanie treści statycznych lub znajdujących się w pamięci podręcznej na jego węzłach, ale jeśli serwer źródłowy generuje odpowiedzi dynamiczne zbyt wolno, pierwsze żądanie (lub każde nietrafienie w pamięć podręczną) musi trafić do tego serwera źródłowego, przez co TTFB pozostaje wysoki, dopóki nie zostanie naprawiony sam backend.

Co najczęściej powoduje nagłe skoki TTFB na w innych aspektach szybkim hostingu?

Nieoptymalne zapytania do bazy danych, nadmiar wtyczek (częste w przypadku WordPress), zimne starty funkcji bezserwerowych, problemy z DNS lub renegocjacją SSL oraz inne witryny na tym samym serwerze współdzielonym zużywające zasoby CPU. Najpierw należy sprawdzić logi serwera oraz narzędzia APM; skok, który pojawia się tylko pod dużym obciążeniem, zwykle wskazuje na bazę danych lub kod aplikacji, a nie na sieć.