TTFB vs czas odpowiedzi vs latencja

Co oznacza każdy termin

Latencja sieciowa, często raportowana jako czas podróży w obie strony (round-trip time), to czas, jaki pakiet spędza w drodze do serwera i z powrotem, bez żadnej pracy aplikacji pomiędzy. Wyznaczają ją odległość fizyczna, liczba przeskoków i jakość trasy. Nic, co robisz w kodzie, tego nie zmienia.

Time to first byte (TTFB) jest mierzony od chwili, gdy klient rozpoczyna żądanie, aż do momentu, gdy dotrze do niego pierwszy bajt odpowiedzi. Ten odcinek obejmuje wyszukiwanie DNS, połączenie TCP, uzgadnianie TLS, czas, jaki żądanie spędza w drodze, to, co robi serwer, żeby wypracować odpowiedź, oraz drogę powrotną. TTFB jest więc zawsze większy niż jeden przelot w obie strony, zwykle o wielokrotność.

Czas odpowiedzi jest najluźniej zdefiniowanym z tej trójki. Większość narzędzi do monitoringu używa go jako całkowitego czasu zakończenia żądania, od pierwszego pakietu do ostatniego bajtu treści. Niektóre narzędzia używają go jako synonimu TTFB. Zanim porównasz dwie liczby oznaczone jako "czas odpowiedzi", sprawdź, w którym momencie dane narzędzie zatrzymało zegar.

Jak mierzy się każdą z tych wartości

Latencja pochodzi z echa ICMP, które wysyła polecenie ping, albo z pomiaru czasu uzgadniania TCP, gdy ICMP jest zablokowane. TTFB i czas całkowity pochodzą z samego klienta HTTP. Jedno wywołanie curl wypisuje wszystkie te granice:

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

Każda wartość jest liczona narastająco od początku żądania, więc trzeba je czytać jako granice, a nie jako czasy trwania. Odejmij poprzednią wartość, żeby uzyskać długość danego etapu.

Jaką liczbę pokazuje Twoje narzędzie

Każde narzędzie raportuje inny wycinek tego samego żądania, co jest zwykłym powodem, dla którego dwa pomiary tej samej strony się nie zgadzają:

• ping raportuje wyłącznie latencję podróży w obie strony, bez uwzględnienia pracy serwera
• curl -w raportuje każdą z powyższych granic, co czyni go punktem odniesienia, gdy liczby się nie zgadzają
• Narzędzia deweloperskie w przeglądarce pokazują TTFB jako etap oczekiwania żądania, oddzielony od etapu pobierania poniżej
• Lighthouse i PageSpeed raportują czas odpowiedzi serwera, czyli TTFB dla żądania dokumentu
• Monitory uptime raportują czas odpowiedzi, którego definicja różni się w zależności od produktu i który obejmuje nawiązanie połączenia od miejsca, z którego wykonano kontrolę
• Monitoring rzeczywistych użytkowników (real user monitoring) raportuje TTFB z pola, uśredniony po prawdziwych odwiedzających w prawdziwych sieciach

Jak wygląda dobra wartość

Latencja jest ograniczona geografią. Poniżej 30 ms to norma wewnątrz jednej aglomeracji, 50 do 100 ms w obrębie kontynentu, a 150 do 250 ms między kontynentami. Trasa, która mierzy znacznie więcej niż wynikałoby z odległości, wskazuje raczej na złą trasę niż na wolny serwer.

Dla TTFB web.dev uznaje 800 ms lub mniej za dobre, a wszystko powyżej 1,8 sekundy za słabe, podczas gdy audyt czasu odpowiedzi serwera w Lighthouse zaczyna oznaczać wynik jako błędny powyżej 600 ms. Dąż do wartości poniżej 600 ms dla żądania dokumentu i traktuj 200 ms jako cel dla wszystkiego, co jest cache'owane lub serwowane statycznie.

Całkowity czas odpowiedzi zależy od rozmiaru tego, co wysyłasz, więc nie ma tu jednej uniwersalnej wartości. Zmierz swój własny punkt odniesienia w normalny dzień i traktuj zmianę względem niego jako sygnał, a nie wartość bezwzględną.

Czytanie luk

Pojedyncze liczby mają mniejsze znaczenie niż odległość między nimi, bo każda luka wskazuje na inny podsystem:

• TTFB minus latencja podróży w obie strony to w przybliżeniu czas, jaki serwer spędził na "myśleniu". Jeśli to jest większa część, problem tkwi w kodzie aplikacji, wolnym zapytaniu albo zimnym cache'u
• Connect minus wyszukiwanie DNS to jeden przelot w obie strony na uzgadnianie TCP. Jeśli jest wyraźnie większy niż zmierzona latencja, trasa sieciowa jest przeciążona albo źle poprowadzona
• TLS minus connect to koszt uzgadniania, zwykle jeden lub dwa dodatkowe przeloty w obie strony, a duża wartość wskazuje na problemy z łańcuchem certyfikatów lub wznawianiem sesji
• Total minus TTFB to czas transferu. Jeśli to on dominuje, odpowiedź jest zbyt duża albo połączenie zbyt wolne, i żadne strojenie serwera tu nie pomoże
• Samo wyszukiwanie DNS po zbuforowaniu powinno trwać kilka milisekund. Konsekwentnie wolne wyszukiwanie to problem resolvera lub autorytatywnego serwera nazw, a nie serwera WWW

To samo rozumowanie działa w drugą stronę, gdy wolna jest tylko jedna lokalizacja. Jednakowy czas "myślenia" serwera wszędzie, przy różnicy tkwiącej wyłącznie w latencji i transferze, oznacza, że serwer jest w porządku, a trasa nie. Uruchom kontrolę z kilku miejsc, zanim dotkniesz aplikacji.

Zmierz to w jednym miejscu

Żeby zobaczyć te liczby dla danej strony bez ręcznego składania ich razem, uruchom test szybkości strony, który ładuje stronę z zewnętrznej lokalizacji i rozbija ładowanie na etapy. Przewodnik po czasie odpowiedzi serwera opisuje ten sam pomiar z linii poleceń. Pojedynczy pomiar mówi tylko o tej jednej chwili, więc jeśli ta liczba ma znaczenie, ustaw na nią zaplanowaną kontrolę: HostTracker mierzy czas odpowiedzi przy każdej kontroli z ponad 300 punktów kontrolnych w 158 miastach, co zamienia jeden pomiar w punkt odniesienia, względem którego widać regresję. Więcej definicji znajdziesz w sekcji o pojęciach monitoringu.