TTFB (Time To First Byte) – jak podejść do optymalizacji.

Czas czytania

4 min.

TTFB co to jest?

TTFB („Time To First Byte„) to akronim w tłumaczeniu „Czas do pierwszego bajtu” – jest to czas wyrażony w milisekundach (ms), od momentu wysłania żądania przez przeglądarkę do otrzymania danych z serwera. W teorii – im dłużej trwa uzyskanie tych danych, tym więcej potrzeba czasu na wyświetlanie Twojej strony w przeglądarce – i to właśnie celu pomocy w optymalizacji powstała ta wartość. Ale sama wartość TTFB nie mówi nic w kontekście, gdzie leży problem, ponieważ sumuje całość, wszystkie 3-etapy. Ważne jest to, aby zrozumieć, że TTFB to nie to samo co prędkość witryny/serwera.

TTFB – Time To First Byte. Przykład GTmetrix, długi TTFB i przekierowania.

TTFB to nie prędkość witryny czy serwera.

Obliczenie TTFB w sieci zawsze uwzględnia tzw. opóźnienie sieci. Ale jest to 3-etapowy proces, a opóźnienia mogą wystąpić w dowolnym miejscu pomiędzy przeglądarką a serwerem, sumując się do całkowitej wartości TTFB ze wszystkich etapów procesu. Powoduje to fakt, iż na podstawie tylko samej wartości TTFB nie jesteśmy w stanie zlokalizować czy problemem jest struktura, konfiguracja czy sprzęt, …a może oprogramowanie. Prześledźmy te 3 etapy po krótce.

1. Żądanie do serwera.

Ten etap mogą obciążyć takie czynniki takie jak: długie wyszukiwanie DNS, jeśli serwer znajduje się geograficznie daleko od odbiorcy lub nawet – nieoptymalne reguły zapory firewall, które wydłużają czas routingu. Do obniżenia wartości może się również przyczynić przekierowanie w .htaccess do HTTPS jeśli mierzymy adres URL podając http://. Ponadto, na tym etapie odpowiednią wartość daje nam możliwość prześledzić zwykła komenda ping, która wyświetla czas dotarcia pakietu do serwera. Warto o tym nie zapominać i z niej korzystać.

ping <nazwa domeny>

2. Przetwarzanie.

Na przetwarzanie żądania przez serwer składa się wiele możliwych czynników, które mogą wpłynąć na wydłużenie TTFB. Możliwe scenariusze to np. brak buforowania, mozolne wywołania do bazy danych, źle zoptymalizowany kod PHP np. wtyczki WordPress, a na końcu – operacje dyskowe czy wydajność serwera. Dziesiątki zmiennych.

3. Wysyłanie odpowiedzi.

Dopiero na tym etapie serwer jest gotowy odesłać „Pierwszy Bajt”. A nawet tu, duży wpływ na to ma zarówno szybkość sieci serwera, sieci pośredniej, jak i tej klienta. Jeśli np. klient ma wolny internet z hotspotu Wi-Fi, zostanie to odzwierciedlone w TTFB.

Ale Google Page Speed Insights mówi…

Sprawy nie ułatwiło polskie tłumaczenie Google Page Speed insights, które dla zbyt dużego TTFB komunikuje „Skróć czas odpowiedzi serwera” pomimo że dodaje przy tym wyraźnie iż na ten parametr składają się dziesiątki czynników. Tak było w wersji 4 GPSI API, która po Maju 2019 roku została zamieniona z wersją 5 API, gdzie w zamian są wykorzystywane współczynniki danych rzeczywistych (ang. real-world data) z Chrome User Experience Report oraz dane labolatoryjne z Lighthouse. Mimo to informacja o TTFB również się pojawia.

Źródło: https://developers.google.com/speed/docs/insights/Server

Więc co z tym TTFB?

Nie panikować. Przykładem tu może być artykuł na oficjalnym blogu Cloudflare, który już w roku 2012 starał się wyjaśnić to, co Google przesadnie skrócił. Udowodniono że żądanie z dłuższym TTFB dotarła szybciej tylko dzięki kompresji. Tak więc warto mieć na uwadze iż optymalizowanie strony pod samym kątem TTFB nie zawsze wpływa pozytywnie na wydajność całej witryny.

Przeczytaj artykuł: „Przestań się martwić o czas do pierwszego bajtu (TTFB)” EN https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

No dobrze, ale mimo wszystko jeśli parametr TTFB jest wysoki i chcemy go zmniejszyć to warto najpierw określić przyczynę.

Jak poprawić TTFB?

Podpowiada logika. Należy zacząć od końca. Gdyż zmiana od razu młotka nie spowoduje że szybciej wbijemy krzywy gwóźdź.

Najpierw cache – bo można.

Upewnijmy się że posiadamy wdrożony jakiś mechanizm cache. Na Hostingu WWW oraz Hostingu Elastycznym czy Hostingu pod WordPress w miejsce zwykłego Apache korzystamy z nawet 7x szybszego serwera Litespeed, co niebagatelnie przekłada się na parametry wydajności strony. Dodatkowo jeśli jeszcze nie skorzystaliście z LScache czyli najszybszej pamięci podręcznej, która jest dostępna dla każdego klienta usługi, polecamy zaznajomić się z poniższymi poradnikami, które demonstrują jak korzystać z pamięci podręcznej:

Jak korzystać z szybkości LiteSpeed lsCache dla WordPress?

Szybki sklep na PrestaShop dzięki Litespeed cache

Optymalizacja witryny – bo trzeba.

Upewnijmy się że posiadamy zoptymalizowaną witrynę WWW. Zwróćmy również uwagę na przekierowania. Do tego celu możemy wykorzystać narzędzie on-line jak GTmetrix.com. Wspomniana w poradnikach wtyczka Litespeed dla WordPress czy PrestaShop posiada wbudowane funkcje optymalizujące zasoby witryny, niemniej jednak możemy użyć też innych narzędzi, tu na przykładzie platformy WordPress polecam artykuły: Przyspiesz swoją stronę na WordPress czy WordPress Google PageSpeed 100/100? Jak to zrobić?

Optymalizacje wg. Google PageSpeed Insight, o które należy zadbać to:

Połączenie po HTTP/2 – certyfikat
Optymalizacja zasobów CSS i JS
Włącz kompresję tekstu
Wcześniej nawiąż połączenia z wymaganymi źródłami
Załaduj wstępnie kluczowe żądania
Wyeliminuj zasoby blokujące renderowanie

Optymalizacja serwera – bo nie ma wyjścia.

Dopiero na samym końcu logicznym jest się zabrać za sam serwer. Jeśli posiadamy Serwer VPS lub serwer dedykowany, warto rozważyć zakup licencji Litespeed lub wdrożyć mechanizm cache jak np. Varnish czy Redis.