Szybkość sklepu PrestaShop: instrukcja konfiguracji

Wydajność: WebP, lazy load, minifikacja i cache. Moduł Performance przyspiesza sklep dzięki dostarczaniu obrazów WebP (z bezpiecznym powrotem do oryginału), leniwemu ładowaniu, minifikacji i łączeniu CSS/JS, nagłówkom pamięci podręcznej przeglądarki, wskazówkom preload/preconnect oraz nieniszczącej konserwacji bazy danych. Każda optymalizacja ma własny przełącznik, więc można włączyć dokładnie to, co obsługuje szablon, a resztę pozostawić wyłączoną. Bez kodowania i bez zmian w szablonie.

Moduł Performance przyspiesza sklep dzięki dostarczaniu obrazów WebP (z bezpiecznym powrotem do oryginału), leniwemu ładowaniu, minifikacji i łączeniu CSS/JS, nagłówkom pamięci podręcznej przeglądarki, wskazówkom preload/preconnect oraz nieniszczącej konserwacji bazy danych. Każda optymalizacja ma własny przełącznik, więc można włączyć dokładnie to, co obsługuje szablon, a resztę pozostawić wyłączoną. Bez kodowania i bez zmian w szablonie.

1. Instalacja

  1. W panelu administracyjnym (back office) należy przejść do Modules → Module Manager → Upload a module i wybrać plik ZIP modułu.
  2. Po zainstalowaniu należy kliknąć Configure, aby otworzyć kreator konfiguracji.
Aktualizacje są automatyczne. Aktualizacje są w cenie. Domeny developerskie (.local, .test, localhost) są zawsze dozwolone. Gdy dostępna jest nowa wersja, widać to bezpośrednio w module.

Jeśli zamiast potwierdzenia pojawi się komunikat „Upload failed”, PrestaShop mógł wyłączyć moduł bez powiadomienia: ustawienia i dane pozostają na swoim miejscu. Jak zaktualizować moduł i co zrobić, gdy pojawi się komunikat „Upload failed”.

2. Konfiguracja krok po kroku

Ekran Configure to jedna strona: panel statusu, ustawienia poszczególnych optymalizacji, przyciski akcji i narzędzie do czyszczenia bazy danych.

Status

Panel kondycji tylko do odczytu, wyświetlany na górze strony.

  • Master switch: czy optymalizacje są obecnie włączone (ON) czy wyłączone (OFF).
  • WebP engine (GD/Imagick): czy serwer potrafi generować WebP. Jeśli nie, przepisywanie na WebP jest po prostu pomijane.
  • WebP cache directory writable: czy wygenerowane pliki WebP można zapisywać.
  • Browser-cache .htaccess block: czy reguły pamięci podręcznej są obecnie zapisane.
Status
Status: możliwości serwera w skrócie

General & Images główny przełącznik

Główny przełącznik oraz wszystkie optymalizacje obrazów.

  • Enable optimizations: główny przełącznik. Wyłączony oznacza, że moduł nic nie robi w sklepie.
  • Serve WebP: opakowuje obrazy w <picture> ze źródłem WebP i oryginałem jako rozwiązaniem zastępczym.
  • Lazy-load images / Lazy-load iframes/videos: dodają loading="lazy" tam, gdzie go brakuje. Logo, obrazy w nagłówku strony, pierwsze 3 obrazy oraz obrazy o wysokim priorytecie ładują się od razu.
  • IntersectionObserver fallback: niewielki skrypt dla starszych przeglądarek bez natywnego leniwego ładowania.
  • WebP quality (1-100): jakość kompresji używana podczas generowania WebP.
General & Images
General & Images: główny przełącznik, WebP i leniwe ładowanie

CSS / JS / HTML

Łączenie i minifikacja zasobów. Opcje „inwazyjne” są domyślnie wyłączone, należy je przetestować na szablonie.

  • Combine and minify CSS (invasive) / Combine and minify JS (invasive): domyślnie wyłączone. Włączają natywny mechanizm CCC PrestaShop (łączenie, kompresja i pamięć podręczna): wszystkie lokalne arkusze stylów są łączone w jeden zminifikowany plik, a lokalne skrypty w jeden zminifikowany plik dla każdej pozycji, co może zmienić kolejność ładowania. Po włączeniu należy przetestować szablon.
  • Minify HTML (invasive): usuwa zbędne odstępy; zachowuje pre/textarea/script/style.
  • Exclusions: jeden fragment w wierszu; każdy obraz, którego adres zawiera któryś z nich, pozostaje nietknięty (bez WebP i bez leniwego ładowania).
CSS / JS / HTML
CSS / JS / HTML: łączenie i minifikacja, wykluczenia

Preload / Preconnect

Dodawanie wskazówek dotyczących zasobów, aby przyspieszyć pierwsze renderowanie.

  • Preload: jeden adres URL w wierszu dla czcionek i zasobów krytycznych. Atrybut as jest wykrywany na podstawie rozszerzenia.
  • Preconnect: jedno źródło (origin) w wierszu, np. https://fonts.gstatic.com.
Preload / Preconnect
Preload / Preconnect: wskazówki dla czcionek i źródeł

Critical CSS (advanced) opcjonalne

Wstawianie CSS widocznego bez przewijania do sekcji <head> strony. Opcja zaawansowana, domyślnie wyłączona.

  • Inline critical CSS (invasive): domyślnie wyłączone; wstawia poniższy CSS do sekcji head.
  • Above-the-fold CSS: CSS do wstawienia. Należy zostawić puste, chyba że wiadomo, co wyodrębnić.
Critical CSS (zaawansowane)
Critical CSS: wstawianie stylów widocznych bez przewijania

Database maintenance thresholds

Jak stare muszą być dane przejściowe, zanim narzędzie czyszczące ich dotknie.

  • Abandoned carts older than (days)
  • Connections/guests older than (days)
  • Log rows older than (days)

Każda wartość mieści się w przedziale od 7 do 3650 dni. Progi te sterują narzędziem czyszczącym znajdującym się niżej na stronie.

Progi konserwacji bazy danych
Database maintenance thresholds: limity wieku danych przejściowych

Actions

Przyciski konserwacji jednym kliknięciem.

  • Clear WebP cache: usuwa wygenerowane pliki WebP.
  • Regenerate WebP (batch 500): wstępnie generuje WebP dla maksymalnie 500 obrazów naraz.
  • Write / Remove browser-cache rules: zapisuje reguły pamięci podręcznej w .htaccess wewnątrz odwracalnego bloku # BEGIN/END cll_perf (tworzona jest jednorazowa kopia zapasowa .htaccess.cll_perf-bak). GZIP/Brotli są włączane tam, gdzie dostępny jest moduł Apache.
Akcje
Actions: pamięć podręczna WebP i reguły .htaccess dla pamięci podręcznej przeglądarki

Database cleanup (maintenance)

Nieniszczące czyszczenie danych przejściowych. To nie jest „tryb konserwacji” sklepu: sklep pozostaje dostępny online, a odwiedzający nigdy nie są blokowani.

  • Execute (otherwise dry-run): pozostawienie niezaznaczonego daje podgląd; nic nie jest usuwane, dopóki nie zostanie zaznaczone.
  • Also OPTIMIZE TABLE: opcjonalnie odzyskuje miejsce w tabelach po czyszczeniu.
  • Run maintenance: dotyczy tylko przejściowych danych gości i dzienników starszych niż ustawione progi; prawidłowe zamówienia i klienci nigdy nie są ruszani.
Czyszczenie bazy danych (konserwacja)
Database cleanup: zawsze najpierw dry-run, potem wykonanie

3. Sprawdzenie działania

  • Należy otworzyć panel Status: główny przełącznik powinien być ON, a silnik WebP powinien być „available”.
  • Przy włączonym „Serve WebP” należy wyświetlić kod źródłowy karty produktu: obrazy powinny być opakowane w <picture> ze źródłem .webp.
  • Czyszczenie bazy danych należy najpierw uruchomić jako dry-run: raportuje, ile koszyków, połączeń i wierszy dziennika zostałoby usuniętych, zanim zostanie wykonane.
  • Po zapisaniu reguł pamięci podręcznej przeglądarki należy sprawdzić w .htaccess blok # BEGIN cll_perf.

4. FAQ

Czy optymalizacja może zepsuć szablon?

Opcje „inwazyjne” (łączenie i minifikacja CSS/JS, minifikacja HTML, critical CSS) są domyślnie wyłączone. Należy włączać je pojedynczo i testować; lista Exclusions pozwala pominąć każdy problematyczny obraz.

Co jeśli serwer nie potrafi tworzyć WebP?

Informuje o tym panel Status. Jeśli niedostępny jest zarówno GD, jak i Imagick, przepisywanie na WebP jest po prostu pomijane, a serwowane są oryginalne obrazy.

Czy czyszczenie bazy danych jest bezpieczne?

Tak. Jest nieniszczące, zawsze oferuje dry-run i usuwa tylko przejściowe dane gości i dzienników starsze niż ustawione progi: nigdy prawidłowych zamówień ani klientów.

Czy trzeba edytować szablon?

Nie. Performance działa przez standardowe hooki i jest zgodny z dowolnym szablonem.

🔧 Poznaj moduł i kup go: Wydajność: WebP, lazy load, minifikacja i cache

Powiązane przewodniki

📚 Wszystkie przewodniki po modułach

Powrót do góry