Optymalizacja PrestaShop:
Szybszy Sklep, Wyższa Konwersja

Przeciętny sklep PrestaShop generuje 200-400 zapytań SQL na każdą odsłonę strony. Większość z nich jest zbędna — to efekt problemu N+1 queries w Doctrine ORM, brakujących indeksów na tabelach ps_product, ps_category_product i ps_stock_available, oraz niezoptymalizowanych overrides w modułach. Ile zapytań zostaje po optymalizacji, pokazuje profiler — mierzę to przed i po zmianach.

W ramach optymalizacji bazy danych PrestaShop wykonuję: profiling slow query log w MySQL/MariaDB, dodanie brakujących indeksów, czyszczenie tabel z logami (ps_connections, ps_guest, ps_log), usuwanie starych koszyków i statystyk, oraz optymalizację tabel InnoDB (OPTIMIZE TABLE). W sklepach z dużą historią zamówień samo czyszczenie zmniejsza rozmiar bazy i skraca czas zapytań — o ile, pokazuje pomiar przed i po.

Zdjęcia produktów to najczęstszy powód wolnego ładowania sklepów PrestaShop. Typowy sklep serwuje obrazy w formacie JPEG/PNG o wadze 300KB-2MB każdy, bez kompresji i bez lazy loading. Na stronie kategorii z 30 produktami to nawet 20-60 MB danych do pobrania — duże obciążenie na połączeniu mobilnym.

Stosuję konwersję do formatów nowej generacji: WebP (25-34% mniejsze od JPEG przy identycznej jakości) i AVIF (nawet 50% mniejsze). PrestaShop 8+ obsługuje natywną regenerację miniatur w WebP. Wdrażam lazy loading z Intersection Observer API — obrazy ładują się dopiero gdy użytkownik przewinie do nich stronę. Dodatkowo konfiguruję responsive images z atrybutem srcset, by urządzenia mobilne pobierały mniejsze wersje zdjęć. Efekt: lżejsze strony kategorii i produktów oraz lepszy wskaźnik LCP (Largest Contentful Paint) — wagę strony i LCP porównuję przed i po wdrożeniu.

PrestaShop posiada wbudowaną funkcję CCC (Combine, Compress, Cache) dostępną w panelu administracyjnym: Zaawansowane → Wydajność. CCC łączy pliki CSS i JavaScript w pojedyncze pliki, kompresuje je i dodaje nagłówki cache. To dobry punkt wyjścia, ale samo CCC nie wystarczy w sklepie z tysiącami produktów — nie adresuje cache obiektów PHP, sesji użytkowników ani wyników zapytań SQL.

Dlatego wdrażam wielopoziomowy system buforowania: CCC jako podstawa, Redis jako cache obiektów Doctrine i sesji (dane w pamięci RAM zamiast na dysku), Smarty template cache dla skompilowanych szablonów, OPcache dla skompilowanego kodu PHP, oraz Varnish lub Nginx FastCGI Cache jako full page cache dla niezalogowanych użytkowników. Prawidłowo skonfigurowany stos cache odciąża bazę danych i skraca TTFB (Time To First Byte) — wpływ na obciążenie bazy i TTFB sprawdzam pomiarem przed i po zmianie.

Domyślna instalacja PrestaShop ładuje 30-60 plików JavaScript i CSS na każdej stronie — większość z nich blokuje renderowanie (render-blocking resources). Przeglądarka musi pobrać i sparsować każdy plik zanim wyświetli cokolwiek użytkownikowi. Do tego dochodzą skrypty modułów: każdy zainstalowany moduł rejestruje się na hookach PrestaShop i dokłada własne pliki — nawet jeśli na danej stronie nie jest potrzebny.

Moja optymalizacja kodu PrestaShop obejmuje: Critical CSS inline — style potrzebne do wyrenderowania widocznej części strony (above-the-fold) są wstawiane bezpośrednio w HTML, eliminując osobne żądania HTTP. Pozostałe style ładuję asynchronicznie. Skrypty JavaScript otrzymują atrybuty defer lub async, a skrypty śledzące (GTM, piksele reklamowe) opóźniam przez requestIdleCallback. Przeprowadzam audyt hooków — w typowym sklepie 50+ hooków wykonuje się na każdym page load. Identyfikuję i wyłączam te, które nie są potrzebne na danej stronie. Efekt: eliminacja render-blocking, szybsze First Contentful Paint i lepszy wynik INP.