Tak, reverse proxy dok\u0142ada jeden dodatkowy przeskok w sieci, wi\u0119c mo\u017ce wyd\u0142u\u017cy\u0107 czas do pierwszego bajtu. O ile? Przy rozs\u0105dnej konfiguracji zwykle o bardzo niewiele. A jedyny uczciwy spos\u00f3b, \u017ceby to sprawdzi\u0107, to pomiar przed zmian\u0105 i po niej. Je\u015bli boisz si\u0119, \u017ce postawienie NGINX przed hostingiem zaszkodzi szybko\u015bci strony i pozycjom w Google, ten poradnik poka\u017ce, z czego naprawd\u0119 sk\u0142ada si\u0119 TTFB przy reverse proxy, sk\u0105d bierze si\u0119 op\u00f3\u017anienie proxy, jak je zmierzy\u0107 i jak utrzyma\u0107 je na niskim poziomie.<\/p>\n\n\n\n
Czas do pierwszego bajtu to czas od rozpocz\u0119cia nawigacji do chwili, gdy dotrze pierwszy bajt odpowiedzi. Tak opisuje go poradnik web.dev o TTFB<\/a>. Obejmuje to zestawienie po\u0142\u0105czenia (zapytanie DNS, po\u0142\u0105czenie TCP, handshake TLS) oraz ca\u0142y czas, jaki backend po\u015bwi\u0119ca na zbudowanie strony. Liczy si\u0119 praca sieci. Liczy si\u0119 praca serwera. Jedno i drugie. Jest te\u017c niuans, kt\u00f3ry wielu pomija: odpowiedzi Early Hints i wczesne wys\u0142anie nag\u0142\u00f3wk\u00f3w albo sekcji <head><\/em> tak\u017ce licz\u0105 si\u0119 jako pierwszy bajt, a osobny znacznik czasu, finalResponseHeadersStart<\/em>, pokazuje, kiedy faktycznie zaczyna si\u0119 w\u0142a\u015bciwa odpowied\u017a z dokumentem. Poniewa\u017c TTFB poprzedza First Contentful Paint i Largest Contentful Paint, wolny pierwszy bajt op\u00f3\u017ania ka\u017cde kolejne renderowanie.<\/p>\n\n\n\n Zgodnie z progami TTFB wed\u0142ug web.dev<\/a> dobry wynik to 0,8 sekundy lub mniej, a s\u0142aby to wszystko powy\u017cej 1,8 sekundy. Sam TTFB nie jest metryk\u0105 Core Web Vitals. Ale bezpo\u015brednio wp\u0142ywa na LCP, kt\u00f3re ni\u0105 jest.<\/p>\n\n\n\n Google w swojej dokumentacji Core Web Vitals dla wyszukiwarki<\/a> zaleca w\u0142a\u015bcicielom stron dobre wyniki Core Web Vitals, je\u015bli chc\u0105 odnosi\u0107 sukces w wyszukiwarce. Czas odpowiedzi serwera wp\u0142ywa wi\u0119c na SEO po\u015brednio. Wolny backend albo \u017ale umieszczone proxy pogarszaj\u0105 metryki \u0142adowania odczuwane przez u\u017cytkownika, na kt\u00f3re Google rzeczywi\u015bcie patrzy (i to o nie warto dba\u0107, a nie o TTFB jako jak\u0105\u015b magiczn\u0105 liczb\u0119 rankingow\u0105).<\/p>\n\n\n\n Proxy dodaje op\u00f3\u017anienie w dw\u00f3ch miejscach: przez dodatkowy przeskok mi\u0119dzy odwiedzaj\u0105cym, proxy i serwerem \u017ar\u00f3d\u0142owym oraz przez nowe po\u0142\u0105czenie, kt\u00f3re mo\u017ce otwiera\u0107 do serwera \u017ar\u00f3d\u0142owego przy ka\u017cdym \u017c\u0105daniu. Najwa\u017cniejsza jest odleg\u0142o\u015b\u0107. Postaw proxy daleko od serwera \u017ar\u00f3d\u0142owego albo daleko od czytelnik\u00f3w, a zap\u0142acisz za to dodatkowymi przej\u015bciami w obie strony. Dlatego wyb\u00f3r lokalizacji hostingu<\/a> wymaga tyle samo namys\u0142u co samo proxy.<\/p>\n\n\n\n Drugi koszt to zestawianie po\u0142\u0105czenia z upstreamem. Przy wy\u0142\u0105czonym keepalive proxy przy ka\u017cdym \u017c\u0105daniu powtarza handshake TCP i TLS z serwerem \u017ar\u00f3d\u0142owym. Czyste marnotrawstwo. Ale jest i druga strona: ten sam uk\u0142ad mo\u017ce Ci wr\u0119cz pom\u00f3c. Je\u015bli TLS ko\u0144czy si\u0119 blisko czytelnik\u00f3w, a proxy trzyma gotowe po\u0142\u0105czenia z serwerem \u017ar\u00f3d\u0142owym, mo\u017cesz zr\u00f3wnowa\u017cy\u0107 koszt dodatkowego przeskoku. Jalvo to na przyk\u0142ad reverse proxy na NGINX z europejskimi i ameryka\u0144skimi adresami IP<\/a>, wi\u0119c wynik zale\u017cy od tego, gdzie proxy stoi wzgl\u0119dem Twojego serwera \u017ar\u00f3d\u0142owego i Twoich odbiorc\u00f3w.<\/p>\n\n\n\n Por\u00f3wnaj ten sam adres URL przez proxy i bezpo\u015brednio na serwerze \u017ar\u00f3d\u0142owym, z tej samej lokalizacji, wielokrotnie. Jedno \u017c\u0105danie nie m\u00f3wi prawie nic. Szum w sieci mocno rozrzuca pojedyncze wyniki.<\/p>\n\n\n\n Dane z rzeczywistego ruchu da Ci Navigation Timing API albo biblioteka web-vitals, kt\u00f3re raportuj\u0105 TTFB dla prawdziwych odwiedzaj\u0105cych. Resource Timing API obs\u0142uguje pozosta\u0142e \u017c\u0105dania, r\u00f3wnie\u017c te do innych domen. Uwaga jednak: zasoby z tej samej domeny mog\u0105 pokazywa\u0107 zero, bo po\u0142\u0105czenie jest ju\u017c otwarte albo plik pochodzi z cache. Czytaj\u0105c wyniki, patrz na r\u00f3\u017cnice. Wi\u0119ksza r\u00f3\u017cnica w czasie po\u0142\u0105czenia i TLS wskazuje na koszt sieci. R\u00f3\u017cnica tylko w czasie do pierwszego bajtu? To backend.<\/p>\n\n\n\n Najwi\u0119kszy zysk po stronie proxy daje ponowne u\u017cywanie po\u0142\u0105cze\u0144 z serwerem \u017ar\u00f3d\u0142owym zamiast otwierania nowego przy ka\u017cdym \u017c\u0105daniu. Na w\u0142asnym NGINX sprowadza si\u0119 to do trzech ustawie\u0144:<\/p>\n\n\n\n Trzymaj proxy i serwer \u017ar\u00f3d\u0142owy blisko siebie w sieci i nie \u0142\u0105cz kilku proxy w \u0142a\u0144cuch, bo ka\u017cda warstwa dok\u0142ada w\u0142asny przeskok. Dla jasno\u015bci: to ustawienia Twojego serwera \u017ar\u00f3d\u0142owego albo Twojego w\u0142asnego NGINX, a nie opcje w panelu Jalvo. A je\u015bli w pomiarach dominuje czas przetwarzania po stronie backendu, najpierw napraw serwer \u017ar\u00f3d\u0142owy. \u017badne strojenie proxy nie ukryje wolnej aplikacji.<\/p>\n\n\n\n Je\u015bli serwer \u017ar\u00f3d\u0142owy jest wolny ju\u017c przy bezpo\u015brednim po\u0142\u0105czeniu, usuni\u0119cie proxy nie poprawi TTFB. Typowi winowajcy po stronie serwera \u017ar\u00f3d\u0142owego: ci\u0119\u017ckie zapytania do bazy danych, brak cache stron w CMS, przeci\u0105\u017cony hosting wsp\u00f3\u0142dzielony.<\/p>\n\n\n\n Oznaki, \u017ce winny jest backend, a nie sie\u0107:<\/p>\n\n\n\n Nie masz pewno\u015bci, czy proxy w og\u00f3le pasuje do Twojej konfiguracji? Zanim cokolwiek zmienisz, zastan\u00f3w si\u0119, kiedy proxy jest w\u0142a\u015bciwym narz\u0119dziem<\/a>.<\/p>\n\n\n\nJaki TTFB jest dobry i dlaczego ma znaczenie dla SEO<\/h2>\n\n\n\n
Gdzie reverse proxy dodaje op\u00f3\u017anienie<\/h2>\n\n\n\n
Jak zmierzy\u0107 TTFB reverse proxy przed zmian\u0105 i po niej<\/h2>\n\n\n\n
\n
curl -o \/dev\/null -s -w \"connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}n\" https:\/\/example.com\/<\/code><\/li>\n--resolve example.com:443:ORIGIN_IP<\/code> albo wpisem w pliku hosts, \u017ceby certyfikat nadal pasowa\u0142.<\/li>\nKeepalive do upstreamu i inne ustawienia na w\u0142asnym NGINX<\/h2>\n\n\n\n
\n
upstream<\/code> z dyrektyw\u0105 keepalive<\/code>, kt\u00f3ra utrzymuje otwarte bezczynne po\u0142\u0105czenia,<\/li>\nproxy_http_version 1.1;<\/code> w bloku location, kt\u00f3ry przekazuje ruch,<\/li>\nproxy_set_header Connection \"\";<\/code>, \u017ceby wyczy\u015bci\u0107 nag\u0142\u00f3wek, kt\u00f3ry inaczej zamyka\u0142by ka\u017cde po\u0142\u0105czenie.<\/li>\n<\/ul>\n\n\n\nKiedy to nie proxy odpowiada za wolny TTFB<\/h2>\n\n\n\n
\n
Co zrobi\u0107 z wynikami TTFB<\/h2>\n\n\n\n