Czy Twój sklep PrestaShop działa wolno? Najpierw zmierz, potem optymalizuj

Ostatnia aktualizacja: czerwiec 2026.

Gdy sklep PrestaShop sprawia wrażenie wolnego, najczęstsza reakcja bywa zarazem najdroższa: zainstalować moduł cache albo optymalizacji, włączyć każdy przełącznik i liczyć na efekt. Czasem to pomaga. Często nie zmienia nic — a niekiedy nawet pogarsza sytuację, bo prawdziwe wąskie gardło wcale nie znajduje się tam, gdzie działa moduł. Problemy z szybkością najpierw wymagają diagnozy. Uczciwa rada od każdego, kto zajmuje się tym zawodowo, jest prosta: najpierw mierz, potem optymalizuj. Znajdź faktyczną przyczynę, a dopiero potem wydaj pieniądze na rozwiązanie, które ją usuwa — co czasem oznacza, że nie trzeba wydawać nic.

Dlaczego zgadywanie tak dużo kosztuje

"Mój sklep działa wolno" to objaw, nie diagnoza. Przyczyna może leżeć w kilku zupełnie różnych miejscach, a narzędzie, które naprawia jedno z nich, nie zrobi nic z pozostałymi:

• Pojedynczy moduł wywołujący problem N+1 zapytań na każdej stronie produktu — jedno dodatkowe zapytanie dla każdego elementu w pętli, pomnożone przez Twój katalog.
• Ciężki szablon, który ładuje setki kilobajtów blokujących renderowanie CSS i JavaScript, zanim cokolwiek pojawi się na ekranie.
• Wolny TTFB (time to first byte) na przeciążonym hostingu współdzielonym albo serwerze bazy danych, który już dobił do limitu CPU lub IO.
• Niezoptymalizowane obrazy — pliki w pełnej rozdzielczości wysyłane na urządzenia mobilne, brak nowoczesnych formatów, brak prawidłowego skalowania.
• Brak pełnostronicowego cache, przez co PrestaShop buduje każdą stronę od zera dla każdego odwiedzającego.
• Instancja MySQL pozbawiona wystarczającej pamięci, wykonująca skanowanie tabel tam, gdzie powinien działać indeks.

Tu właśnie kryje się pułapka. Jeśli problemem jest szablon blokujący renderowanie i wolny TTFB, moduł cache stron może trochę przyspieszyć kolejne odsłony, ale nie poprawi pierwszego wrażenia — tego, które mierzy Google. Jeśli problemem jest przeciążona baza danych, żadna optymalizacja zasobów frontendu nie przyniesie zauważalnej poprawy. Możesz bez końca inwestować w niewłaściwą warstwę i nadal nie czuć różnicy. Dlatego traktujemy audyt wydajności jako pierwszy krok: pokazuje, która warstwa faktycznie kosztuje Cię czas, dzięki czemu kolejny zakup (jeśli w ogóle będzie potrzebny) trafia we właściwe miejsce.

Co naprawdę mierzy audyt wydajności

Rzetelny audyt to nie pojedynczy wynik w teście szybkości. Rozkłada stronę na rzeczywiste elementy i sprawdza, gdzie ucieka czas:

Czas serwera kontra czas przeglądarki

Pierwszy podział to TTFB kontra renderowanie po stronie frontendu. TTFB obejmuje wszystko, co dzieje się, zanim serwer wyśle pierwszy bajt — wykonanie PHP, zapytania do bazy danych, odczyty z cache. Renderowanie frontendowe to wszystko, co przeglądarka robi później z otrzymaną odpowiedzią. Strona ładująca się 3 sekundy, z czego 2,4 s przypada na TTFB, ma problem po stronie backendu; ta sama 3-sekundowa strona z TTFB 0,2 s i renderowaniem 2,8 s ma problem po stronie frontendu. Wymagają przeciwnych działań, a tylko pomiar mówi, z którym przypadkiem masz do czynienia.

Liczba zapytań na stronę i najwięksi winowajcy

Strony PrestaShop potrafią wykonywać od kilkudziesięciu do kilkuset zapytań SQL. Audyt liczy je dla każdego typu strony i wskazuje największych winowajców — często pojedynczy moduł, który powinien zapisywać odczyt w cache, ale odpytuje bazę przy każdym hooku. Znalezienie tego jednego zapytania bywa warte więcej niż dowolna liczba kolejnych warstw cache nałożonych na problem.

Narzut modułów

Każdy moduł podpięty do strony dodaje pracę, a niektóre podpinają się pod każdą stronę, niezależnie od tego, czy są tam potrzebne. Audyt profiluje, które moduły realnie zwiększają czas wykonania, a które uruchamiają się bez potrzeby, dzięki czemu możesz wyłączyć albo zastąpić prawdziwych winowajców zamiast zgadywać.

Waga zasobów i cache

Mierzy całkowitą wagę strony, liczbę żądań oraz to, jak dobrze skonfigurowane są CCC (combine-compress-cache), critical-CSS i odroczony JavaScript — albo czy w ogóle są skonfigurowane. Sprawdza też cały stos cache od początku do końca: współczynnik trafień pełnostronicowego cache, OPcache dla skompilowanego PHP oraz Redis dla cache obiektów/zapytań. Cache, który istnieje, ale rzadko trafia, jest prawie bezwartościowy — i tylko współczynnik trafień to ujawnia.

Limit hostingu, mobile i Core Web Vitals

Na końcu audyt patrzy na realia sprzętowe — zapas CPU, IO i pamięci pod obciążeniem — oraz testuje mobile oddzielnie od desktopu, bo większość ruchu i większość pomiarów Google dotyczy urządzeń mobilnych. To bezpośrednio łączy się z Core Web Vitals: LCP, CLS i INP. To nie są próżne metryki; to realny sygnał rankingowy, dlatego szybkość i wyszukiwanie tak często się przenikają, a techniczny audyt SEO oraz audyt wydajności tak często pokazują te same problemy.

Samodzielny test, który wykonasz w dziesięć minut

Nie musisz niczego zamawiać, żeby uzyskać pierwszy odczyt dla własnego sklepu. Otwórz stronę główną i obciążoną stronę produktu w Chrome, a potem zrób to:

• Uruchom waterfall. Otwórz DevTools, przejdź do karty Network, wykonaj twarde odświeżenie i spójrz na pierwsze żądanie. Czas "Waiting (TTFB)" pokazuje, ile dzieje się po stronie serwera. Wynik powyżej ~600 ms na rozgrzanym cache wskazuje na backend.
• Policz żądania i wagę. Stopka karty Network pokazuje łączną liczbę żądań i rozmiar przesłanych danych. Setki żądań albo kilka megabajtów na stronę to mocny sygnał dotyczący zasobów/CCC.
• Odczytaj profiler PrestaShop. Włącz tryb debugowania na kopii stagingowej i uruchom profiler — wypisze liczbę zapytań oraz najwolniejsze zapytania dla danej strony. Strona produktu wykonująca 250+ zapytań zasługuje na uwagę.
• Ogranicz mobile. W DevTools ustaw urządzenie na profil telefonu ze średniej półki z ograniczeniem "Slow 4G" i odśwież stronę. Jeśli doświadczenie tutaj się rozpada, właśnie to naprawdę odczuwa większość Twoich odwiedzających.

Te liczby są progami orientacyjnymi, nie gwarancjami — każdy sklep jest inny. Zwykle jednak wskażą właściwy kierunek, zanim ktokolwiek wyda choćby euro.

Zmierz TTFB z wiersza poleceń

Jeśli wolisz uzyskać precyzyjny czas serwera bez otwierania DevTools, curl pokazuje rozkład czasu bezpośrednio. To operacja tylko do odczytu — po prostu pobiera stronę i wypisuje, ile trwała każda faza:

# Print connection, TLS, TTFB and total time for one page load
curl -s -o /dev/null \
  -w "dns:    %{time_namelookup}s\nconnect: %{time_connect}s\nTLS:     %{time_appconnect}s\nTTFB:    %{time_starttransfer}s\ntotal:   %{time_total}s\n" \
  https://yourdomain.com/your-product-page

Najważniejsza liczba to tutaj TTFB (time_starttransfer): wszystko do pierwszego bajtu odpowiedzi. Uruchom polecenie kilka razy, żeby zimny cache nie zafałszował wyniku. Jeśli ta wartość pozostaje wysoka — wyraźnie powyżej pół sekundy na rozgrzanym cache — wąskie gardło znajduje się po stronie serwera (PHP, zapytania, hosting), a żadna optymalizacja zasobów frontendu tego nie naprawi. Jeśli TTFB jest niski, ale strona w przeglądarce nadal wydaje się wolna, koszt leży w renderowaniu i zasobach. Ten jeden podział jest całym powodem, dla którego warto mierzyć, zanim coś kupisz.

Uczciwy finał: co audyt każe zrobić

Cały sens mierzenia najpierw polega na tym, że werdykt często nie brzmi: "kup moduł optymalizacyjny". Dobry audyt kończy się jednym z kilku jasnych kierunków:

• To hosting. Jeśli TTFB jest wysoki nawet przy trafieniu w cache, a serwer dochodzi do limitu CPU/IO, żaden moduł tego nie naprawi — potrzebujesz lepszego hostingu albo dostrojonego stosu, a właśnie to określa zakres audytu hostingu.
• To konfiguracja. Często cache istnieje, ale jest źle skonfigurowany: CCC włączone tylko częściowo, OPcache za mały, Redis w rzeczywistości niepodłączony. To zmiana ustawień, nie zakup.
• To konkretny moduł albo szablon. Czasem jeden ciężki moduł albo nieefektywny szablon stanowi cały problem, a rozwiązaniem jest jego wymiana lub usunięcie.
• Naprawdę potrzebujesz narzędzia. Jeśli wąskim gardłem są zasoby frontendu i brak pełnostronicowego cache, celowany moduł z otwartym kodem, taki jak Performance Revolution, jest właściwym zakupem — ale dopiero gdy wiesz, że to właśnie ta warstwa kosztuje Cię czas, nie wcześniej.
• Wszystko już działa dobrze. Zdarza się, że audyt pokazuje zdrowy sklep, a odczuwalna powolność wynika z jednego wolnego skryptu zewnętrznego albo regionalnego problemu sieciowego. Taka wiedza chroni Cię przed "optymalizowaniem" czegoś, co nie jest zepsute.

Kupowanie w ciemno kończy się tym, że sklepy mają trzy nakładające się moduły cache i wolniejszą stronę niż na początku. Diagnoza przed zakupem jest tańsza, nawet jeśli sama coś kosztuje, bo zatrzymuje wydatki na niewłaściwą warstwę.

Jak zacząć

Jeśli zamiast popołudnia DIY wolisz uporządkowany odczyt, nasz audyt wydajności powstał dokładnie po to. Podajesz adres URL sklepu, najpierw uruchamia się szybka kontrola gotowości tylko do odczytu — bez przekazywania danych administratora; zobacz nasze notatki o gotowości sklepu do audytu, żeby sprawdzić, jak obsługujemy dostęp — i dopiero wtedy zamawiany jest audyt. To część naszych pozostałych usług eksperckich dla przypadków, w których rozwiązaniem okazuje się hosting, konfiguracja albo prace programistyczne, a nie produkt. Niezależnie od wyniku będziesz wiedzieć, dlaczego sklep jest wolny, zanim wydasz pieniądze na jego przyspieszenie — i właśnie ta część naprawdę oszczędza pieniądze.

Najczęściej zadawane pytania

Mam już zainstalowany moduł cache. Dlaczego mój sklep nadal działa wolno?

Bo cache pomaga tylko tej warstwie, w której działa. Pełnostronicowy cache nie zrobi nic z wolnym pierwszym bajtem na przeciążonej bazie danych, a optymalizator frontendu nie naprawi serwera, który dobił do limitu CPU. Często też cache jest zainstalowany, ale prawie nie ma trafień — CCC skonfigurowane połowicznie, OPcache za mały, Redis w rzeczywistości niepodłączony. Podział TTFB opisany wyżej pokazuje, czy Twoje wąskie gardło w ogóle leży w warstwie, na którą cache może wpłynąć. Często nie leży, dlatego moduł "nic nie dał".

Jaki TTFB jest "dobry" dla PrestaShop?

Orientacyjnie: poniżej ~200 ms jest zdrowo, ~200–600 ms jest akceptowalne, a stale ponad ~600 ms na rozgrzanym cache wskazuje na problem po stronie serwera, który warto zbadać. To okolice, nie twarde granice — ciężka strona produktu naturalnie wykonuje więcej pracy niż strona główna. Przydatne porównanie to własny sklep na zimno kontra na ciepło oraz TTFB zestawiony z czasem renderowania, który przeglądarka dodaje później. Ta proporcja, a nie pojedyncza liczba, mówi, w którą stronę kierować wydatki.

Czy audyt wydajności może zagwarantować, że mój sklep przyspieszy?

Nie — i uważaj na każdego, kto to obiecuje. Audyt mówi, dlaczego sklep jest wolny i które rozwiązanie usuwa przyczynę; nie wykonuje naprawy ani nie gwarantuje konkretnego wyniku. Jeśli przyczyną jest hosting, przyspieszenie zależy od nowego stosu; jeśli ciężki moduł, od tego, czy możesz go zastąpić; jeśli wszystko jest już w porządku, uczciwy wynik brzmi: "nie wydawaj nic". Wartością jest właściwe skierowanie budżetu, a nie obiecana liczba milisekund.

Czy audyt spowolni albo narazi mój działający sklep?

Nie. Kontrola gotowości i pomiary są tylko do odczytu — ładują strony tak, jak zrobiłby to odwiedzający, i zapisują czasy; nic nie jest zapisywane ani zmieniane. Krok z profilerem w samodzielnym teście to jedyna rzecz, którą należy wykonać na kopii stagingowej, a nie na produkcji, bo tryb debugowania ujawnia szczegóły wewnętrzne i dodaje narzut. Sam audyt nie wymaga trybu debugowania w sklepie produkcyjnym.

Czym różni się to od zwykłego uruchomienia PageSpeed Insights?

PageSpeed mierzy renderowanie frontendowe jednego URL-a i ocenia je względem Core Web Vitals — to naprawdę przydatne i warto z tego korzystać. Nie widzi jednak serwera: liczby zapytań, modułu uruchamianego przy każdym hooku, współczynnika trafień cache ani tego, czy prawdziwym limitem jest baza danych. Strona może mieć dobry wynik w PageSpeed, a mimo to działać wolno pod realnym obciążeniem katalogu, albo mieć słaby wynik z powodu, którego moduł nie naprawi. Audyt obejmuje backendową połowę, której PageSpeed nie widzi.

Powiązane artykuły

• Czy udostępnienie audytorowi dostępu do sklepu PrestaShop jest bezpieczne?
• Przedstawiamy Expert Services: audyty PrestaShop, zanim kupisz kolejny moduł
• Jak sprawdzić, czy Twój sklep PrestaShop potrzebuje audytu SEO
• Oznaki, że Twój sklep PrestaShop potrzebuje audytu bezpieczeństwa (i jak najpierw sprawdzić go samodzielnie)
• PrestaShop SEO: kompletny przewodnik po wyższych pozycjach