Spis treści:
- Dlaczego cache to fundament?
- Aktualizacje – szybciej i bezpieczniej
- Sprzątanie modułów
- Modyfikacje w core PrestaShop
- Podsumowanie
Black Friday nie wybacza technicznych potknięć – im bliżej piku, tym większe znaczenie mają solidne podstawy aplikacji. W poprzednim tekście pokazaliśmy, jak namierzać wąskie gardła i potwierdzać je twardymi danymi, aby nie działać „na oślep”. Teraz czas posprzątać fundamenty: właściwa wersja PHP, poprawna konfiguracja cache i kompilacji szablonów, wyłączony tryb developerski oraz porządek w modułach to zestaw, który warunkuje skuteczność wszystkich kolejnych optymalizacji.
Nawet mocny serwer i CDN nie pomogą, jeśli sklep jest źle skonfigurowany na poziomie aplikacji: gdy szablony są przeliczane przy każdym wejściu, korzystasz z przestarzałej wersja PHP, a w tle pracują niepotrzebne moduły. Optymalizacja aplikacji PrestaShop to po prostu odciążenie u źródła – dopiero na takim gruncie warto inwestować czas w bazę danych, konfigurację serwera, CDN, Varnish czy testy obciążeniowe.
Efekt dla biznesu: szybsza reakcja strony w piku = mniej porzuceń koszyka = stabilniejszy ROAS kampanii.
1. Dlaczego cache to fundament?
Bez cache każda odsłona powtarza te same operacje: zapytania do bazy, przetwarzanie w PHP i renderowanie Smarty – to koszt, który niepotrzebnie ponawiany jest przy każdym żądaniu. Cache sprawia, że kosztowne kroki wykonują się raz, a kolejne wizyty dostają gotowy wynik. W rezultacie mamy niższy TTFB (ang. Time to First Byte) i stabilne czasy w piku ruchu.
Jak skonfigurować cache, Smarty i tryb developerski w PrestaShop
Konfiguracja Smarty (kompilacja i cache szablonów)
Smarty to silnik szablonów używany przez PrestaShop do generowania HTML na froncie sklepu oraz w starszych częściach panelu administracyjnego. W praktyce oddziela logikę (PHP, zapytania) od prezentacji (szablon), a ponieważ szablony mogą być kompilowane i buforowane, jego ustawienia bezpośrednio wpływają na szybkość renderowania.
Jak skonfigurować Smarty w PrestaShop
Wejdź w: Panel administracyjny → Zaawansowane → Wydajność. W tej zakładce skonfigurujesz kluczowe sekcje: Smarty, Pamięć podręczna oraz Tryb debugowania.
Poniżej znajdziesz konkretne ustawienia per środowisko z krótkim uzasadnieniem.
Produkcja (działający sklep)
- Kompilacja szablonów: ustaw „Nigdy nie kompiluj ponownie plików szablonów”.
- Pamięć podręczna: „Tak”.
- Czyszczenie pamięci podręcznej: „Nigdy nie kasuj plików pamięci podręcznej”.
- Tryb developerski: wyłączony.
Po każdej zmianie w szablonach/modułach: kliknij „Wyczyść cache”, aby uniknąć mieszania starej i nowej wersji widoków. Zapewni to stabilność i szybkość – bez zbędnej rekompilacji i nadmiarowych zapytań.
Środowisko testowe (staging)
- Kompilacja szablonów: „Przeładowuj, jeśli pliki się zmieniły” – zmiany w plikach są widoczne bez ręcznego czyszczenia.
- Pamięć podręczna: „Tak” – pozwala sprawdzić odświeżanie (inwalidację) cache po zmianach konfiguracji.
- Czyszczenie pamięci podręcznej: „Wyczyść pamięć podręczną za każdym razem kiedy coś zostanie zmienione”.
Środowisko programistyczne (lokalnie)
- Kompilacja szablonów: „Wymuś kompilację” – każda zmiana pliku widoczna od razu.
- Pamięć podręczna: „Nie” – priorytetem jest szybka praca nad kodem, nie pomiar wydajności.
- Czyszczenie pamięci podręcznej: „Wyczyść pamięć podręczną za każdym razem kiedy coś zostanie zmienione”.
- Tryb developerski: może być włączony, ale tylko poza produkcją.
Tryb developerski (WAŻNE)
Na działającym sklepie produkcyjnym musi być ZAWSZE WYŁĄCZONY. Włączenie trybu developerskiego może ominąć cache, generuje więcej logów i uruchamia dodatkowe operacje diagnostyczne, co często wyraźnie spowalnia każdą stronę. Dodatkowo błędy i ostrzeżenia mogą zostać wyświetlone bezpośrednio na froncie, co zaburza wygląd sklepu i może zniechęcić użytkowników. Używaj go wyłącznie na środowiskach testowych lub programistycznych.
Przykład praktyczny
Pozostawienie na produkcji „Wymuś kompilację” i wyłączonego cache wymuszało rekompilację szablonów i świeże odczyty z bazy przy każdym żądaniu. Czasy ładowania wzrosły do ~1,8 s zamiast ~500 ms. Powrót do poprawnych ustawień natychmiast przywrócił stabilność.
Szybki test po zmianach (1 minuta)
Zanim uznasz, że konfiguracja cache działa poprawnie, warto wykonać krótki test, który potwierdzi dwie rzeczy: że kolejne odsłony strony faktycznie korzystają z pamięci podręcznej oraz że cache prawidłowo się odświeża po zmianach w ustawieniach lub treści. Ten prosty krok wychwytuje typowe błędy (np. wymuszona kompilacja na produkcji, zbyt agresywne odświeżanie, brak unieważniania po zmianie konfiguracji modułu) i oszczędza czas na późniejsze dochodzenie, dlaczego strona raz jest szybka, a raz nie.
- Odwiedź kartę produktu i koszyk jako niezalogowany, odśwież 2–3 razy – kolejne ładowania powinny być wyraźnie szybsze (cache działa).
- Zmień drobną opcję w module (np. widoczność bloku), zapisz i sprawdź widok – potwierdzisz poprawne odświeżanie cache.
Więcej o testach i diagnostyce przeczytasz w pierwszym artykule z serii: PrestaShop na Black Friday: Audyt i diagnostyka – gdzie zacząć optymalizację PrestaShop?
Ustawienia do zapamiętania
Użyj tej instrukcji do szybkiego ustawienia środowiska bez wracania do całej instrukcji. Dzięki niemu łatwo unikniesz typowych pomyłek (np. kompilacji na produkcji czy wyłączonego cache na testach) i od razu zastosujesz właściwe mechanizmy pod aktualny cel: stabilność na produkcji, weryfikacja odświeżania na testach, szybka praca nad kodem lokalnie.
- Produkcja:
- „Nigdy nie kompiluj…”
- „Nigdy nie kasuj plików pamięci podręcznej”
- cache: Tak
- tryb developerski: wyłączony
- Test:
- „Przeładowuj, jeśli pliki się zmieniły”
- „Wyczyść pamięć podręczną za każdym razem kiedy coś zostanie zmienione”
- cache: Tak (weryfikacja odświeżania)
- Lokalnie:
- „Wymuś kompilację”
- „Wyczyść pamięć podręczną za każdym razem kiedy coś zostanie zmienione”
- cache: Nie (szybka praca nad kodem)
2. Aktualizacje – szybciej i bezpieczniej
Aktualizacje to nie tylko nowe funkcjonalności i „łatki” błędów. W praktyce przynoszą nowsze technologie, realne zyski wydajności oraz dłuższe wsparcie. Każdy moduł to fragment oprogramowania, który współpracuje z corem PrestaShop, bazą danych i zewnętrznymi usługami (API).
Zaniedbane aktualizacje mogą powodować:
- Problemy z kompatybilnością (starszy moduł nie działa poprawnie z nowszym PHP lub Symfony).
- Spadek wydajności (nowsze wersje ograniczają liczbę i koszt zapytań SQL, optymalizują hooki, zmniejszają liczbę ładowanych plików).
- Luki bezpieczeństwa (brak poprawek zwiększa ryzyko ataków, np. SQL injection, XSS).
Dlaczego aktualizacje są tak ważne?
Nowsze wersje PrestaShop podnoszą wersje frameworka i zgodność z nowszym PHP (np. 8.1, 8.2, 8.3, 8.4), co przekłada się na lepsze bezpieczeństwo, nowoczesne możliwości i krótsze czasy odpowiedzi. Często zawierają też optymalizację zapytań SQL, lepsze wykorzystanie cache oraz usprawnienia w warstwie renderowania – te zmiany dają odczuwalny efekt szczególnie przy większym ruchu.
Przykład praktyczny
Sklep przeniesiony z PrestaShop 1.7.6 na PrestaShop 8.1 oraz z PHP 7.2 na PHP 8.1 przyspieszył ładowanie koszyka (10 produktów) z około 0,8 s do około 0,6 s, bez żadnych innych zmian – to typowy efekt przejścia na nowszą wersję silnika sklepu i języka PHP.
Jak bezpiecznie zaktualizować PrestaShop
Najpierw wykonaj aktualizacje na środowisku testowym: zaktualizuj PrestaShop i moduły, przejdź krytyczne ścieżki (strona produktu, koszyk, checkout), sprawdź logi i podstawowe czasy odpowiedzi. Gdy testy wypadną dobrze, wdrażaj je na produkcji z planem awaryjnym: zrób kopię zapasową, wdrażaj w oknie serwisowym, po wdrożeniu wyczyść cache i wykonaj szybki test działania (smoke test). Pamiętaj też o wersji PHP – trzymaj najwyższą wspieraną przez posiadaną wersję PrestaShop i po zmianie PHP sprawdź wpływ na czasy odpowiedzi pod ruchem.
Kompatybilność wersji PHP z wersjami PrestaShop
3. Sprzątanie modułów
Każdy zainstalowany moduł to potencjalny balast – nawet jeśli nie widać tego na pierwszy rzut oka. Jedne wczytują własne skrypty, inne dokładają zapytania do bazy, a jeszcze inne w tle odpytują zewnętrzne usługi. Regularny audyt modułów to najszybsza droga do odzyskania płynności działania sklepu, zwłaszcza przed intensywnym ruchem.
Dlaczego moduły spowalniają?
- Każdy moduł dodaje własne pliki CSS/JS i może zwiększać liczbę żądań oraz wagę strony.
- Rejestruje hooki, które potrafią uruchamiać się przy każdym odświeżeniu i dokładać pracę aplikacji.
- Często wykonuje dodatkowe zapytania SQL (czasem duplikowane lub bez cache).
- Może odpytywać zewnętrzne API w tle, co zwiększa opóźnienia i obciążenie I/O.
- Renderuje własne bloki/sekcje, co wydłuża czas generowania widoku.
- Zajmuje pamięć, a nadmiar modułów pogarsza ogólną kondycję BO (ang. Back Office) i frontu.
Przykład praktyczny
Sklep miał ok. 80 aktywnych modułów, w tym 20 zbędnych. Po ich odinstalowaniu panel administracyjny wyraźnie przyspieszył – jeden z usuniętych modułów przy każdym wejściu do BO sprawdzał dostępność aktualizacji przez zewnętrzne API, niepotrzebnie spowalniając pracę.
Jak przeprowadzić audyt modułów?
Krok 1. Zrób aktualną listę
- Wejdź w Moduły → Menedżer modułów → Zainstalowane.
- Wyeksportuj listę lub skopiuj do arkusza (nazwa, wersja, status, opis, przeznaczenie).
Krok 2. Skategoryzuj
- Krytyczne dla biznesu: płatności, kurierzy, ERP, integracje magazynowe/księgowe.
- Marketing/SEO: banery, pop‑upy, rekomendacje/cross‑sell, tagi, piksele.
- Statystyki/analityka: moduły zbierające dane przy każdej odsłonie (często ciężkie).
- Testowe/zapomniane: instalowane chwilowo do prób, nieużywane w procesie zakupowym.
Krok 3. Mierz „przed i po”
Zanim zaczniesz usuwać zbędne moduły, zapisz czasy kluczowych ścieżek (strona produktu, kategoria, koszyk, checkout) oraz TTFB/łączny czas SQL. Po zmianach powtórz testy w tych samych warunkach.
Interesuje Cię różnica w:
- czasie generowania strony,
- liczbie i łącznym czasie zapytań SQL,
- wielkości i liczbie plików CSS/JS,
- czasie odpowiedzi BO (widok modułów, produktów, zamówień).
Krok 4. Usuń to, co zbędne
Usuń moduły nieużywane/testowe wraz z plikami z serwera (samo ich wyłączenie zostawia hooki/wpisy w bazie). Spisz zależności (czy moduł wstrzykuje coś do checkoutu, koszyka, BO), by uniknąć niespodzianek.
Krok 5. Ogranicz kosztowne integracje
Jeżeli moduł musi pytać zewnętrzne API, rozważ:
- cache odpowiedzi na krótki TTL,
- łączenie zapytań (batching) zamiast wielu pojedynczych,
- wykonywanie odpytań asynchronicznie (CRON/kolejka) poza cyklem renderowania.
Krok 6. Uporządkuj hooki i zasoby
- Sprawdź, czy moduły nie są podpięte do nadmiarowych hooków.
- Zredukuj zbędne CSS/JS (wyłącz ładowanie na stronach, gdzie nie są potrzebne).
- Rozważ „lazy load” komponentów, które nie są krytyczne dla pierwszego widoku.
Krok 7. Procedura utrzymaniowa
Raz w kwartale powtórz mini‑audyt: lista modułów, ich status, wpływ na krytyczne ścieżki. Aktualizuj moduły i notuj zmiany w wydajności po aktualizacji.
Tip: moduły analityczne często liczą coś przy każdej odsłonie – rozważ przeniesienie analityki do zewnętrznego narzędzia np. GA4 i ogranicz ilość pracy po stronie sklepu.
Gdy pojawia się wątpliwość „czy ten moduł jest potrzebny?”, sprawdź faktyczne użycie w procesie: czy wspiera sprzedaż, obsługę, raportowanie, czy tylko dubluje funkcję innego elementu.
4. Modyfikacje w core PrestaShop
Override (czyli nadpisanie fragmentu kodu rdzenia sklepu własną wersją klasy lub metody, która zaczyna działać zamiast standardowej), bywa sposobem na szybkie dopisanie brakującej funkcjonalności albo takiej, która ma tylko przetrwać aktualizację sklepu. W dłuższej perspektywie to jednak jedna z najczęstszych przyczyn spowolnień i problemów przy upgrade’ach. Warto wiedzieć, jak je kontrolować i kiedy wybrać bezpieczniejszą alternatywę.
Dlaczego override’y są problematyczne?
- Problemy z aktualizacją: po podniesieniu wersji sklepu wiele override’ów okazuje się niekompatybilnych, co blokuje upgrade lub powoduje błędy w krytycznych miejscach.
- Często nieoptymalne: override’y potrafią dodawać dodatkowe zapytania SQL w newralgicznych punktach (karta produktu, koszyk, checkout), bez żadnej polityki cache, co podnosi TTFB i koszt generowania widoków.
- Trudne do profilowania: w profilerach kod z override’u bywa widoczny jak kod rdzenia, przez co trudniej namierzyć źródło spowolnienia niż w przypadku wydzielonego modułu.
Przykład praktyczny
Override pliku Cart.php wprowadzał zapytanie do integracji magazynowej osobno dla każdego produktu w koszyku. Efekt: koszyk z 20 pozycjami wykonywał 20 wywołań API i ładował się około 6 sekund. Po przeniesieniu logiki do osobnego modułu i zebraniu zapytań w jedno zbiorcze odwołanie czas ładowania spadł do około 800 ms. Różnica wynikała wyłącznie z ograniczenia liczby wywołań oraz lepszej kontroli cache/strategii pobierania.
Podsumowanie
Solidne fundamenty przynoszą najszybszy i najbardziej przewidywalny efekt: poprawna konfiguracja cache i kompilacji szablonów, regularne aktualizacje silnika oraz modułów, „odchudzenie” listy rozszerzeń i kontrola override’ów. To proste kroki, które realnie skracają czas odpowiedzi, stabilizują działanie w szczytach i zmniejszają liczbę niespodzianek przy kolejnych wdrożeniach.
Warto pamiętać o trzech zasadach. Po pierwsze, środowiska ustawiaj świadomie – produkcja na stabilnym cache i bez trybu developerskiego, testy do weryfikacji odświeżania, a praca lokalna pod szybkie iteracje. Po drugie, każdy moduł ma swoją cenę wydajnościową – inwentaryzacja, usuwanie zbędnych pozycji i pomiary „przed/po” to najprostsza droga do odzyskania szybkości. Po trzecie, override’y traktuj jako ostateczność – preferuj moduły i hooki, łącz wywołania do usług zewnętrznych, dodawaj cache z kontrolą unieważniania i zawsze potwierdzaj efekty pomiarami.
Te porządki są bazą pod kolejne etapy optymalizacji: dopracowanie kodu modułów, pracę na danych i bazie, konfigurację serwera, CDN oraz cache wyższego poziomu, a także testy obciążeniowe. W następnym artykule na temat optymalizacji danych omówimy: indeksowanie, eliminowanie wzorca N+1, politykę retencji, higienę logów i praktyki, które utrzymują szybkie zapytania nawet przy rosnącej skali.
Jeśli potrzebujesz wsparcia przy optymalizacji swojego sklepu na PrestaShop lub po prostu chcesz porozmawiać o rozwoju – skontaktuj się z nami.
