PrestaShop: krytyczne błędy spowalniające sklep

Jakie błędy powodują wolne działanie PrestaShop — praktyczne spojrzenie na przyczyny i rozwiązania

Jakie błędy powodują wolne działanie PrestaShop? Najczęściej te najbardziej prozaiczne: nieoptymalny hosting, błędne ustawienia cache, przeładowane modułami środowisko i ciężki motyw. Z czasem każdy sklep rozrasta się o nowe integracje, zdjęcia i funkcje, a to wszystko zwiększa liczbę zapytań do bazy, rozmiar zasobów do pobrania i obciążenie serwera. Dobra wiadomość jest taka, że większość wąskich gardeł można dość szybko namierzyć i naprawić, a pierwsze efekty widać nierzadko w ciągu jednego dnia.

Błędy po stronie serwera i konfiguracji, które spowalniają sklep

Nieodpowiedni hosting (shared z mocnymi limitami CPU/IO). Jeśli Twoje TTFB (Time To First Byte) jest zmienne lub wysokie nawet przy pustej stronie, problem zwykle leży w serwerze. Słabe I/O, przeciążony współdzielony serwer i brak Redis/Memcached to klasyki.
Stara wersja PHP lub wyłączony OPcache. PrestaShop 1.7/8.x najlepiej działa na PHP 8.1/8.2 (zgodnie z wersją sklepu). OPcache powinien być włączony i odpowiednio skonfigurowany (m.in. pamięć, revalidate_freq).
Niewłaściwa konfiguracja bazy (MariaDB/MySQL). Zbyt małe innodb_buffer_pool_size, brak slow_query_log, brak optymalizacji parametrów dla realnego wolumenu danych. W efekcie baza „mieli”, a przy większym ruchu wszystko zwalnia.
Brak kompresji i nowoczesnych protokołów. HTTP/2 lub HTTP/3, kompresja Brotli/Gzip, cache w warstwie serwera (Nginx/Apache) – bez tego przeglądarka ściąga zasoby wolniej i w większej liczbie połączeń.

Baza danych – czyszczenie, indeksy i dobre praktyki

Rozrośnięte tabele statystyk i logów. ps_connections, ps_guest, ps_page_viewed, ps_log potrafią urosnąć do milionów rekordów. Regularne czyszczenie (CRON) i retencja danych to obowiązek. Nadmiar śmieci spowalnia zapytania.
Brak właściwych indeksów. Jeśli listy produktów długo się ładują, sprawdź EXPLAIN dla kluczowych zapytań (produkty, kategorie, atrybuty). Indeksy złożone na kolumny używane w WHERE/ORDER BY (np. id_shop, active, id_category, id_lang, date_add/date_upd) potrafią skrócić czas zapytań z sekund do milisekund.
Nieużywana historia koszyków, kupony i reguły cenowe. ps_cart, ps_cart_product, ps_specific_price i powiązane tabele potrafią puchnąć. Wdrażaj politykę retencji i archiwizacji.
Brak slow_query_log i analizy. Włącz log wolnych zapytań i przeanalizuj, które zapytania pojawiają się najczęściej. To najszybsza droga do wykrycia realnego problemu, a nie „wróżenia” z objawów.

Ustawienia PrestaShop, które najczęściej spowalniają działanie

Tryb debugowania włączony na produkcji. Debug Mode i Profiling są świetne do analizy, ale musi to być chwilowe. W produkcji wyłącz.
Zła konfiguracja Smarty. Największy grzech: Force Compile ON i Cache OFF. W produkcji ustaw: kompilacja tylko przy zmianie, cache włączony. Dla dużego ruchu rozważ korzystanie z Redis/Memcached.
Cache globalny wyłączony lub błędny backend cache. PrestaShop oferuje CacheFS, Memcached, Redis – na środowiskach wieloserwerowych i przy większym ruchu Redis/Memcached są bezpieczniejszym wyborem niż plikowy CacheFS.
CCC/Minify ustawione bez strategii. Łączenie i minifikacja CSS/JS mogą pomóc, ale przy HTTP/2/3 kluczowe jest też usunięcie zasobów nieużywanych i lazy loading. Nie chodzi tylko o „zlepić wszystko w jedno”, ale o ładować mniej i mądrzej.
Przeładowanie konfiguracją: przewoźnicy, strefy, reguły cenowe, waluty. Każdy element to dodatkowe warunki i zapytania. Porządki w konfiguracji mogą przynieść zaskakująco duży efekt.

Moduły i override’y – niewidzialne hamulce

Zbyt wiele modułów aktywnych „bo może się przyda”. Każdy moduł to dodatkowe hooki, SQL i zasoby. Wyłącz, a najlepiej odinstaluj to, czego realnie nie używasz (zwłaszcza moduły statystyk i trackingu, jeśli dane zbierasz w GA/Tag Manager).
Konflikty override’ów i ciężkie zapytania w hookach. Hooki typu displayHeader, actionFrontControllerSetMedia, actionProductListOverride potrafią dodać sekundy do TTFB. Audyt kodu modułów, profilowanie i ograniczenie liczby podpinanych hooków to must-have.
Moduły statystyk (np. statsdata) i logów. Przy dużym ruchu potrafią spowolnić każdy request. Rozważ odłączenie lub ograniczenie zakresu zbieranych danych.
Brak aktualizacji modułów. Stare wersje mają często znane problemy z wydajnością. Regularne aktualizacje naprawdę mają znaczenie.

Front‑end: motyw, obrazy i JavaScript

Ciężki motyw z nadmiarem bibliotek. Frameworki CSS użyte w 10%, kilka sliderów, 3 różne karuzele – to setki kilobajtów do pobrania. Usuń nieużywane biblioteki i sekcje, ładuj skrypty „defer”, a CSS krytyczny inline.
Nieoptymalne obrazy. Brak WebP/AVIF, brak lazy‑load, gigantyczne wymiary. Kompresuj obrazy, serwuj w nowoczesnych formatach, generuj miniatury o właściwych rozmiarach, używaj srcset. To najczęstszy „szybki wygrany”.
Fonty jako „blokery”. Zbyt wiele rodzin i odmian, brak display=swap. Ogranicz liczbę fontów, włącz swap, rozważ preloading najważniejszych.
Zasoby blokujące renderowanie. Przenieś skrypty na dół, użyj „defer”, wczytuj krytyczny CSS, a resztę asynchronicznie. Mniej plików ≠ szybciej, jeśli ładowane są rozsądnie – liczy się priorytetyzacja.

Katalog, filtrowanie i wyszukiwanie – ciche źródła spowolnień

Indeksowanie w ps_facetedsearch (filtrowanie). Brak indeksu przy każdej zmianie produktu, duże kategorie i złożone filtry potrafią „zamulić” listy. Ustal harmonogram indeksacji i dopilnuj kompletności indeksu.
Zbyt złożone reguły cenowe i atrybuty. Każda wariacja to dodatkowe zapytania. Uprość drzewo kategorii, atrybutów i reguł, jeśli to możliwe.
Wyszukiwarka. Domyślna może być OK dla małych katalogów, ale przy dużych rozważ Elasticsearch/Opensearch i odpowiednią konfigurację indeksów.

Jak diagnozować: krok po kroku, bez zgadywania

Zmierz TTFB, LCP, TBT. Celuj w TTFB < 500 ms, LCP < 2,5 s, TBT < 200 ms. Narzędzia: PageSpeed Insights, WebPageTest, GTmetrix.
DevTools w przeglądarce. Zakładka Network (waterfall), Performance (profil czasu), Coverage (ile CSS/JS jest nieużywane). To pokaże realne „ciężary”.
Profiling PrestaShop. Tymczasowo włącz PS_DEBUG_PROFILING, sprawdź liczbę zapytań i ich czasy na danej stronie. Szybko wychwycisz moduły generujące nadmiar SQL.
Slow Query Log i EXPLAIN. Włącz log wolnych zapytań, użyj EXPLAIN, by dobrać indeksy. To daje mierzalny efekt, zamiast kosmetyki na froncie.
APM (New Relic, Blackfire, Tideways). Widok transakcji, trace’y funkcji, gorące punkty w kodzie – najlepszy sposób na wykrycie wąskich gardeł w PHP.

Szybkie wygrane – co możesz zrobić dziś

Włącz cache Smarty i globalny, wyłącz Force Compile na produkcji.
Dodaj Redis/Memcached jako backend cache (jeśli hosting pozwala).
Zaktualizuj PHP do wspieranej i wydajnej wersji zgodnej z Twoją wersją PrestaShop.
Odchudź moduły: wyłącz/odinstaluj zbędne, ogranicz statystyki.
Optymalizuj obrazy: WebP/AVIF, lazy‑load, prawidłowe wymiary.
Włącz kompresję (Brotli/Gzip) i HTTP/2/3 na serwerze, skonfiguruj cache nagłówki.
Wyczyść bazę: stare logi, połączenia, goście, koszyki testowe.
Ustal CRON do regularnego sprzątania i reindeksacji facetów.

Checklist optymalizacji dla zespołu

[ ] Produkcja: Debug OFF, Profiling OFF, Smarty cache ON
[ ] Backend cache: Redis/Memcached skonfigurowany i monitorowany
[ ] Serwer: OPcache ON, kompresja Brotli/Gzip, HTTP/2/3 aktywne
[ ] Baza: slow_query_log ON, EXPLAIN dla top zapytań, indeksy dodane
[ ] Moduły: audyt hooków, usunięte zbędne, aktualizacje na bieżąco
[ ] Front-end: lazy‑load, WebP/AVIF, krytyczny CSS, skrypty „defer”
[ ] Katalog: zoptymalizowane filtry, regularny reindeks ps_facetedsearch
[ ] CRON: sprzątanie logów/statystyk, optymalizacja tabel
[ ] Monitoring: PageSpeed, WebPageTest, APM do obserwacji w czasie rzeczywistym

Jakie błędy powodują wolne działanie PrestaShop – podsumowanie i najważniejsze wnioski

Nie ma jednego magicznego przełącznika, który „przyspieszy wszystko”. Wydajność to suma detali: serwer (PHP, OPcache, HTTP/2/3), baza (indeksy, retencja danych), konfiguracja PrestaShop (cache, Smarty, moduły) i front‑end (obrazy, CSS/JS, fonty). Najczęstsze błędy to te, które pozostają „niewidoczne” na co dzień: debug na produkcji, puchnące tabele statystyk, nadmiar modułów i brak rzeczywistego audytu zapytań SQL.

Dobra strategia to: zmierzyć, zdiagnozować, naprawić i ustawić automaty (CRON, monitoring), aby problem nie wrócił. Zacznij od największych dźwigni: cache + obrazy + moduły + indeksy w bazie. W większości sklepów już te cztery kroki potrafią skrócić czas ładowania o kilkadziesiąt procent, a użytkownicy i konwersja szybko to odczują.

Jeśli po tych działaniach sklep nadal bywa ociężały pod ruchem, rozważ skalowanie pionowe/poziome, CDN dla zasobów statycznych, a przy rozbudowanym katalogu – dedykowany silnik wyszukiwania. Najważniejsze, by opierać się na danych, a nie intuicji. Wydajność da się ująć w liczbach – i właśnie te liczby niech prowadzą Twoje decyzje.