TTFB a reverse proxy: czy proxy spowalnia Twoją stronę?
W tym artykule
- Co właściwie mierzy czas do pierwszego bajtu?
- Jaki TTFB jest dobry i dlaczego ma znaczenie dla SEO
- Gdzie reverse proxy dodaje opóźnienie
- Jak zmierzyć TTFB reverse proxy przed zmianą i po niej
- Keepalive do upstreamu i inne ustawienia na własnym NGINX
- Kiedy to nie proxy odpowiada za wolny TTFB
- Co zrobić z wynikami TTFB
- FAQ
Tak, reverse proxy dokłada jeden dodatkowy przeskok w sieci, więc może wydłużyć czas do pierwszego bajtu. O ile? Przy rozsądnej konfiguracji zwykle o bardzo niewiele. A jedyny uczciwy sposób, żeby to sprawdzić, to pomiar przed zmianą i po niej. Jeśli boisz się, że postawienie NGINX przed hostingiem zaszkodzi szybkości strony i pozycjom w Google, ten poradnik pokaże, z czego naprawdę składa się TTFB przy reverse proxy, skąd bierze się opóźnienie proxy, jak je zmierzyć i jak utrzymać je na niskim poziomie.
Co właściwie mierzy czas do pierwszego bajtu?
Czas do pierwszego bajtu to czas od rozpoczęcia nawigacji do chwili, gdy dotrze pierwszy bajt odpowiedzi. Tak opisuje go poradnik web.dev o TTFB. Obejmuje to zestawienie połączenia (zapytanie DNS, połączenie TCP, handshake TLS) oraz cały czas, jaki backend poświęca na zbudowanie strony. Liczy się praca sieci. Liczy się praca serwera. Jedno i drugie. Jest też niuans, który wielu pomija: odpowiedzi Early Hints i wczesne wysłanie nagłówków albo sekcji <head> także liczą się jako pierwszy bajt, a osobny znacznik czasu, finalResponseHeadersStart, pokazuje, kiedy faktycznie zaczyna się właściwa odpowiedź z dokumentem. Ponieważ TTFB poprzedza First Contentful Paint i Largest Contentful Paint, wolny pierwszy bajt opóźnia każde kolejne renderowanie.
Jaki TTFB jest dobry i dlaczego ma znaczenie dla SEO
Zgodnie z progami TTFB według web.dev dobry wynik to 0,8 sekundy lub mniej, a słaby to wszystko powyżej 1,8 sekundy. Sam TTFB nie jest metryką Core Web Vitals. Ale bezpośrednio wpływa na LCP, które nią jest.
Google w swojej dokumentacji Core Web Vitals dla wyszukiwarki zaleca właścicielom stron dobre wyniki Core Web Vitals, jeśli chcą odnosić sukces w wyszukiwarce. Czas odpowiedzi serwera wpływa więc na SEO pośrednio. Wolny backend albo źle umieszczone proxy pogarszają metryki ładowania odczuwane przez użytkownika, na które Google rzeczywiście patrzy (i to o nie warto dbać, a nie o TTFB jako jakąś magiczną liczbę rankingową).
Gdzie reverse proxy dodaje opóźnienie
Proxy dodaje opóźnienie w dwóch miejscach: przez dodatkowy przeskok między odwiedzającym, proxy i serwerem źródłowym oraz przez nowe połączenie, które może otwierać do serwera źródłowego przy każdym żądaniu. Najważniejsza jest odległość. Postaw proxy daleko od serwera źródłowego albo daleko od czytelników, a zapłacisz za to dodatkowymi przejściami w obie strony. Dlatego wybór lokalizacji hostingu wymaga tyle samo namysłu co samo proxy.
Drugi koszt to zestawianie połączenia z upstreamem. Przy wyłączonym keepalive proxy przy każdym żądaniu powtarza handshake TCP i TLS z serwerem źródłowym. Czyste marnotrawstwo. Ale jest i druga strona: ten sam układ może Ci wręcz pomóc. Jeśli TLS kończy się blisko czytelników, a proxy trzyma gotowe połączenia z serwerem źródłowym, możesz zrównoważyć koszt dodatkowego przeskoku. Jalvo to na przykład reverse proxy na NGINX z europejskimi i amerykańskimi adresami IP, więc wynik zależy od tego, gdzie proxy stoi względem Twojego serwera źródłowego i Twoich odbiorców.
Jak zmierzyć TTFB reverse proxy przed zmianą i po niej
Porównaj ten sam adres URL przez proxy i bezpośrednio na serwerze źródłowym, z tej samej lokalizacji, wielokrotnie. Jedno żądanie nie mówi prawie nic. Szum w sieci mocno rozrzuca pojedyncze wyniki.
- Uruchom curl z polami czasowymi dla nazwy hosta proxy:
curl -o /dev/null -s -w "connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}n" https://example.com/ - Uruchom to samo polecenie dla serwera źródłowego, z
--resolve example.com:443:ORIGIN_IPalbo wpisem w pliku hosts, żeby certyfikat nadal pasował. - Powtórz każdy pomiar wiele razy i porównuj mediany, a nie pojedyncze wartości.
- Testuj z regionów, w których faktycznie są Twoi czytelnicy, a nie tylko ze swojego laptopa.
Dane z rzeczywistego ruchu da Ci Navigation Timing API albo biblioteka web-vitals, które raportują TTFB dla prawdziwych odwiedzających. Resource Timing API obsługuje pozostałe żądania, również te do innych domen. Uwaga jednak: zasoby z tej samej domeny mogą pokazywać zero, bo połączenie jest już otwarte albo plik pochodzi z cache. Czytając wyniki, patrz na różnice. Większa różnica w czasie połączenia i TLS wskazuje na koszt sieci. Różnica tylko w czasie do pierwszego bajtu? To backend.
Keepalive do upstreamu i inne ustawienia na własnym NGINX
Największy zysk po stronie proxy daje ponowne używanie połączeń z serwerem źródłowym zamiast otwierania nowego przy każdym żądaniu. Na własnym NGINX sprowadza się to do trzech ustawień:
- blok
upstreamz dyrektywąkeepalive, która utrzymuje otwarte bezczynne połączenia, proxy_http_version 1.1;w bloku location, który przekazuje ruch,proxy_set_header Connection "";, żeby wyczyścić nagłówek, który inaczej zamykałby każde połączenie.
Trzymaj proxy i serwer źródłowy blisko siebie w sieci i nie łącz kilku proxy w łańcuch, bo każda warstwa dokłada własny przeskok. Dla jasności: to ustawienia Twojego serwera źródłowego albo Twojego własnego NGINX, a nie opcje w panelu Jalvo. A jeśli w pomiarach dominuje czas przetwarzania po stronie backendu, najpierw napraw serwer źródłowy. Żadne strojenie proxy nie ukryje wolnej aplikacji.
Kiedy to nie proxy odpowiada za wolny TTFB
Jeśli serwer źródłowy jest wolny już przy bezpośrednim połączeniu, usunięcie proxy nie poprawi TTFB. Typowi winowajcy po stronie serwera źródłowego: ciężkie zapytania do bazy danych, brak cache stron w CMS, przeciążony hosting współdzielony.
Oznaki, że winny jest backend, a nie sieć:
- bezpośrednie żądania do serwera źródłowego pokazują podobnie wolny pierwszy bajt,
- czasy połączenia i TLS są niskie, a czas do pierwszego bajtu pozostaje wysoki,
- pliki statyczne wracają szybko, ale strony dynamiczne się ociągają,
- w godzinach szczytu wszystko zwalnia.
Nie masz pewności, czy proxy w ogóle pasuje do Twojej konfiguracji? Zanim cokolwiek zmienisz, zastanów się, kiedy proxy jest właściwym narzędziem.
Co zrobić z wynikami TTFB
Tak, reverse proxy dodaje przeskok. Ale w praktyce zmierzone opóźnienie zależy głównie od odległości i ponownego używania połączeń z upstreamem, a oba te czynniki da się poprawić. Zmierz serwer źródłowy i proxy, porównaj mediany, sprawdź dane z rzeczywistego ruchu względem progu web.dev. Więcej o lokalizacji i konfiguracji serwerów znajdziesz we wpisach o hostingu na blogu. Moja rada? Zrób dziś jedno porównanie w curl. Jasny punkt odniesienia to najszybszy sposób, żeby sprawdzić, czy TTFB reverse proxy to naprawdę Twój problem.
FAQ
Czy reverse proxy zawsze zwiększa TTFB?
u003cpu003eNie zawsze. Owszem, dodaje przeskok w sieci, ale ponownie używane połączenia z upstreamem i TLS kończony bliżej czytelników mogą zrównoważyć ten koszt. Tylko pomiar przed zmianą i po niej pokaże, jak to naprawdę działa na Twojej stronie.u003c/pu003e
Jak sprawdzić TTFB z proxy i bez niego?
u003cpu003eUżyj pól czasowych curl dla nazwy hosta proxy, a potem dla serwera źródłowego z opcją u003ccodeu003eu002du002dresolveu003c/codeu003e, żeby obowiązywał ten sam certyfikat. Powtórz każdy test kilka razy z tej samej lokalizacji. Potem porównaj mediany, a nie pojedyncze wyniki.u003c/pu003e
Czy TTFB jest czynnikiem rankingowym Google?
u003cpu003eSam nie jest metryką Core Web Vitals, ale poprzedza LCP, które nią jest. Google zaleca dobre wyniki Core Web Vitals, jeśli chcesz odnosić sukces w wyszukiwarce, więc wolny pierwszy bajt może zaszkodzić pośrednio.u003c/pu003e
Daj każdej stronie własne IP.
Pierwszą domenę dodasz w kilka minut.
