Optymalizacja PrestaShop: co naprawdę przyspiesza sklep i kiedy to za mało

Zanim cokolwiek zmienisz: zmierz, gdzie ucieka czas

„Sklep jest wolny” to nie diagnoza. Diagnozą jest: strona kategorii dla niezalogowanego klienta odpowiada po dwóch sekundach, a dla zalogowanego hurtownika po ośmiu. Albo: serwer odpowiada szybko, ale strona produktu ładuje 4 MB obrazów i 30 plików JavaScript. To dwa różne problemy z dwiema różnymi listami zadań.

Zrób trzy pomiary, zanim porozmawiasz z kimkolwiek o optymalizacji:

1. PageSpeed Insights dla strony głównej, jednej kategorii i jednego produktu. Zapisz Core Web Vitals (LCP, INP, CLS) i czas odpowiedzi serwera (TTFB). To rozdziela problemy serwera od problemów przeglądarki.
2. Ten sam pomiar po zalogowaniu jako klient B2B, jeśli masz ceny per klient. Narzędzia publiczne tego nie zmierzą, więc użyj narzędzi deweloperskich w przeglądarce (zakładka Sieć) albo poproś wykonawcę o pomiar z poziomu serwera.
3. Liczba aktywnych modułów z panelu, z zaznaczeniem, które z nich są widoczne na stronie (nagłówek, stopka, lista produktów, koszyk).

Z tymi trzema liczbami przejdź przez listę poniżej. Kolejność nie jest przypadkowa: od zmian najtańszych i najbardziej przewidywalnych do najdroższych.

Krok 1. Wersja PHP i wersja PrestaShop

To najczęściej pomijany krok, bo wymaga rozmowy z hostingiem, a nie kliknięcia w panelu. Sklep na PrestaShop 1.7 często stoi na PHP 7.x, bo tak został postawiony lata temu. Według strony wydania PrestaShop 9 wersja 9 wymaga co najmniej PHP 8.1 i jest zgodna z PHP 8.4. Nowsze wersje PHP wykonują ten sam kod szybciej, ale to nie jest główny powód, dla którego ten krok jest pierwszy. Główny powód jest taki, że PrestaShop 1.7 nie jest już utrzymywany: gałąź 1.7.8 dostawała wyłącznie poprawki bezpieczeństwa od wydania 8.0, a ten okres skończył się wraz z wydaniem 9.0 w czerwcu 2025. Optymalizowanie sklepu, który nie dostaje poprawek bezpieczeństwa, jest inwestowaniem w coś, co i tak trzeba będzie zmienić.

Jeśli stoisz na 1.7, przeczytaj najpierw tekst o aktualizacji PrestaShop do 8 lub 9. Jeśli stoisz na 8.2 lub 9, sprawdź wersję PHP na hostingu i podnieś ją do najwyższej, którą twoja wersja PrestaShop i twoje moduły obsługują. Najpierw na kopii, bo starsze moduły potrafią nie działać na nowym PHP.

Krok 2. Cache: Smarty, CCC i cache po stronie serwera

PrestaShop ma trzy mechanizmy cache opisane w dokumentacji ustawień wydajności. Warto wiedzieć, co każdy z nich robi, bo agencje sprzedają „włączenie cache” jako usługę.

Cache szablonów Smarty. Szablony sklepu są kompilowane i przechowywane w gotowej postaci. Dokumentacja opisuje trzy tryby: nigdy nie kompiluj ponownie, kompiluj ponownie, gdy pliki motywu się zmieniły, oraz wymuś kompilację. Ten ostatni, jak mówi dokumentacja, włącza się tylko wtedy, gdy edytujesz motyw i chcesz widzieć zmiany przy każdym odświeżeniu. Na produkcji powinien być wyłączony. Jeśli jest włączony, to pierwsza rzecz do poprawy.

CCC, czyli łączenie, kompresja i cache plików. Dokumentacja opisuje, że PrestaShop łączy pliki tego samego typu (CSS, JavaScript), kompresuje je i przechowuje wynik, żeby „serwer nie musiał wykonywać tego procesu przy każdym wczytaniu strony”. Dokumentacja dodaje, że cache dla CSS jest bezpieczne, a cache dla JavaScript „może czasem sprawiać problemy”, więc trzeba je przetestować. Opcja optymalizacji Apache modyfikuje konfigurację serwera.

Cache po stronie serwera. Dokumentacja wymienia Memcached („bardzo skuteczny, przede wszystkim przy kilku serwerach”), APC (dla jednego serwera) i radzi sprawdzić z hostingiem, czy serwer ma odpowiednie rozszerzenie. To ten rodzaj cache, który przechowuje statyczne wersje dynamicznych stron.

Jest jedno „ale”, którego dokumentacja nie podkreśla, a które decyduje o sklepach B2B. Cache działa dla stron, które są takie same dla wszystkich. Strona kategorii z cenami per klient, koszyk z rabatem zależnym od obrotu, lista produktów z dostępnością dla konkretnego magazynu: tego nie da się serwować z cache, bo każdy klient widzi co innego. Jeśli twoje pomiary pokazują, że wolne są właśnie strony po zalogowaniu, żadne ustawienie cache tego nie zmieni.

Krok 3. Funkcje opcjonalne, których nie używasz

Ten krok jest mało znany i darmowy. Dokumentacja wydajności opisuje sekcję funkcji opcjonalnych, w której można wyłączyć kombinacje, cechy i grupy klientów, „żeby przyspieszyć sklep”. Zastrzeżenie: nie da się wyłączyć funkcji, z której korzystają produkty, więc najpierw trzeba usunąć dane. Jeśli sprzedajesz produkty bez wariantów i nie używasz cech, wyłączenie kombinacji i cech usuwa z każdej strony produktu zapytania, które nic nie wnoszą.

Z grupami klientów ostrożnie: w sklepie B2B to one odpowiadają za ceny netto i ukrywanie cen, więc wyłączenie ich nie wchodzi w grę. Opisujemy to w tekście o PrestaShop B2B.

Krok 4. Moduły: tu zwykle ucieka najwięcej

Większość modułów podpina się pod hooki wykonywane przy każdym wczytaniu strony: nagłówek, stopka, lista produktów, koszyk. Każdy dokłada własne zapytania do bazy oraz pliki CSS i JavaScript. Dziesięć modułów widocznych w nagłówku to dziesięć zestawów zapytań na każdej stronie, niezależnie od tego, czy klient z nich korzysta.

Zrób trzy rzeczy, w tej kolejności:

1. Wyłącz moduły, z których nikt nie korzysta. W sklepie po kilku latach jest ich zwykle więcej, niż się wydaje: dawne promocje, porzucone integracje, dwa moduły opinii. Dokumentacja opisuje w trybie debugowania opcję wyłączenia modułów spoza PrestaShop, żeby wyizolować źródło błędu. Ta sama opcja na kopii sklepu pokazuje, ile czasu zabierają moduły łącznie: zmierz stronę z modułami i bez.
2. Sprawdź, które moduły wykonują zapytania na każdej stronie. Moduł wyświetlający „ostatnio oglądane” albo „inni kupili też” robi to przy każdym wczytaniu. Jeśli nie zwiększa sprzedaży, kosztuje tylko czas.
3. Zaktualizuj te, które zostają. Autorzy modułów poprawiają wydajność w kolejnych wersjach, a stare wersje na nowym PHP potrafią generować ostrzeżenia zapisywane do logów przy każdym żądaniu.

Jeśli po tym kroku sklep nadal jest wolny, a lista modułów jest długa, bo każda funkcja sprzedaży to osobny moduł, to sygnał, o którym piszemy na końcu.

Krok 5. Obrazy i serwer mediów

Obrazy rzadko spowalniają serwer, ale często spowalniają przeglądarkę, czyli to, co klient widzi jako „wolny sklep”. PrestaShop generuje warianty obrazów według ustawień rozmiarów, więc pierwsza rzecz to sprawdzenie, czy motyw nie wczytuje dużych wariantów tam, gdzie wystarczą miniatury. Druga to format: nowsze wersje PrestaShop obsługują WebP, a sklep z tysiącami zdjęć w JPEG w pełnej rozdzielczości ładuje megabajty, których nikt nie ogląda.

Trzecia rzecz to serwer mediów. Dokumentacja wydajności opisuje przekierowanie obrazów, wideo i podobnych plików na inne domeny lub subdomeny, zwykle CDN, i ostrzega, że wpisanie własnej domeny sklepu w to pole „nie jest właściwą drogą do świetnej wydajności”. Dokumentacja zaznacza też, że hosty CDN muszą mieć zsynchronizowane katalogi obrazów, motywów i modułów ze sklepem głównym.

Krok 6. Baza danych i hosting

Dwa kroki, które agencje sprzedają najchętniej, bo są najdroższe. Są potrzebne, ale dopiero po poprzednich.

Baza. W sklepie po latach rosną tabele statystyk, logów, połączeń i koszyków gości. Czyszczenie ich jest standardową czynnością utrzymaniową, którą wykonawca PrestaShop zna. Drugi temat to zapytania przy dużym katalogu: listy produktów z wieloma cenami specyficznymi i filtrami potrafią generować zapytania, które baza wykonuje długo. Tu pomaga indeksowanie i analiza wolnych zapytań, a nie szybszy serwer.

Hosting. Zmiana z hostingu współdzielonego na serwer VPS albo dedykowany pomaga, jeśli pomiary pokazują wolny czas odpowiedzi serwera przy prostych stronach. Nie pomaga, jeśli problemem jest kod modułów albo zapytania. Dlatego ten krok jest ostatni: po poprzednich wiesz, czy płacisz za serwer, czy za cudze błędy.

Kiedy optymalizacja PrestaShop nie wystarczy

Lista powyżej doprowadza większość sklepów do akceptowalnej szybkości. Są jednak trzy sytuacje, w których kolejna optymalizacja nic nie daje, bo problem jest w architekturze, a nie w ustawieniach.

Sklep liczy ceny dla każdego zalogowanego klienta osobno. Hurtownia z tysiącami klientów i cenami per klient na dużym katalogu nie skorzysta z cache, bo każda strona jest inna. Można to przyspieszać zapytaniami i serwerem, ale koszt rośnie szybciej niż efekt. Platformy headless rozwiązują to inaczej: storefront pobiera z API tylko dane, które się zmieniają (cenę dla klienta), a resztę strony serwuje z cache. Tak działa sklep na Medusie, który opisujemy w tekście co to jest Medusa.js.

Każda nowa funkcja to kolejny moduł, który spowalnia wszystkie strony. Jeśli lista modułów rośnie z każdym kwartałem, a każdy z nich dokłada zapytania na każdej stronie, optymalizacja jest sprzątaniem po decyzjach, które będą zapadać dalej. Wtedy liczymy, ile kosztuje utrzymanie tego stosu przez 24 miesiące, i porównujemy z platformą, na której funkcje buduje się w kodzie sklepu, a nie w warstwie dodatków.

Sklep stoi na PrestaShop 1.7. Jest wolny i nie dostaje poprawek bezpieczeństwa. Aktualizacja do 9 i tak oznacza przepisanie motywu i sprawdzenie każdego modułu, więc jest dobrym momentem na pytanie, czy przepisywać motyw pod PrestaShop, czy od razu pod nową platformę. Pomagamy przejść przez ten rachunek na stronie PrestaShop: aktualizacja do 9 czy nowa platforma.

Jak podchodzimy do wolnego sklepu

Gdy firma przychodzi do nas z wolnym sklepem na PrestaShop, nie zaczynamy od oferty migracji. Zaczynamy od trzech pomiarów z początku tego tekstu i od listy modułów. W większości przypadków wynik to lista zadań dla wykonawcy PrestaShop i nic więcej. W pozostałych przypadkach pokazujemy, że problem jest w architekturze, i liczymy obie drogi: aktualizację z optymalizacją oraz migrację sklepu na platformę, która ceny per klient i duży katalog obsługuje z założenia, a nie przez obejścia. Jak budujemy takie sklepy, opisujemy na stronie wdrożeń Medusa.js.