Czas odpowiedzi serwera: od czego zacząć diagnozę wolnego sklepu

Czas odpowiedzi serwera PrestaShop to liczba, od której zaczyna się każda sensowna diagnoza wydajności. Mierzy odcinek od wysłania żądania przez przeglądarkę do otrzymania pierwszego bajtu odpowiedzi, czyli wszystko, co dzieje się po stronie sklepu: pracę PHP, zapytania do bazy, odczyty z cache i połączenia do usług zewnętrznych. Dopóki ta liczba jest wysoka, żadna praca nad obrazami ani skryptami nie da efektu, bo przeglądarka nie ma jeszcze czego wyświetlać.

Ten tekst pokazuje, jak zmierzyć czas odpowiedzi wiarygodnie, jak rozłożyć go na składniki i co robić z każdym z nich.

Co składa się na czas odpowiedzi

Ta jedna liczba zawiera kilka odcinków, które warto rozdzielić, bo każdy naprawia się inaczej.

Rozróżnienie ma konsekwencję praktyczną. Wysoki czas odpowiedzi przy pojedynczej wizycie wskazuje na wykonanie aplikacji albo na usługi zewnętrzne. Wysoki dopiero przy wielu jednoczesnych wizytach wskazuje na kolejkowanie i na zasoby serwera. To dwie różne rozmowy i dwa różne budżety.

Czas odpowiedzi serwera PrestaShop: jak zmierzyć go wiarygodnie

Pojedynczy pomiar niczego nie dowodzi, bo pierwsza odpowiedź bywa serwowana z cache albo przeciwnie, trafia w moment odbudowy. Potrzebujesz trzech porównań.

Z cache i bez cache

Pobierz tę samą stronę dwa razy z rzędu i porównaj czasy. Jeśli drugie pobranie nie jest wyraźnie szybsze, strona nie jest serwowana z cache i to jest twój pierwszy wniosek. Powtórz dla strony głównej, listingu kategorii i karty produktu, bo każdy szablon może zachowywać się inaczej, a element zależny od użytkownika potrafi wyłączyć buforowanie tylko na jednym z nich.

Pojedyncza wizyta i kilkanaście jednoczesnych

Czas odpowiedzi przy jednym żądaniu mówi o konfiguracji. Czas przy kilkunastu równoległych mówi o tym, ile sklep uniesie. Sklep bywa poprawny w pierwszym pomiarze i rozsypuje się w drugim, a to właśnie drugi decyduje o tym, co się stanie w tygodniu największej sprzedaży. Pomiar wykonuj poza godzinami szczytu i uprzedź osobę administrującą serwerem, żeby nie potraktowała ruchu jako ataku.

O różnych porach doby

Na hostingu współdzielonym wieczorne pomiary bywają wyraźnie gorsze od porannych, bo zasoby dzielisz z innymi. Jeśli różnica jest duża i powtarzalna, żadna optymalizacja po stronie aplikacji tego nie przeskoczy, a wnioskiem jest zmiana środowiska, nie kolejne poprawki w sklepie.

Wszystkie trzy pomiary wykonuj na adresach bez parametrów omijających cache. Dodanie takiego parametru pokazuje wersję generowaną na świeżo, więc mierzysz wtedy najgorszy możliwy przypadek zamiast tego, czego doświadcza klient.

Gdy czas zjada aplikacja

Objaw: pojedyncza wizyta jest wolna, obciążenie serwera niewielkie, druga próba nie jest szybsza od pierwszej. Cztery najczęstsze przyczyny, uporządkowane od najtańszej do usunięcia.

Cache wyłączony albo omijany. Najczęstszy przypadek i najtańszy w naprawie. Element wyświetlający treść zależną od zalogowanego użytkownika, licznik koszyka renderowany po stronie serwera albo moduł rekomendacji potrafi wyłączyć buforowanie całej strony. Sklep ma wtedy skonfigurowany cache i nie korzysta z niego tam, gdzie zależy najbardziej. Rozwiązaniem jest wyjęcie dynamicznego elementu poza buforowaną stronę i dociąganie go osobno.

Moduł odpytujący usługę zewnętrzną w trakcie generowania strony. Sklep czeka na odpowiedź obcego serwera, a jeśli ten nie odpowiada, strona ładuje się aż do przekroczenia limitu czasu. Objawia się to losowymi długimi ładowaniami, których nie da się odtworzyć na żądanie. Takie odpytania należą do zadań w tle, nie do żądania klienta.

Zapytania do bazy w pętli. Widoczne przede wszystkim na listingach. Sposób wykrycia: policz zapytania przy dziesięciu i przy pięćdziesięciu produktach na stronie. Jeśli liczba rośnie proporcjonalnie, któryś moduł odpytuje bazę osobno dla każdego produktu. Ten wątek rozkładamy szerzej w tekście o wydajności listingu PrestaShop.

Rozrośnięte tabele. Logi, statystyki, porzucone koszyki i sesje gości narastają latami. Zajmują wielokrotnie więcej miejsca niż realne zamówienia i spowalniają zapytania, które muszą je przeglądać. Czyszczenie jest pracą jednorazową o przewidywalnym zakresie.

Gdy czas zjada serwer

Objaw: pojedyncza wizyta wypada przyzwoicie, ale czas odpowiedzi rośnie wraz z ruchem, a wieczorem jest gorzej niż rano.

Reverse proxy przed sklepem jest tu zmianą o największym wpływie. Vinyl cache, znany do 2026 roku jako Varnish Cache, to standard branżowy, a nie autorskie rozwiązanie. Serwuje gotowe strony bez uruchamiania PHP i bez odpytywania bazy, więc czas odpowiedzi przestaje rosnąć wraz z liczbą jednoczesnych wizyt. Warunkiem jest poprawna lista wykluczeń: koszyk, wszystkie kroki checkoutu, konto klienta i strony z indywidualnymi cenami muszą zostać poza buforowaniem. Pomyłka w tym miejscu oznacza pokazanie jednemu klientowi koszyka drugiego.

Liczba procesów PHP decyduje o tym, ile żądań serwer obsłuży równolegle. Zbyt mała powoduje kolejkowanie, zbyt duża wyczerpuje pamięć i kończy się jeszcze gorzej. To parametr do dobrania przez osobę administrującą serwerem, na podstawie realnego ruchu i dostępnej pamięci.

Wersja PHP i pamięć podręczna kodu. Nowsze wersje wykonują ten sam kod szybciej, a mechanizm buforujący skompilowany kod eliminuje powtarzalną pracę przy każdym żądaniu. Oba ustawienia są po stronie serwera i nie wymagają zmian w sklepie, ale aktualizacja wersji PHP wymaga sprawdzenia zgodności modułów, więc idzie przez środowisko testowe.

Parametry hostingu i dobór środowiska prowadzimy w ramach usługi optymalizacja wydajności PrestaShop, bo to decyzja na lata, a nie pojedyncza poprawka.

Zadania w tle, które spowalniają sklep w losowych momentach

Objaw jest charakterystyczny i przez to mylący: sklep działa sprawnie, ale kilka razy dziennie odpowiada zauważalnie wolniej, bez powtarzalnego wzorca. Nikt nie potrafi tego odtworzyć na żądanie, więc problem trafia do kategorii „czasem tak ma”.

Przyczyną są zwykle zadania uruchamiane cyklicznie: import z systemu ERP, synchronizacja stanów magazynowych, generowanie plików produktowych do porównywarek, wysyłka wiadomości, przeliczanie statystyk. Każde z nich obciąża bazę, a jeśli działają na tym samym serwerze co sklep, konkurują o zasoby z ruchem klientów.

Cztery rzeczy do sprawdzenia:

• Pory uruchamiania. Zadania ciężkie przenieś poza godziny sprzedaży. Import odpalany w południe to decyzja, nie konieczność.
• Nakładanie się zadań. Jeśli import trwa dłużej niż odstęp między uruchomieniami, drugie zadanie startuje przed zakończeniem pierwszego i oba walczą o bazę. Zabezpieczenie przed równoległym uruchomieniem rozwiązuje to raz.
• Sposób wyzwalania. Zadania uruchamiane przez ruch użytkowników zamiast przez harmonogram systemowy obciążają losowego klienta, który akurat wszedł na stronę. Harmonogram po stronie serwera jest tu jedynym sensownym rozwiązaniem.
• Unieważnianie cache po imporcie. Import zwykle omija ścieżkę, która automatycznie czyści cache, więc trzeba wywołać je osobno. Inaczej sklep pokazuje ceny i stany sprzed importu.

Diagnoza polega na zestawieniu wykresu czasu odpowiedzi z harmonogramem zadań. Jeśli szczyty pokrywają się z godzinami uruchomień, masz odpowiedź w pięć minut. To jeden z powodów, dla których warto prowadzić monitoring wydajności PrestaShop, a nie tylko doraźne pomiary.

Panel administracyjny to też czas odpowiedzi

Panel bywa wolniejszy od sklepu i zwykle nikt tego nie mierzy, bo klienci go nie widzą. Widzi go za to zespół, po kilka godzin dziennie, a każde oczekiwanie na wczytanie listy zamówień mnoży się przez liczbę wejść i liczbę osób.

Panel nie korzysta z buforowania stron, więc pokazuje surowy czas wykonania aplikacji i zapytań. Jest przez to wygodnym miernikiem stanu bazy: jeśli lista zamówień z domyślnym filtrem wczytuje się zauważalnie długo, masz odpowiedź o kondycji tabel, zanim jeszcze zajrzysz do bazy.

Trzy typowe przyczyny wolnego panelu: rozrośnięte tabele logów i statystyk, moduły dokładające własne zapytania do widoku listy zamówień oraz brak indeksów na kolumnach używanych do filtrowania po dołożeniu własnych pól. Prosty rachunek, który uzasadnia prace: zmierz czas wczytania listy zamówień i pomnóż przez liczbę wejść dziennie razy liczba osób w zespole. Wynik w godzinach miesięcznie zwykle wystarcza.

Jak rozmawiać z dostawcą hostingu

Zgłoszenie „sklep działa wolno” dostaje zwykle odpowiedź „u nas wszystko sprawne”, i obie strony mają rację, bo mówią o różnych rzeczach. Dostawca patrzy na dostępność serwera, Ty na czas odpowiedzi aplikacji.

Zgłoszenie, na które da się odpowiedzieć, zawiera cztery elementy: konkretny adres strony, czas odpowiedzi zmierzony przez Ciebie, porę pomiaru oraz informację, czy problem występuje stale, czy tylko pod obciążeniem. Do tego jedno pytanie zamknięte, na przykład o liczbę dostępnych procesów PHP albo o to, czy sklep w danym momencie nie przekraczał limitów.

Warto ustalić trzy rzeczy, zanim uznasz, że winny jest serwer:

• Czy sklep dobija do limitów. Wyczerpanie pamięci albo liczby procesów objawia się jako spowolnienie, a nie jako błąd, więc nie widać go w logach aplikacji.
• Jaka jest wersja PHP i czy działa pamięć podręczna kodu. Oba ustawienia są po stronie serwera i oba mają wymierny wpływ.
• Czy baza działa na tym samym serwerze. Przy współdzieleniu zasobów obciążenie bazy przez zadania w tle odbija się na czasie odpowiedzi sklepu.

Zmiana hostingu jest decyzją na lata i nie warto jej podejmować pod wpływem jednego złego tygodnia. Warto natomiast podjąć ją bez zwłoki, gdy pomiary o różnych porach powtarzalnie pokazują wysoką odpowiedź niezależnie od zmian w sklepie. Wtedy każda kolejna optymalizacja aplikacji jest pracą u podstaw postawionych na piasku.

Czego nie robić przy wysokim czasie odpowiedzi

Nie dokładaj CDN jako pierwszego kroku. Sieć dostarczania treści skraca dystans do plików statycznych, ale nie przyspiesza generowania strony. Sklep, którego serwer długo składa odpowiedź, będzie ją składał tak samo długo niezależnie od tego, ile punktów obecności ma dostawca.

Nie zwiększaj limitów pamięci w ciemno. Podniesienie limitu bez ustalenia, co go wyczerpuje, maskuje objaw i przesuwa awarię w czasie. Sensowniej znaleźć zapytanie albo moduł, który pobiera do pamięci cały katalog.

Nie wyłączaj modułów na produkcji, żeby zdiagnozować problem. Metoda działa, ale w godzinach sprzedaży oznacza wyłączanie płatności albo dostaw dla realnych klientów. To praca na środowisku testowym.

Co warto mierzyć na stałe

Czas odpowiedzi jest wskaźnikiem, który najszybciej reaguje na zmiany w sklepie, więc nadaje się na stały punkt kontrolny. Wystarczy jeden adres, mierzony o tej samej porze, i porównanie do średniej z poprzedniego tygodnia zamiast do wartości bezwzględnej.

Skokowy wzrost zawsze oznacza konkretną zmianę: nowy moduł, aktualizację, import albo wyłączony cache. Powolny wzrost przez kilka tygodni oznacza zwykle rosnące tabele w bazie albo przyrost katalogu. Rozróżnienie tych dwóch wzorców oszczędza godziny diagnozy, a wymaga jedynie regularnego zapisu jednej liczby.

Kolejność prac i do czego dążyć

Nie ma oficjalnego progu dla czasu odpowiedzi tak jednoznacznego jak progi Core Web Vitals, bo wskaźnik ten jest składnikiem LCP, a nie osobnym kryterium. Praktyczny cel wynika z arytmetyki: skoro LCP ma zmieścić się poniżej 2,5 s, a po otrzymaniu odpowiedzi przeglądarka musi jeszcze pobrać style, czcionki i zdjęcie główne, to na samą odpowiedź serwera zostaje ułamek tego budżetu. Definicje i sposób liczenia opisuje dokumentacja Google na web.dev.

1. Sprawdź, czy cache w ogóle działa. Dwa pobrania tej samej strony. Kwadrans, a rozstrzyga kierunek całej dalszej pracy.
2. Znajdź elementy omijające buforowanie. Zwykle jeden moduł na jednym szablonie.
3. Wyeliminuj odpytania usług zewnętrznych z generowania strony. Przenieś je do zadań w tle.
4. Wyczyść rozrośnięte tabele i dołóż brakujące indeksy. Praca jednorazowa, efekt widoczny też w panelu.
5. Wdroż reverse proxy. Dopiero teraz, gdy wiadomo, co jest dynamiczne i musi zostać poza cache.
6. Dobierz parametry serwera albo zmień środowisko. Ostatnie, bo najdroższe i najtrudniejsze do cofnięcia.

Odwrócenie tej kolejności jest najczęstszym sposobem przepalenia budżetu. Mocniejszy serwer dołożony do sklepu, który nie korzysta z cache i odpytuje zewnętrzną usługę przy każdym wyświetleniu strony, kupuje kilka miesięcy spokoju i wraca do punktu wyjścia razem ze wzrostem ruchu.

Gdy czas odpowiedzi zejdzie do rozsądnego poziomu, wąskim gardłem staje się to, co dzieje się w przeglądarce. Wtedy przenosisz uwagę na optymalizację obrazów PrestaShop i na optymalizację skryptów PrestaShop. Kolejność wszystkich obszarów porządkuje przewodnik o optymalizacji PrestaShop.