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. Po profesjonalnej optymalizacji bazy danych ta liczba spada do 30-50 zapytań.

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ń sama operacja czyszczenia potrafi zmniejszyć rozmiar bazy o 40-60% i obniżyć czas zapytań o połowę.

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 — katastrofa 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: redukcja wagi strony o 60-80% i znacząca poprawa wskaźnika LCP (Largest Contentful Paint).

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 redukuje obciążenie bazy danych o 70-90% i obniża TTFB (Time To First Byte) poniżej 200ms — nawet przy ruchu rzędu 1000+ odwiedzin dziennie.

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.