Czas do pierwszego bajtu (TTFB)

Czas do pierwszego bajtu (Time to First Byte) mierzy odstęp czasu między żądaniem zasobu przez przeglądarkę a otrzymaniem pierwszego bajtu odpowiedzi. Łączy on kilka odrębnych faz: przekierowania, rozpoznawanie nazw domen (DNS), nawiązywanie połączenia, negocjację TLS, samo żądanie oraz czas przetwarzania serwera przed rozpoczęciem odpowiedzi. Ponieważ wszystkie inne procesy ładowania strony zależą od otrzymania tej odpowiedzi, pełni on funkcję podstawy dla każdej metryki ładowania downstream.

Jego wartość diagnostyczna wynika z pozycji w sekwencji. Strona z powolnym renderowaniem największej zawartości i szybkim pierwszym bajtem ma problem z front-endem, w dostarczaniu zasobów, renderowaniu lub blokowaniu zasobów. Ta sama strona z powolnym pierwszym bajtem ma problem z back-endem lub siecią i żadna optymalizacja obrazu ani odroczenie skryptu tego nie naprawi, ponieważ przeglądarka nie otrzymała jeszcze niczego, z czym mogłaby pracować. Ustalenie, który z tych problemów ma zastosowanie, to pierwszy krok w każdym poważnym badaniu wydajności.

Przyczyny dzielą się na kategorie sieciowe i serwerowe. Po stronie sieci, odległość geograficzna między użytkownikiem a serwerem źródłowym powoduje nieuniknione opóźnienia, łańcuchy przekierowań dodają pełną trasę w obie strony, a negocjacja połączenia i TLS generuje kolejne trasy w przypadku nowych połączeń. Po stronie serwera, do najczęstszych przyczyn należą: powolny kod aplikacji, nieindeksowane lub nieefektywne zapytania do bazy danych, synchroniczne wywołania usług zewnętrznych podczas żądania, brak lub nieefektywne buforowanie oraz konflikty zasobów na hostingu współdzielonym.

Rozwiązania te różnią się w zależności od sytuacji. Sieci dostarczania treści (CDS) radzą sobie z odległością, obsługując połączenia z lokalizacji znajdujących się blisko użytkownika i mogą obsługiwać buforowane odpowiedzi całkowicie z krawędzi, bez kontaktu z punktem źródłowym. Buforowanie na wielu warstwach, w tym buforowanie całej strony, fragmentów, obiektów i zapytań do bazy danych, eliminuje powtarzające się zadania. Eliminacja łańcuchów przekierowań eliminuje całe cykle, co często stanowi największą dostępną poprawę w witrynach ze starszymi strukturami adresów URL. Nowoczesne protokoły i ponowne wykorzystanie połączeń zmniejszają obciążenie związane z negocjacjami. Po stronie aplikacji optymalizacja zapytań i przeniesienie zbędnych zadań poza ścieżkę żądania rozwiązują problem komponentu serwera.

Pomiar powinien rozróżniać odpowiedzi buforowane i niebuforowane oraz pierwsze i powtórne wizyty, ponieważ mogą one różnić się o rząd wielkości, a średnia pomija oba te czynniki. Dane terenowe segmentowane według regionu geograficznego i typu połączenia są bardziej informatywne niż pojedyncza wartość, ponieważ witryna o akceptowalnej liczbie odwiedzin może bardzo słabo obsługiwać jeden rynek. Testowanie z lokalizacji hostowanej witryny, co jest powszechnym ustawieniem domyślnym, systematycznie zaniża to, czego doświadczają odlegli użytkownicy.

Współczynnik trafień w pamięci podręcznej to najprzydatniejszy wskaźnik diagnostyczny używany do badania tej metryki w witrynie działającej w ramach sieci CDS (Content Delivery Network). Często jest on zaniżony z przyczyn łatwych do skorygowania. Odpowiedzi oznaczone domyślnie jako niebuforowalne, klucze pamięci podręcznej pofragmentowane przez parametry śledzenia lub zbędne nagłówki oraz krótkie czasy wygaśnięcia – wszystko to powoduje, że żądania docierają do źródła, mimo że nie powinny. Pomiar odsetka żądań obsługiwanych z krawędzi i analiza czynników decydujących o chybionych wynikach zazwyczaj identyfikuje niewielką liczbę decyzji konfiguracyjnych odpowiedzialnych za większość z nich. Poprawa tego odsetka zmniejsza zarówno opóźnienia dla użytkowników, jak i obciążenie źródła, co poprawia odpowiedzi, które faktycznie muszą zostać wygenerowane.

Ponieważ poprawa zazwyczaj wymaga zmian w infrastrukturze, strategii buforowania lub kodzie aplikacji, a nie w zasobach front-end, to właśnie ten aspekt najczęściej przenosi pracę nad wydajnością z warstwy prezentacji do inżynierii. W praktyce jest to realizowane wspólnie przez wydajność sieci oraz rozwój produktówi często to właśnie ograniczenie należy rozwiązać w pierwszej kolejności, ponieważ optymalizacja front-endu stosowana na wolnym źródle daje rozczarowujące wyniki, które są błędnie przypisywane pracom optymalizacyjnym.