Optymalizacja wydajnosci sklepu PrestaShop: od zapytan bazodanowych po Full Page Cache

Kazde dodatkowe 100ms czasu ladowania kosztuje Cie konwersje. W e-commerce szybkosc to nie luksus – bezposrednio wplywa na Twoje przychody. Ten przewodnik koncentruje sie na konkretnych, wykonalnych optymalizacjach, ktore robia najwieksza roznice w sklepach PrestaShop.

Zacznij od pomiaru

Zanim cokolwiek zoptymalizujesz, potrzebujesz punktu odniesienia. Uzyj tych narzedzi:

• Google PageSpeed Insights – dostarcza Core Web Vitals (LCP, FID, CLS) i wynik wydajnosci
• GTmetrix – dostarcza wykresy kaskadowe pokazujace dokladnie, co sie laduje i kiedy
• MySQL slow query log – wlacz tymczasowo, aby znalezc zapytania trwajace dluzej niz 1 sekunde
• Xdebug profiler – do identyfikacji waskich gardel na poziomie PHP (uzyj cachegrind do analizy)

Najpierw zmierz, potem zoptymalizuj, potem zmierz ponownie. W przeciwnym razie zgadujesz.

Optymalizacja bazy danych

Baza danych jest najczestszym waskim gardlem w PrestaShop. Oto co sprawdzic:

Indeksuj wlasne tabele

Jesli Twoje moduly tworza wlasne tabele, upewnij sie, ze maja odpowiednie indeksy. Brakujacy indeks na czesto odpytywanej kolumnie moze zamienic zapytanie 10ms w 3-sekundowy skan calej tabeli.

ALTER TABLE ps_my_module_data ADD INDEX idx_id_product (id_product);
ALTER TABLE ps_my_module_data ADD INDEX idx_date_add (date_add);

Wyczysc stare dane

PrestaShop gromadzi dane, ktore z czasem wszystko spowalniaja:

• ps_connections i ps_connections_page – moga urosnac do milionow wierszy
• ps_log – regularnie obcinaj
• ps_mail – stare rekordy e-mail sie pietrzа
• Porzucone koszyki starsze niz 30 dni – w wiekszosci przypadkow bezpieczne do usuniecia

Optymalizuj zapytania

Uzywaj EXPLAIN na kazdym zapytaniu dotyczacym duzych tabel. Uwazaj na type: ALL (pelny skan tabeli) i Using temporary; Using filesort – oba sa sygnalem ostrzegawczym.

PHP i OPcache

Optymalizacja na poziomie PHP jest czesto pomijana:

• PHP 8.2+ – znacznie szybszy niz 7.4, a PrestaShop 8.x/9.x go obsluguje
• OPcache – wlacz i ustaw opcache.revalidate_freq=60 w produkcji (nie 0)
• Realpath cache – zwieksz realpath_cache_size do 4096K dla duzych sklepow
• Limit pamieci – ustaw na minimum 512M, aby uniknac presji garbage collectora

Redis dla cache i sesji

Zastap domyslny cache oparty na plikach Redisem:

• Cache Smarty, cache Symfony i cache modulow – wszystkie korzystaja z Redisa
• Przechowywanie sesji w Redisie eliminuje problemy z blokowaniem plikow przy duzej wspolbieznosci
• Jedna instancja Redisa moze obsluzyc wszystkie te obciazenia dla typowego sklepu

Optymalizacja frontend

• CCC (Combine, Compress, Cache) – wlacz w ustawieniach wydajnosci, ale dokladnie przetestuj
• Lazy loading – uzywaj natywnego loading="lazy" dla zdjec produktow
• Obrazy WebP – 25-35% mniejsze niz JPEG przy porоwnywalnej jakosci
• CDN – przekieruj statyczne zasoby na Cloudflare lub podobne; ustaw URL serwera mediow w PrestaShop
• Critical CSS – osadz style above-the-fold inline, aby wyeliminowac zadania blokujace renderowanie

Full Page Cache

Dla sklepow z duzym ruchem i relatywnie statycznym katalogiem, Full Page Cache (Varnish lub nginx FastCGI cache) moze zredukowac czasy odpowiedzi z 500ms do ponizej 50ms. Najtrudniejsza czesc to inwalidacja cache – musisz prawidlowo czyscic, gdy zmieniaja sie ceny, aktualizuja stany magazynowe lub startuja i koncza sie promocje.

Zacznij od optymalizacji bazy danych i PHP – daja najwieksze rezultaty przy najmniejszym ryzyku. Dodaj cache frontend i full page, gdy fundament bedzie solidny.