Jak przyspieszyć sklep PrestaShop

Publikacja: 9 września 2026 · Grzegorz Rapczyński

Wolny sklep traci klientów zanim zobaczą produkt. Nie chodzi o punkty w narzędziach pomiarowych, tylko o to, że część osób wychodzi w trakcie ładowania i nigdy nie wraca. Ten tekst opisuje, co realnie przyspiesza sklep na PrestaShop, w kolejności od rzeczy dających największy efekt.

Najpierw zmierz, potem zmieniaj

Optymalizacja bez pomiaru to zgadywanie. Zanim cokolwiek ruszysz, zrób trzy rzeczy:

Zmierz kartę produktu i kategorię, nie stronę główną. To na nich ląduje ruch z Google i z kampanii, a strona główna bywa najlżejszą stroną w całym sklepie.
Sprawdź, co się faktycznie ładuje. Zakładka sieci w narzędziach przeglądarki pokazuje każdy plik, jego wagę i to, ile czekał. To jedyne miejsce, gdzie widać prawdę.
Zapisz wyniki przed zmianami. Bez punktu odniesienia nie będziesz wiedział, czy to, co zrobiłeś, pomogło.

Warto rozróżnić dwie rzeczy, które łatwo pomylić: czas odpowiedzi serwera (jak długo trwa, zanim przeglądarka dostanie pierwszy bajt) i czas renderowania (jak długo trwa złożenie strony w przeglądarce). Pierwsze naprawia się po stronie serwera i bazy, drugie po stronie plików i szablonu. Mylenie ich to najczęstszy powód, dla którego optymalizacja nie daje efektu.

Obrazy - największy zysk najmniejszym kosztem

W sklepach internetowych obrazy to zwykle 70-90 procent wagi strony. Trzy rzeczy, które warto sprawdzić w pierwszej kolejności:

Rozmiar pliku kontra rozmiar wyświetlania

Klasyczny przypadek: zdjęcie produktu ma 2000 pikseli szerokości, a na listingu wyświetla się w kadrze 300 pikseli. Przeglądarka pobiera pełny plik i zmniejsza go w locie - klient płaci transferem i czasem za coś, czego nie zobaczy. PrestaShop generuje miniatury w zdefiniowanych rozmiarach; warto sprawdzić, czy szablon faktycznie z nich korzysta, czy sięga po oryginał.

Format

Nowoczesne formaty potrafią zdjąć połowę wagi przy tej samej jakości wizualnej. Warto podawać je z zapasem starszego formatu, żeby żadna przeglądarka nie została bez obrazu.

Ładowanie odroczone

Zdjęcia poniżej pierwszego ekranu nie muszą ładować się od razu. Wyjątkiem jest główne zdjęcie produktu i pierwszy baner - te powinny ładować się priorytetowo, bo to zwykle one decydują o tym, kiedy strona wygląda na gotową.

Ważny szczegół, o którym łatwo zapomnieć: każdy obraz powinien mieć podaną szerokość i wysokość. Bez nich przeglądarka nie wie, ile miejsca zarezerwować, i treść przeskakuje w trakcie ładowania. To wygląda źle i jest liczone jako błąd w pomiarach.

Moduły, których nikt nie używa

Druga największa pozycja. Każdy moduł w PrestaShop dokłada swoje pliki stylów i skryptów - i robi to zwykle na wszystkich stronach, także tam, gdzie nie ma nic do roboty.

Co warto zrobić:

Przejrzyj listę zainstalowanych modułów. W sklepach po kilku latach regularnie znajduje się kilkanaście, których nikt nie pamięta.
Odinstaluj, nie tylko wyłącz. Wyłączony moduł czasem nadal zostawia po sobie ślady w konfiguracji.
Sprawdź moduły, które są potrzebne tylko na jednej stronie. Slider potrzebny wyłącznie na stronie głównej nie musi ładować się na karcie produktu.

Przy okazji warto zajrzeć do tego, jakie moduły są w sklepie naprawdę potrzebne - większość spowolnień bierze się z rzeczy, które ktoś zainstalował „na próbę”.

Cache i łączenie plików w panelu

PrestaShop ma wbudowane ustawienia wydajności: łączenie i kompresję plików stylów oraz skryptów, a także własny cache. To najprostsza optymalizacja w całym zestawie - i najczęściej pomijana, bo wymaga sprawdzenia sklepu po włączeniu.

Kolejność, która ogranicza ryzyko:

Zrób kopię zapasową.
Włącz opcje pojedynczo, nie wszystkie naraz.
Po każdej zmianie wyczyść cache i przeklikaj sklep: strona główna, kategoria, karta produktu, koszyk, pełny proces zamówienia.
Sprawdź konsolę przeglądarki - błędy skryptów po włączeniu łączenia plików są typowym objawem szablonu, który nie jest z nim zgodny.

Nie włączaj tych opcji na produkcji w piątek po południu. Jeśli szablon albo moduł źle znosi łączenie plików, objawia się to zwykle w koszyku - czyli tam, gdzie boli najbardziej.

Zanim zaczniesz kręcić ustawieniami, warto wiedzieć, jak w PrestaShop działa cache - są cztery niezależne warstwy i większość pytań w stylu „zmieniłem, a nie widać” dotyczy nie tej, którą się czyści.

Ustawienia po stronie serwera

Kompresja. Pliki tekstowe - HTML, style, skrypty - powinny być wysyłane skompresowane. To zwykle jedna linia w konfiguracji i kilkadziesiąt procent mniej danych.
Nagłówki cache dla plików statycznych. Obrazy, czcionki, style i skrypty nie zmieniają się między wizytami. Powinny być zapamiętywane przez przeglądarkę na długo, żeby powracający klient nie pobierał ich ponownie.
Wersjonowanie plików. Jeśli ustawiasz długi cache, musisz mieć sposób na wymuszenie odświeżenia po zmianie - zwykle przez dopisek z numerem wersji w adresie pliku. Bez tego zmiany w wyglądzie nie dotrą do stałych klientów.
Aktualna wersja PHP. Nowsze wydania są zauważalnie szybsze od starszych. To jedna z niewielu zmian, która przyspiesza sklep bez ruszania kodu.
Cache kodu po stronie serwera. Powinien być włączony na każdym sensownym hostingu - warto sprawdzić, czy faktycznie jest.

Wymagania serwera opisałem osobno przy hostingu pod PrestaShop.

Jeśli po przejściu przez wszystkie punkty powyżej czas odpowiedzi serwera dalej jest wysoki, limitem przestaje być sklep, a zaczyna maszyna. Wtedy warto rozważyć przeniesienie sklepu na nowy serwer - ale dopiero wtedy, nie wcześniej.

Osobnym obciążeniem bywają filtry na liście produktów: przy każdej zmianie filtra sklep przelicza, ile produktów pasuje do każdej pozostałej opcji. Kilka filtrów mniej w kategorii potrafi dać więcej niż godzina optymalizacji zapytań.

Baza danych

Przy dużym katalogu baza staje się wąskim gardłem. Trzy rzeczy warte sprawdzenia:

Indeks wyszukiwarki wewnętrznej. Przy dziesiątkach tysięcy produktów tabela indeksu rośnie i potrafi spowalniać zapytania.
Stare dane sesji i porzuconych koszyków. W sklepie działającym latami potrafi ich być kilkaset tysięcy rekordów.
Statystyki. Moduły statystyk zapisują każde wejście. Jeśli i tak korzystasz z zewnętrznej analityki, zwykle nie są potrzebne.

Czyszczenie bazy robi się z kopią zapasową i najlepiej poza godzinami sprzedaży. To nie jest miejsce na eksperymenty.

Jeśli wolny jest wyłącznie panel administracyjny, a sklep dla klientów działa normalnie, to osobny problem o innych przyczynach - opisałem go w tekście o wolnym panelu administracyjnym. Sama baza zaś rośnie z czasem sama: co z niej wyrzucić, zebrałem w tekście o tym, co czyścić, gdy baza sklepu rośnie.

Skrypty zewnętrzne

Analityka, piksele reklamowe, czat, widżety opinii, mapy. Każdy z nich to połączenie do innego serwera, na który nie masz wpływu.

Policz, ile ich naprawdę jest. W sklepach po kilku kampaniach zostaje zwykle kilka pikseli, których nikt już nie używa.
Ładuj je nieblokująco, żeby nie wstrzymywały renderowania strony.
Czat i widżety opinii potrafią ważyć więcej niż cała reszta strony. Warto sprawdzić, ile realnie kosztują i czy ich wartość to uzasadnia.

Szablon i czcionki

Czcionki. Cztery kroje po cztery grubości to dwanaście plików więcej, niż potrzeba. Zwykle wystarczą dwie, trzy grubości jednego kroju. Warto też ustawić, żeby tekst był widoczny od razu, zamiast czekać na pobranie czcionki.
Nieużywane style. Gotowe szablony zawierają style dla dziesiątek wariantów układu, z których używasz jednego.
Style krytyczne. Style potrzebne do wyświetlenia pierwszego ekranu warto umieścić bezpośrednio w kodzie strony, a resztę doładować później.

Czego nie robić

Nie instaluj modułu „przyspieszacza” jako pierwszego kroku. Kolejny moduł to kolejne pliki. Najpierw usuń przyczynę, potem rozważ narzędzia.
Nie optymalizuj pod punkty w narzędziu. Celem jest szybszy sklep dla klienta, nie ładniejszy wykres. Bywają zmiany, które podnoszą wynik i pogarszają odczucie.
Nie blokuj plików stylów i skryptów w robots.txt. Google renderuje stronę i musi je zobaczyć, żeby ocenić ją tak, jak widzi ją użytkownik.
Nie rób wszystkiego naraz. Jeśli coś się zepsuje, przy pięciu zmianach nie będziesz wiedział, która to była.

Wydajność to jeden z czterech obszarów, które sprawdzam w ramach audytu sklepu internetowego. Jeśli sklep zwalnia i nie wiadomo dlaczego, to zwykle najszybsza droga do przyczyny.

Jeśli szykujesz się na listopadowy szczyt sprzedaży, wydajność jest pierwszą rzeczą do sprawdzenia, bo jako jedyna wymaga realnej pracy, a nie kliknięcia w panelu. Plan na cztery tygodnie rozpisałem przy przygotowaniu sklepu na Black Friday.

Najczęstsze pytania

Ile da się realnie zyskać?

W sklepie, którym nikt się nie zajmował, samo uporządkowanie obrazów i usunięcie nieużywanych modułów potrafi zdjąć większość wagi strony. Przy sklepie już zadbanym zostają pojedyncze procenty i wtedy schodzi się na poziom serwera i bazy.

Czy szybszy sklep oznacza wyższe pozycje w Google?

Szybkość jest jednym z sygnałów, ale słabszym niż treść i linki. Realna korzyść jest inna: mniej porzuconych wejść i więcej dokończonych zamówień. To widać w sprzedaży wcześniej niż w pozycjach.

Czy warto przenieść sklep na mocniejszy serwer?

Tylko wtedy, gdy pomiary pokazują długi czas odpowiedzi serwera. Jeśli problemem jest ciężka strona, mocniejszy serwer niewiele zmieni - wyśle ten sam nadmiar, tylko odrobinę szybciej.

Jak często sprawdzać wydajność?

Po każdej większej zmianie w sklepie: nowym module, zmianie szablonu, dużym imporcie produktów. Poza tym wystarczy raz na kwartał.

Czytaj też: największym balastem w większości sklepów są obrazki. Co konkretnie wgrywać, żeby nie ciążyły, opisałem w tekście o zdjęciach produktów do sklepu.

Sklep zwalnia i nie wiesz dlaczego?

Przegląd wydajności to zwykle kilka godzin: pomiar, lista przyczyn w kolejności od największej i konkretne poprawki. Zakres stałej opieki nad sklepem opisałem na stronie opieki i optymalizacji - napisz przez formularz kontaktowy, jeśli chcesz, żebym sprawdził Twój sklep.