Przyspieszenie PrestaShop — optymalizacja i Core Web Vitals krok po kroku

Dlaczego PrestaShop bywa wolny

PrestaShop to rozbudowana platforma — i ta rozbudowa ma swoją cenę. Front (to, co widzi klient) renderuje się na tym samym serwerze, na którym działa cała logika sklepu: baza produktów, zamówienia, moduły. Każdy element tej układanki może stać się wąskim gardłem.

Zanim zaczniesz cokolwiek optymalizować, warto wiedzieć, co najczęściej odpowiada za wolne ładowanie:

• Nadmiar modułów — każdy zainstalowany moduł dokłada własne pliki CSS i JS oraz potrafi generować dziesiątki, a czasem setki zapytań SQL na jedno wyświetlenie strony
• Źle skonfigurowany cache Smarty — gdy szablony rekompilują się przy każdym żądaniu, dokładają setki milisekund do czasu odpowiedzi serwera
• Słaby hosting i brak cache serwerowego — współdzielony hosting bez OPcache, Redisa czy CDN oznacza wysoki TTFB (czas do pierwszego bajtu)
• Nieoptymalna baza danych — tabele w MyISAM zamiast InnoDB, sterty starych logów, porzucone koszyki i wygasłe rabaty
• Ciężkie assety frontu — obrazy w JPG/PNG zamiast WebP, brak lazy loadingu, render-blocking JavaScript

Core Web Vitals w PrestaShop — co mierzyć

Core Web Vitals to zestaw metryk, którymi Google ocenia realne doświadczenie użytkownika — i które wpływają na pozycje w wyszukiwarce. Dla sklepu PrestaShop celuj w te wartości:

Krok 1: ustawienia wydajności w panelu

Najtańsza optymalizacja PrestaShop nie kosztuje nic i zajmuje kilka minut. Wejdź w Parametry zaawansowane → Wydajność i ustaw:

To pojedyncza zmiana, która najczęściej daje największy skok wyniku — bo eliminuje rekompilację szablonów i redukuje liczbę pobieranych plików. Ważne: po każdej zmianie wyczyść cache i przetestuj sklep, bo agresywne łączenie plików (CCC) sporadycznie rozjeżdża wygląd na nietypowych szablonach.

Krok 2: obrazy — największy dług wagi strony

W typowym sklepie obrazy to 60–80% wagi strony. Trzy działania, które realnie poprawiają LCP i CLS:

• Konwersja na WebP — format WebP tnie wagę obrazów o około 30% przy tej samej jakości. PrestaShop od wersji 1.7.6 potrafi generować WebP natywnie (Wydajność → format obrazów), są też darmowe moduły
• Lazy loading — obrazy poniżej pierwszego ekranu ładują się dopiero, gdy klient do nich doscrolluje. Skraca początkowe ładowanie na stronach kategorii i liście produktów
• Sztywne wymiary — każdy obraz i baner powinien mieć zadeklarowane width i height (lub proporcje). To jedyny skuteczny sposób na CLS — bez tego treść skacze, gdy obrazy się doładowują

Krok 3: PHP, OPcache i serwer

Tu zaczynają się zmiany, które najmocniej ruszają TTFB. Część zrobisz z panelu hostingu, część wymaga dostępu do konfiguracji — ale żadna nie wymaga przepisywania sklepu:

• PHP 8.1 lub nowsze — sam skok wersji PHP potrafi dać kilkadziesiąt procent szybszego przetwarzania. To zmiana jednym kliknięciem w panelu hostingu
• OPcache — buforuje skompilowany kod PHP w pamięci. Zalecane wartości: opcache.memory_consumption=256, opcache.max_accelerated_files=16229, opcache.revalidate_freq=10
• InnoDB zamiast MyISAM — nowoczesny silnik bazy z lepszą obsługą współbieżności; dołóż odpowiedni innodb_buffer_pool_size
• Redis lub Memcached — cache serwerowy trzymający wyniki zapytań w pamięci; powracający ruch dostaje odpowiedź błyskawicznie
• Wyłącz tryb deweloperski — upewnij się, że _PS_MODE_DEV_ jest ustawione na false na produkcji; tryb debug potrafi wielokrotnie spowolnić sklep
• Optymalizacja autoloadera — po większych zmianach uruchom composer dump-autoload --optimize --classmap-authoritative

Krok 4: audyt modułów

Moduły to najczęstsza ukryta przyczyna wolnego PrestaShop. Zasada jest prosta: każdy nieużywany moduł to czysta strata — dokłada zapytania, skrypty i style, a nie wnosi nic w zamian.

Szczególnie uważaj na moduły „all-in-one” ładujące własne biblioteki (slidery, popupy, liczniki), które i tak dublują to, co masz w szablonie.

Krok 5: CDN na statyczne zasoby

CDN (Content Delivery Network) rozprowadza obrazy, CSS i JS po serwerach na całym świecie, a klient pobiera je z najbliższej lokalizacji. Efekt: niższa latencja, odciążony serwer sklepu i niższy TTFB dla zasobów statycznych. Dla większości sklepów wystarczy darmowy plan Cloudflare przed domeną — zero zmian w kodzie.

Co daje najwięcej — kolejność działań

Jeśli masz zrobić tylko kilka rzeczy, zrób je w tej kolejności — od największego zwrotu przy najmniejszym wysiłku:

Gdzie kończy się optymalizacja szablonu

Powyższe kroki potrafią przenieść sklep z wyniku 40 na 70–80 w PageSpeed. Ale w pewnym momencie uderzasz w sufit architektury: front PrestaShop renderuje się przez Smarty na tym samym serwerze co backend, a każdy moduł frontowy nadal dokłada swój narzut. Wyczyściłeś cache, skonwertowałeś obrazy, wyciąłeś moduły — a LCP dalej nie chce zejść poniżej progu.

Wtedy zostaje zmiana architektury — headless. Front działa jako osobna, zoptymalizowana aplikacja na własnej infrastrukturze i komunikuje się z PrestaShop wyłącznie przez API. Panel, produkty, zamówienia i checkout zostają bez zmian — zmienia się tylko warstwa, która decyduje o wydajności.

Headless nie jest dla każdego — ma sens, gdy wydajność jest priorytetem, a optymalizacja szablonu przestała wystarczać. Jak to działa krok po kroku i co zmienia w codziennej pracy, opisaliśmy w osobnych materiałach: