Co mierzy TTFB, a czego nie mówi o szybkości strony
TTFB (Time to First Byte) to czas od rozpoczęcia żądania do chwili, w której przeglądarka otrzyma pierwszy bajt odpowiedzi. Wynik zależy nie tylko od pracy serwera. Mogą się na niego składać również opóźnienia sieciowe, zestawienie połączenia, przekierowania i obsługa żądania przez pośrednie systemy, takie jak CDN. Dokładny zakres pokazywany w narzędziu zależy od sposobu pomiaru, dlatego przed porównaniem wyników warto sprawdzić, co obejmuje dana metryka.
Krótki TTFB nie oznacza, że strona będzie szybko gotowa do użycia. Po pierwszej odpowiedzi przeglądarka nadal musi pobrać dokument, style, skrypty i obrazy, a następnie wyświetlić treść. Z kolei długi TTFB może opóźniać rozpoczęcie tych prac. Traktuj go więc jako wskazówkę dotyczącą początkowej fazy ładowania, a nie jako pełną ocenę wydajności lub widoczności w wyszukiwarce.
Skąd bierze się opóźnienie pierwszej odpowiedzi
Najpierw znaczenie ma droga żądania. Użytkownik oddalony od serwera zwykle potrzebuje więcej czasu na wymianę danych niż użytkownik znajdujący się bliżej niego. Dodatkowy czas mogą wprowadzać kolejne przekierowania, na przykład z adresu HTTP na HTTPS, a potem na inną wersję adresu. Nie każde przekierowanie jest błędem, ale zbędny łańcuch wydłuża drogę do właściwego dokumentu.
Po dotarciu żądania serwer może zwrócić gotową kopię strony albo dopiero ją zbudować. W sklepie internetowym karta popularnego produktu może być obsłużona z pamięci podręcznej, podczas gdy koszyk wymaga danych właściwych dla konkretnej osoby. Gdy odpowiedź powstaje na bieżąco, czas mogą zajmować zapytania do bazy, działanie aplikacji lub oczekiwanie na inne usługi. Słabsza wydajność pod obciążeniem bywa z kolei widoczna tylko w godzinach większego ruchu.
Istotne jest także miejsce pomiaru. CDN może szybko podać zapisaną kopię dokumentu, lecz przy braku takiej kopii musi pobrać go z serwera źródłowego. Dwie wizyty pod tym samym adresem mogą więc dać różne wyniki bez żadnej zmiany w kodzie strony.
Jak sprawdzić, gdzie znika czas
Zacznij od kilku adresów reprezentujących różne typy stron: strony głównej, kategorii, artykułu lub karty produktu. Otwórz panel sieciowy w narzędziach deweloperskich przeglądarki i sprawdź żądanie głównego dokumentu. Zwróć uwagę na przekierowania oraz rozbicie czasu na oczekiwanie i pozostałe etapy połączenia. Powtórz test, zamiast wyciągać wniosek z pojedynczego odczytu.
Porównuj wyniki uzyskane w podobnych warunkach: z tej samej lokalizacji, na podobnym połączeniu i przy tym samym stanie pamięci podręcznej. Osobno sprawdź pierwsze wejście oraz ponowne odwiedziny. Jeśli korzystasz z CDN lub cache aplikacji, ustal, czy odpowiedź pochodziła z zapisanej kopii. Strona obsługiwana z cache może wyglądać dobrze w teście, podczas gdy jej wygenerowanie po wygaśnięciu kopii nadal trwa długo.
Pomocne są też logi i pomiary po stronie serwera, jeżeli masz do nich dostęp. Pozwalają odróżnić długie przetwarzanie aplikacji od opóźnienia powstającego wcześniej, na drodze do serwera. Jeśli TTFB różni się między adresami, szukaj cech wspólnych wolniejszych stron, zamiast od razu zmieniać konfigurację całej witryny.
Kiedy poprawa TTFB jest warta pracy
Warto nadać jej priorytet, gdy opóźnienie powtarza się na ważnych stronach i stanowi wyraźną część czasu oczekiwania na treść. Przykładem jest serwis poradnikowy, w którym większość artykułów rzadko się zmienia, lecz każde wejście uruchamia kosztowne generowanie dokumentu. W takiej sytuacji cache HTML może ograniczyć zbędną pracę aplikacji. Trzeba przy tym zaplanować odświeżanie kopii po zmianie treści.
Jeśli problem dotyczy tylko wybranych podstron, zacznij od ich szablonów, zapytań do bazy i zależności od innych usług. Jeżeli czas wydłuża się głównie przy pierwszym wejściu, sprawdź przekierowania oraz drogę połączenia. Gdy wyniki pogarszają się pod obciążeniem, przyjrzyj się zasobom serwera i temu, jak aplikacja obsługuje równoczesne żądania.
Nie każda różnica w TTFB wymaga interwencji. Jeśli pierwsza odpowiedź przychodzi sprawnie, a użytkownik nadal długo czeka na widoczną treść, większy efekt może dać praca nad obrazami, skryptami lub sposobem wyświetlania strony. Celem jest poprawa rzeczywistego doświadczenia odwiedzających, nie samo obniżenie jednej liczby w raporcie.
Krótka lista kontrolna przed zmianami
Sprawdź, czy mierzysz główny dokument strony, a nie plik obrazu lub skrypt. Zapisz adres, warunki testu, liczbę przekierowań oraz informację, czy odpowiedź pochodziła z cache. Porównaj kilka typów podstron i powtórz pomiary. Następnie ustal, czy zwłoka występuje w sieci, na serwerze źródłowym, czy podczas generowania konkretnej strony.
Po wprowadzeniu jednej zmiany wykonaj test ponownie w możliwie tych samych warunkach. Skontroluj również, czy strona nadal pokazuje aktualną treść oraz czy funkcje wymagające indywidualnych danych działają prawidłowo. Taki porządek ułatwia znalezienie przyczyny i zmniejsza ryzyko, że poprawa wyniku testowego odbędzie się kosztem działania serwisu.
