TTFB w sklepie internetowym: jak znaleźć wolny serwer

TTFB w sklepie internetowym: co właściwie mierzy ten parametr

TTFB to czas od rozpoczęcia żądania do momentu, w którym przeglądarka zaczyna otrzymywać pierwsze dane odpowiedzi. Skrót pochodzi od angielskiego Time to First Byte. W praktyce wynik obejmuje nie tylko pracę samej aplikacji, ale również część drogi sieciowej, zestawienie połączenia, DNS, TLS oraz czas oczekiwania na odpowiedź serwera.

To istotne rozróżnienie, ponieważ wysoki TTFB nie zawsze oznacza słaby hosting. Jeżeli sklep przez długi czas generuje HTML, przyczyną może być wolny kod PHP, zapytania do MySQL lub MariaDB, zewnętrzne API, brak cache albo przeciążony proces PHP. Z kolei jeżeli nawet bardzo prosta, statyczna odpowiedź z tego samego serwera pojawia się z dużym opóźnieniem, podejrzenie powinno paść raczej na infrastrukturę lub sieć.

TTFB jest mierzony przed FCP i LCP, więc opóźnienie na tym etapie może przesunąć kolejne momenty ładowania strony. Nie oznacza to jednak, że każdą stronę trzeba doprowadzić do identycznego wyniku. W dokumentacji web.dev wartość około 0,8 sekundy jest podawana jako orientacyjny cel dla większości witryn, natomiast sam TTFB nie jest Core Web Vitals. Wynik trzeba interpretować razem z tym, jak sklep generuje i dostarcza treść.

Jeżeli podczas audytu widzisz wysoki TTFB, nie zaczynaj od zmiany hostingu. Najpierw ustal, gdzie dokładnie powstaje opóźnienie.

Jak sprawdzić TTFB sklepu bez zgadywania

Najprostszy pomiar możesz wykonać w Chrome. Otwórz stronę sklepu, uruchom Narzędzia deweloperskie i przejdź do zakładki Network. Odśwież stronę, wybierz główne żądanie dokumentu HTML i sprawdź szczegóły czasu oczekiwania na odpowiedź.

W widoku Network interesuje Cię przede wszystkim żądanie typu Document. Nie analizuj w pierwszej kolejności obrazów, plików CSS czy JavaScriptu, ponieważ odpowiadają one za inne etapy ładowania. Jeżeli główna odpowiedź HTML długo czeka na pierwszy bajt, problem znajduje się przed dostarczeniem dokumentu do przeglądarki.

Możesz również sprawdzić TTFB z poziomu JavaScriptu za pomocą Navigation Timing API. W konsoli przeglądarki przydatny jest prosty pomiar:

performance.getEntriesByType('navigation')[0].responseStart

Otrzymana wartość jest podawana w milisekundach od początku nawigacji. MDN wskazuje responseStart jako parametr pozwalający odczytać TTFB dla głównego żądania nawigacji.

Nie opieraj diagnozy na jednym odświeżeniu. Wykonaj kilka pomiarów, najlepiej w trybie bez cache oraz po ponownym załadowaniu strony. Porównaj również stronę główną, kategorię, produkt, koszyk i wyszukiwanie. Jeżeli każda z nich ma podobnie wysoki czas oczekiwania, szukaj przyczyny wspólnej dla całego sklepu. Jeżeli tylko jedna sekcja jest wolna, bardziej prawdopodobna jest przyczyna związana z generowaniem konkretnego widoku.

Przydatny jest również test z kilku lokalizacji. TTFB obejmuje część czasu potrzebnego na DNS, zestawienie połączenia i przesłanie żądania do serwera. Sklep obsługujący klientów w Polsce może mieć inny wynik mierzony z Polski niż z odległego regionu. Różnica między lokalizacjami może wskazywać na problem sieciowy, geograficzne oddalenie serwera albo konfigurację CDN.

Nie porównuj bezpośrednio wyników z różnych narzędzi bez sprawdzenia, co dokładnie mierzą. TTFB może być przedstawiany w różny sposób zależnie od narzędzia i konfiguracji odpowiedzi HTTP.

Wolny serwer sklepu czy wolna aplikacja?

To najważniejsze pytanie podczas diagnozy. Sklep może działać na dobrym VPS-ie, a mimo to generować stronę przez kilka sekund. Może też mieć prostą aplikację, która odpowiada szybko, ale serwer jest przeciążony i opóźnia każdą odpowiedź.

Dobrym testem jest porównanie kilku rodzajów zasobów. Jeżeli masz możliwość, przygotuj prosty statyczny plik HTML umieszczony na tym samym serwerze i domenie lub w tej samej infrastrukturze. Następnie porównaj jego odpowiedź z odpowiedzią generowaną przez sklep.

Jeżeli statyczny plik odpowiada szybko, a strona produktu ma wysoki TTFB, infrastruktura sieciowa prawdopodobnie nie jest jedynym problemem. Wtedy przechodzisz do PHP, bazy danych, modułów i logiki aplikacji.

Jeżeli także statyczny plik odpowiada wolno, trzeba sprawdzić serwer, sieć, DNS, reverse proxy, obciążenie CPU, pamięć, dysk oraz konfigurację usług. W takim przypadku instalowanie kolejnych wtyczek cache może tylko zamaskować problem.

Podobny test możesz wykonać na kilku stronach sklepu. Jeżeli strona główna odpowiada szybko, ale wyszukiwanie produktów potrzebuje dużo więcej czasu, nie ma sensu zaczynać od wymiany całego hostingu. Szukasz wtedy operacji wykonywanych podczas wyszukiwania.

Jeżeli natomiast nawet prosta strona kategorii, która powinna korzystać z cache, ma wysoki czas odpowiedzi, sprawdź konfigurację cache oraz serwer WWW. Przy okazji można ocenić, czy opóźnienia widoczne w INP sklepu nie wynikają z osobnego problemu po stronie przeglądarki. INP i TTFB mierzą inne fragmenty procesu, dlatego nie należy traktować ich jako zamiennych wskaźników.

Co powoduje wysoki TTFB w sklepie internetowym

Hosting i zasoby serwera

Pierwszym podejrzanym jest infrastruktura, ale nie zawsze słusznie. Sprawdź obciążenie CPU, wykorzystanie pamięci RAM, swap, obciążenie dysku oraz liczbę aktywnych procesów PHP. Na hostingu współdzielonym dodatkowym problemem może być konkurencja o zasoby z innymi stronami.

Jeżeli TTFB rośnie w godzinach największego ruchu, korelacja z obciążeniem serwera jest mocnym sygnałem diagnostycznym. Nie oznacza jeszcze, że trzeba kupić większy serwer. Najpierw sprawdź, co zużywa zasoby.

Na VPS-ie zweryfikuj między innymi procesy PHP-FPM, serwer WWW oraz bazę danych. Warto sprawdzić również limity procesów PHP i sytuacje, w których wszystkie dostępne workery są zajęte. Sklep może wtedy czekać na wolny proces, nawet jeżeli średnie wykorzystanie CPU nie wygląda dramatycznie.

PHP i aplikacja sklepu

WooCommerce, PrestaShop i inne platformy e-commerce wykonują podczas generowania strony wiele operacji. Ładowane są moduły, wykonywane są zapytania do bazy, sprawdzane są ceny, stany magazynowe, reguły promocji, warianty, koszyki i dane użytkownika.

Problemem może być również moduł, który wykonuje kosztowną operację przy każdym żądaniu. Dotyczy to szczególnie dodatków integrujących sklep z zewnętrznymi usługami, systemami magazynowymi, porównywarkami cen czy API.

Jeżeli po wyłączeniu konkretnego modułu TTFB wyraźnie się zmienia, masz punkt zaczepienia. Test wykonuj na kopii sklepu lub w kontrolowanym środowisku, ponieważ wyłączanie modułów na produkcji może zmienić działanie sklepu.

Jeżeli sklep zwraca błędy PHP, nie ignoruj ich tylko dlatego, że strona finalnie się wyświetla. Ostrzeżenia, wyjątki i nieefektywne operacje mogą zwiększać czas generowania odpowiedzi. Gdy TTFB jest bardzo wysoki i jednocześnie występują błędy aplikacji, pomocna będzie również diagnostyka błędów 500 w sklepie, ponieważ część problemów z wydajnością może mieć wspólną przyczynę w kodzie lub konfiguracji.

Baza danych

W sklepie internetowym baza danych często jest miejscem, którego nie widać w zwykłym pomiarze TTFB. Przeglądarka widzi tylko to, że długo czeka na pierwszy bajt. PHP może w tym czasie wykonywać serię zapytań SQL.

Szczególnie podejrzane są zapytania wykonywane na dużych tabelach bez odpowiednich indeksów, pobieranie zbyt wielu rekordów, wielokrotne odpytywanie tej samej tabeli oraz zapytania związane z filtrowaniem produktów, wariantami i wyszukiwaniem.

Jeżeli wolna jest przede wszystkim wyszukiwarka sklepu, zacznij od analizy zapytań wykonywanych dla wyszukiwania. Jeżeli wolne są strony produktów, sprawdź zapytania dotyczące atrybutów, wariantów, cen, stanów magazynowych i powiązanych produktów.

Nie zakładaj, że baza danych jest wolna tylko dlatego, że ma dużo rekordów. Liczy się sposób wykonywania zapytań, indeksy, konfiguracja serwera bazy i ilość pracy wykonywanej podczas pojedynczego żądania.

Cache

Brak cache może sprawić, że każda wizyta uruchamia pełne generowanie strony. W przypadku sklepu część stron może być jednak cache’owana, a część musi być generowana dynamicznie.

Sprawdź nagłówki odpowiedzi oraz konfigurację mechanizmu cache. Jeżeli po pierwszym wejściu odpowiedź jest wolna, a kolejne wejścia są znacznie szybsze, cache prawdopodobnie uczestniczy w obsłudze żądania. Jeżeli każda odpowiedź trwa podobnie długo, sprawdź, czy cache rzeczywiście działa i czy nie jest omijany przez ciasteczka, parametry URL lub konfigurację aplikacji.

Parametry śledzące w adresach mogą również wpływać na wykorzystanie cache. web.dev zwraca uwagę, że unikalne parametry URL mogą powodować kierowanie żądań do serwera źródłowego zamiast wykorzystania wcześniej zapisanej odpowiedzi z warstwy cache.

Sieć, DNS i TLS

TTFB obejmuje również etap poprzedzający właściwe generowanie strony. DNS, zestawienie połączenia TCP oraz negocjacja TLS mogą dołożyć własne opóźnienie.

Jeżeli problem występuje głównie dla użytkowników z określonych regionów, porównaj wyniki z różnych lokalizacji. Sprawdź rekordy DNS, miejsce uruchomienia serwera, CDN oraz trasę połączenia.

Wysoki TTFB wynikający z sieci będzie wyglądał inaczej niż wysoki TTFB spowodowany przez PHP. W pierwszym przypadku opóźnienie pojawia się przed rozpoczęciem właściwej odpowiedzi aplikacji. W drugim przeglądarka nawiązuje połączenie, ale potem długo czeka na dane.

Jak odróżnić problem całego serwera od jednej strony

Najprostsza metoda to porównanie kilku adresów o różnym stopniu złożoności. Sprawdź stronę główną, kategorię, produkt, wyszukiwarkę, koszyk oraz prosty zasób statyczny.

Jeżeli wszystkie odpowiedzi mają podobnie wysoki TTFB, zacznij od infrastruktury, sieci, serwera WWW, PHP-FPM i wspólnych elementów aplikacji. Jeżeli tylko produkt jest wolny, sprawdzaj logikę strony produktu. Jeżeli wolne jest wyszukiwanie, analizuj wyszukiwanie i zapytania SQL. Jeżeli koszyk jest wolny, sprawdź operacje zależne od sesji i danych użytkownika.

Przydatne jest również porównanie odpowiedzi z cache i bez cache. Jeżeli wersja z cache odpowiada szybko, a wersja dynamiczna długo, problem leży raczej w generowaniu strony niż w podstawowej komunikacji z serwerem.

W sklepie wielojęzycznym wykonaj test dla kilku języków. Jeżeli tylko jeden wariant językowy ma wysoki TTFB, sprawdź jego moduły, zapytania i sposób generowania danych. Nie zakładaj od razu, że problem wynika z samego serwera.

Jeżeli podczas testów widzisz również błędy przekierowań, najpierw sprawdź ich liczbę. Każdy dodatkowy redirect może dołożyć czas przed uzyskaniem właściwej odpowiedzi HTML. Podobnie trzeba uważać na niepotrzebne przekierowania między wersjami HTTP, HTTPS, www i bez www.

Diagnostyka krok po kroku

Najpierw wykonaj pomiar strony głównej i kilku reprezentatywnych podstron. Zapisz wyniki osobno dla cache i dla pierwszego żądania. Nie wyciągaj wniosków na podstawie jednej strony.

Następnie sprawdź Network w Chrome i zobacz, jak długo główne żądanie dokumentu czeka na odpowiedź. Jeżeli możesz, porównaj wyniki z różnych lokalizacji.

Kolejny etap to serwer. Sprawdź obciążenie CPU, RAM, swap, dysk, PHP-FPM i bazę danych. Jeżeli TTFB rośnie równocześnie z obciążeniem, przeanalizuj procesy odpowiedzialne za wzrost zużycia zasobów.

Potem przejdź do aplikacji. Sprawdź logi PHP, moduły, wtyczki oraz operacje wykonywane podczas generowania wolnej strony. W razie potrzeby wykonaj profilowanie kodu na środowisku testowym.

Dopiero później analizuj konkretne zapytania SQL. Szukaj zapytań wykonywanych wielokrotnie, operujących na dużej liczbie rekordów albo pozbawionych odpowiednich indeksów.

Na końcu zweryfikuj cache. Sprawdź, czy odpowiedź faktycznie jest cache’owana, kiedy cache jest omijany i czy parametry URL lub cookies nie powodują przejścia do dynamicznego generowania strony.

Jeżeli sklep korzysta z wielu zewnętrznych usług, sprawdź także czas ich odpowiedzi. Moduł może podczas generowania strony czekać na zewnętrzne API. Wtedy nawet mocny serwer nie rozwiąże problemu, ponieważ aplikacja nadal będzie oczekiwać na odpowiedź innego systemu.

Poniższa tabela pozwala szybko przypisać objaw do obszaru, który trzeba sprawdzić:

Źródło opóźnienia	Typowy sygnał	Co sprawdzić	Następny krok diagnostyczny
Hosting	Wysoki TTFB na wielu stronach	Obciążenie CPU, RAM, dysku i limity	Porównaj prosty plik statyczny z PHP
Serwer WWW	Opóźnienia także dla prostych żądań	Nginx, Apache, reverse proxy, konfigurację	Sprawdź logi i czasy odpowiedzi
PHP	HTML długo czeka na wygenerowanie	PHP-FPM, workery, błędy i profilowanie	Znajdź wolne fragmenty aplikacji
Baza danych	Wolne strony produktów, kategorii lub wyszukiwanie	Zapytania SQL, indeksy, obciążenie DB	Przeanalizuj najwolniejsze zapytania
Cache	Duża różnica między pierwszym i kolejnym wejściem	Nagłówki cache i reguły wykluczeń	Sprawdź, kiedy cache jest omijany
Zewnętrzne API	Wybrane funkcje są znacznie wolniejsze	Czas odpowiedzi usług zewnętrznych	Zmierz każde wywołanie osobno
DNS i sieć	Różne wyniki zależnie od lokalizacji	DNS, trasa, TLS, odległość serwera	Porównaj pomiary z różnych regionów
Konkretna strona	Tylko jeden typ URL jest wolny	Kod kontrolera, moduły i SQL	Profiluj generowanie danego widoku

Co zrobić, gdy TTFB jest wysoki tylko na produkcji

To częsty przypadek. Środowisko testowe może mieć mniej danych, mniej ruchu, mniej modułów i inną konfigurację cache. Po wdrożeniu sklep zaczyna wykonywać te same operacje na rzeczywistej bazie i przy rzeczywistym obciążeniu.

Nie porównuj więc wyłącznie wersji PHP lub parametrów serwera. Porównaj również dane, liczbę produktów, liczbę wariantów, konfigurację cache oraz zadania cron.

Sprawdź, czy w tle nie działa import produktów, synchronizacja stanów, generowanie indeksów albo integracja z zewnętrznym systemem. Takie zadania mogą chwilowo obciążyć bazę lub CPU i zmienić TTFB stron sklepu.

Jeżeli problem pojawił się po wdrożeniu nowego modułu, aktualizacji platformy albo zmianie konfiguracji serwera, porównaj moment wystąpienia problemu z historią zmian. To często pozwala zawęzić zakres diagnostyki szybciej niż przypadkowe wyłączanie kolejnych funkcji.

Jeżeli jednocześnie występują problemy z innymi sygnałami technicznymi, nie mieszaj ich w jedną diagnozę. Na przykład analiza INP, LCP i CLS w sklepie pomoże rozdzielić opóźnienia backendu od problemów występujących już po dostarczeniu dokumentu do przeglądarki.

Jak zmniejszyć TTFB sklepu bez wymiany hostingu w ciemno

Po ustaleniu źródła problemu dopiero wybierasz rozwiązanie. Jeżeli winny jest kod PHP, optymalizujesz operacje wykonywane podczas żądania. Jeżeli baza danych, analizujesz zapytania i indeksy. Jeżeli cache, poprawiasz jego konfigurację i reguły wykluczeń. Jeżeli serwer jest przeciążony, oceniasz konfigurację procesów oraz dostępne zasoby.

Nie zaczynaj od instalowania kolejnego systemu cache. Jeżeli strona wykonuje kosztowne zapytania SQL przed zapisaniem odpowiedzi do cache, cache może ograniczyć problem tylko dla części użytkowników i tylko w określonych warunkach.

Nie zaczynaj również od migracji na droższy VPS, jeśli nie wiesz, co obciąża obecny serwer. Większa maszyna może zwiększyć dostępne zasoby, ale nie naprawi błędnego zapytania SQL, wolnego API ani modułu wykonującego niepotrzebną pracę przy każdym żądaniu.

Jeżeli natomiast prosty plik statyczny, strona z cache i dynamiczna strona mają podobne opóźnienia, a problem występuje niezależnie od aplikacji, wtedy analiza hostingu i infrastruktury ma znacznie więcej sensu.

Podczas audytu szybkości można przejść tę ścieżkę metodycznie: najpierw zmierzyć, później rozdzielić sieć od backendu, następnie PHP od bazy danych, a na końcu wskazać konkretny element generujący opóźnienie. Taki sposób pracy jest bardziej użyteczny niż sama informacja, że sklep ma wysoki TTFB.

Jeżeli nie wiesz, czy problem znajduje się po stronie serwera, aplikacji czy bazy danych, audyt szybkości sklepu internetowego pozwala zacząć od pomiarów i wskazania obszaru wymagającego dalszej diagnostyki.

TTFB a SEO sklepu internetowego

TTFB SEO warto traktować jako element technicznej wydajności, a nie jako samodzielny rankingowy cel. Wysoki TTFB opóźnia rozpoczęcie pobierania dokumentu HTML, a przez to może wpływać na dalsze etapy ładowania strony.

W praktyce nie chodzi o to, aby obsesyjnie ścigać pojedynczy wynik z testu. Jeżeli sklep ma dobry TTFB, ale ciężki JavaScript blokuje dalsze renderowanie, użytkownik nadal może czekać na właściwą treść. Jeżeli TTFB jest wysoki, ale reszta strony działa sprawnie, trzeba ustalić, czy poprawa backendu rzeczywiście jest głównym ograniczeniem.

Dlatego pomiar TTFB powinien być częścią większego audytu wydajności. Najpierw ustalasz, ile czasu zajmuje odpowiedź, potem szukasz miejsca powstawania opóźnienia i dopiero na tej podstawie wybierasz zmianę techniczną.

Etapy żądania HTTP wpływające na TTFB

Przebieg żądania zaczyna się od nawigacji i ewentualnych przekierowań. Następnie DNS, zestawienie połączenia TCP oraz negocjacja TLS. Kolejny etap to wysłanie żądania do serwera i oczekiwanie na przetworzenie. W tej fazie źródłem opóźnienia może być serwer WWW, PHP, aplikacja, cache, baza danych albo zewnętrzne API. Ostatni etap to rozpoczęcie odpowiedzi i nadejście pierwszego bajtu, czyli punkt pomiaru TTFB.

TTFB nie oznacza więc wyłącznie czasu pracy PHP. Obejmuje również część komunikacji sieciowej przed rozpoczęciem dostarczania odpowiedzi. Dlatego sam wynik TTFB nie pozwala jeszcze wskazać winnego komponentu.

Podsumowanie: jak znaleźć wolny serwer sklepu

Wysoki TTFB jest sygnałem do diagnostyki, a nie gotową diagnozą. Najpierw zmierz główne żądanie HTML, potem porównaj kilka typów stron i sprawdź, czy problem występuje również dla prostego zasobu statycznego.

Jeżeli wolny jest cały serwer, sprawdź hosting, sieć, DNS, serwer WWW i dostępne zasoby. Jeżeli wolna jest tylko aplikacja, przejdź do PHP, modułów, cache i bazy danych. Jeżeli wolny jest jeden typ strony, analizuj operacje charakterystyczne dla tego widoku.

Tak podejdziesz również do pytania, co powoduje wysoki TTFB: nie szukasz jednej uniwersalnej przyczyny, tylko eliminujesz kolejne warstwy odpowiedzialne za czas odpowiedzi serwera. Dopiero po takim pomiarze można zdecydować, czy potrzebna jest zmiana konfiguracji, optymalizacja kodu, poprawa zapytań SQL, lepszy cache czy zmiana infrastruktury. Takie poprawki po stronie serwera i aplikacji można zlecić w ramach optymalizacji szybkości sklepu.