Jak poprawić szybkość PrestaShop krok po kroku

Szybki sklep to mniejsza liczba porzuconych koszyków, lepsze pozycje w Google i niższe koszty infrastruktury. Ten przewodnik przeprowadzi Cię przez konkretne, sprawdzone działania, dzięki którym przyspieszysz PrestaShop bez utraty funkcjonalności. Zaczniemy od rzetelnego pomiaru, wyciągniemy wnioski i wdrożymy optymalizacje od konfiguracji panelu, przez serwer i bazę, aż po front‑end. W efekcie skrócisz czasy ładowania i wydajność sklepu wzrośnie, a TTFB oraz LCP spadną do bezpiecznych wartości.

Audyt i pomiary bazowe

Krok 1: Zmierz gdzie naprawdę tracisz czas

Zanim cokolwiek zmienisz, wykonaj pomiar z kilku narzędzi i lokalizacji. Użyj PageSpeed Insights (mobile i desktop), Lighthouse w Chrome, WebPageTest oraz testów z różnych krajów istotnych dla Twoich klientów. Zbieraj metryki LCP, INP, CLS, a także czas pierwszego bajtu i czas do interakcji. Zwróć uwagę, czy różnice dotyczą tylko stron kategorii, karty produktu, checkoutu czy również strony głównej.

Równolegle obejrzyj sieć w DevTools: posortuj requesty po czasie i rozmiarze, sprawdź powtarzalne pliki CSS/JS, brakujące nagłówki cachowania, zbyt duże obrazy i wielokrotne zapytania XHR do wyszukiwania lub rekomendacji. Zanotuj, które zasoby dominują w waterfall i gdzie występują przerwy na DNS, TLS, negocjację HTTP/2 oraz wywołania blokujące renderowanie.

• Zapisz zrzuty ekranu i wyeksportuj raporty do późniejszego porównania.
• W WebPageTest uruchom 3 powtórzenia i porównuj medianę z cache i bez.
• Skonfiguruj narzędzia RUM (np. GA4, Plausible, Sentry Performance), aby poznać realne czasy użytkowników.

Krok 2: Włącz profilowanie i logi pod obciążeniem

Na środowisku testowym włącz tryb debugowania i profiler (w PrestaShop 1.7/8 oparty o Symfony). Przechwyć kilka typowych ścieżek użytkownika: wejście z listingu, filtracja, karta produktu, dodanie do koszyka, checkout. Zwróć uwagę, ile czasu zajmują poszczególne kontrolery, zapytania do bazy, kompilacja Smarty, generowanie hooków i moduły zewnętrzne.

W tym samym czasie uruchom krótkie testy obciążeniowe (np. k6, JMeter) na 10–30 równoległych użytkowników, by wyłapać wąskie gardła, które nie wyjdą w pojedynczym profilu. Loguj czasy zapytań do bazy (slow query log), błędy PHP i timeouty. Dzięki temu oddzielisz problemy skali (blokady w bazie, kolejkowanie na PHP‑FPM) od problemów front‑end (zbyt duże assety).

Krok 3: Ustal cele i priorytety

Wyznacz docelowe progi: LCP poniżej 2,5 s na 75. percentylu mobile, INP poniżej 200 ms, CLS poniżej 0,1. Ustal budżet wydajności: maksymalny rozmiar JS poniżej 200–300 kB skompresowany, CSS poniżej 100–150 kB, obrazy produktu < 200 kB na listingu (responsive). Zdecyduj, które obszary optymalizujesz jako pierwsze: na ogół checkout i listing kategorii dają największy zwrot z inwestycji.

Przygotuj plan wdrożeń w iteracjach: najpierw ustawienia konfiguracji i szybkie zyski, następnie zmiany serwerowe, dalej refaktoryzacja front‑end i porządki w danych. Po każdym kroku wykonuj ponowne pomiary, aby potwierdzić realny efekt.

Konfiguracja w panelu PrestaShop

Krok 1: Smarty, szablony i CCC

W panelu administracyjnym przejdź do Zaawansowane parametry → Wydajność. Ustaw kompilację szablonów na „Nigdy nie kompiluj ponownie” dla trybu produkcyjnego i włącz magazynowanie szablonów. Włącz także łączenie, kompresję i kompilację (CCC) dla CSS i JS. Przenieś skrypty na koniec dokumentu i ustaw mechanizmy opóźniania inicjalizacji, jeśli motyw to wspiera. To redukuje liczbę żądań i czas blokowania renderowania.

Jeśli korzystasz z motywu potomnego lub często wprowadzasz zmiany, dopracuj proces wdrożeń: buduj i minifikuj assety w CI/CD, a następnie odświeżaj tylko niezbędne pliki, aby uniknąć zbędnej rekompilacji w produkcji.

Krok 2: Włącz i dobierz rodzaj cache

W tej samej sekcji włącz mechanizm cache. Dla małych sklepów wystarczy system plików, ale przy większym ruchu przejdź na pamięć współdzieloną (np. Redis lub Memcached). Dobry mechanizm cache znacząco odciąża bazę i skraca czasy odpowiedzi kontrolerów, szczególnie dla gości. Pamiętaj o prawidłowych TTL oraz czyszczeniu po zmianie cen, stanów magazynowych i publikacji nowych produktów.

Jeśli obsługujesz głównie ruch niezalogowany, rozważ pełno‑stronicowe buforowanie (FPC) na warstwie serwera www lub Varnish. Zadbaj o poprawną inwalidację: różnicuj cache po języku, walucie, wersji urządzenia i koszyku (dla zalogowanych wyłączaj FPC).

Krok 3: Media serwery i CDN

Skonfiguruj serwery multimediów (Media servers) w panelu, wskazując alternatywne domeny do serwowania obrazów i assetów statycznych. W prostych przypadkach możesz użyć subdomen plików. Dla globalnego ruchu wdroż sieć dostarczania treści: CDN z edge cache przyspieszy ładowanie, skróci drogę do użytkownika i zapewni HTTP/2 lub HTTP/3 na brzegu. Dodaj nagłówki Cache‑Control i ETag, a dla statycznych wersjonowanych plików ustaw długie czasy życia.

Zadbaj o poprawne CORS dla fontów i plików z obcej domeny oraz o preconnect/dns‑prefetch do hostów zewnętrznych. Jeśli korzystasz z usług trzecich (czat, mapy, analityka), agreguj i ładuj je warunkowo, aby ograniczyć dodatkowe round‑tripy.

Krok 4: Obrazy – generowanie, formaty i reguły

W Ustawieniach → Obrazy zdefiniuj rozmiary miniatur odpowiadające realnemu użyciu w motywie. Usuń przestarzałe typy i wygeneruj ponownie miniatury. Włącz kompresję na poziomie serwera, a jeśli motyw/wersja wspiera nowoczesne formaty, zastosuj WebP z fallbackiem do JPEG/PNG. Upewnij się, że atrybuty width/height są obecne, aby zapobiegać skokom layoutu (CLS).

Na listingu ogranicz liczbę produktów na stronę i rozważ leniwe ładowanie obrazów (loading=”lazy”) poza pierwszym ekranem. Pamiętaj o atrybucie decoding=”async” dla obrazów niekrytycznych i preloading dla hero-image, gdy LCP jest obrazem.

Krok 5: Konfiguracja sesji i cookies

Ustaw sesje tak, aby minimalizować zapisy w bazie: trzymanie sesji w pamięci współdzielonej zmniejsza obciążenie i opóźnienia. Skróć czas życia cookies, które nie są krytyczne, i ogranicz ich liczbę, by nie powiększać każdego żądania do serwera. To szczególnie ważne przy zasobach statycznych serwowanych z wielu domen.

Serwer, PHP i baza danych

Krok 1: Dobierz infrastrukturę do ruchu

Największe skoki wydajności przynosi sensowny dobór hostingu: szybkie CPU, dyski NVMe, wystarczająca pamięć RAM i izolowane procesy PHP‑FPM. Włącz HTTP/2 lub HTTP/3, TLS 1.3 oraz Keep‑Alive. Jeżeli obsługujesz skoki ruchu (kampanie, święta), zaplanuj autoskalowanie lub przynajmniej skalowanie pionowe z wyprzedzeniem. Zadbaj o monitoring zasobów: CPU, iowait, wykorzystanie pamięci i liczby workerów.

Krok 2: Konfiguracja PHP-FPM i OPcache

Zaktualizuj środowisko do stabilnej wersji PHP wspieranej przez Twoją wersję PrestaShop. Włącz i skoryguj OPcache: rozmiar pamięci, liczba kluczy i harmonogram ponownej walidacji. Usuń rozszerzenia i moduły debugujące z produkcji. Skonfiguruj pulę PHP‑FPM: pm = dynamic/ondemand, właściwe limity children, min/max spare servers, aby uniknąć kolejek i częstych forków procesów.

W php.ini ustaw rozsądny memory_limit, realpath_cache_size i dłuższe realpath_cache_ttl. Włącz JIT tylko po testach – w e‑commerce często nie daje zauważalnych korzyści i może wprowadzać niestabilność.

Krok 3: Tuning bazy danych i analiza zapytań

Skonfiguruj instancję MySQL lub MariaDB pod workload transakcyjny: innodb_buffer_pool_size na 50–70% pamięci serwera, log slow queries z progiem np. 200–500 ms, rozsądne innodb_log_file_size i flush method. Wyłącz przestarzałe mechanizmy, które nie działają w nowoczesnych wersjach (query cache).

Przeanalizuj najwolniejsze zapytania (EXPLAIN) i dodaj brakujące indeksy w tabelach o dużym wolumenie: ps_orders, ps_order_detail, ps_cart, ps_cart_product, ps_connections, ps_pageview, ps_product, ps_stock_available. Upewnij się, że kolumny używane w filtrach i JOINach są pokryte indeksami z dobrą selektywnością. Rozważ partycjonowanie tabel logów lub przeniesienie metryk analitycznych do narzędzi zewnętrznych, aby nie obciążać produkcyjnej bazy.

Krok 4: Warstwa cache i sesje

Skonfiguruj Redis jako magazyn obiektów i sesji. Dzięki temu odciążysz bazę i skrócisz czasy generowania stron dla gości i zalogowanych. Dla stron publicznych wprowadź edge‑cache po stronie serwera www (Nginx microcache) lub Varnish z regułami Vary. Zaplanuj invalidację po zmianach w katalogu produktów i cennikach; rozważ pre‑warm cache po deployu i przy dużych kampaniach.

Dodatkowo ustaw kompresję na serwerze: gzip dla tekstu, ewentualnie brotli na Nginx. Pamiętaj o nagłówkach Cache‑Control i vary na akceptowane formaty, aby uniknąć mieszania wersji.

Krok 5: Serwer www i transport

Optymalizuj konfigurację Nginx/Apache: rozsądne buforowanie proxy, duże sendfile, http2_max_concurrent_streams, limity keepalive, kompresję i serwowanie plików statycznych bez angażowania PHP. Dla uploadów i webhooków ustaw większe time‑outy tylko na dedykowanych lokacjach. Dodaj HSTS i OCSP stapling, aby skrócić negocjację TLS.

Wyeliminuj zewnętrzne bloki: opóźniaj ładowanie narzędzi trzecich (tag manager, czat), ładuj je asynchronicznie i tylko na stronach, gdzie są potrzebne. To często uwalnia dziesiątki procent czasu na mobile.

Front-end i zasoby statyczne

Krok 1: Krytyczne CSS i eliminacja zasobów blokujących

Zidentyfikuj krytyczne style dla pierwszego ekranu (critical CSS) i wstrzyknij je inline, a resztę CSS ładuj asynchronicznie z atrybutem preload i rel=”stylesheet” po onload. Połącz pliki, ale nie doprowadzaj do gigantycznego jednego CSS obejmującego wszystkie podstrony – rozbijaj per kontekst (listing, produkt, checkout). Usuń nieużywane reguły (purge) z bibliotek UI, aby zejść z dziesiątek do kilku kilobajtów.

Skrypty ładuj z defer/async, unikaj synchronizacji na head. Przeniesienie inicjalizacji widgetów pod eventy interakcji (np. otwarcie sekcji opinii) dodatkowo skróci postrzegany czas gotowości do działania.

Krok 2: Obrazy responsywne i optymalizacja formatów

Używaj atrybutów srcset i sizes, aby przeglądarka pobierała najmniejszy możliwy wariant obrazu. Zadbaj o właściwe proporcje i rozdzielczości miniatur. Konwertuj grafiki do nowoczesnych formatów, a jeśli motyw nie wspiera automatyki, wdroż proces konwersji i wersjonowania plików przy deployu. Dla ikon preferuj SVG i sprite’y zamiast wielu małych PNG.

Stosuj leniwe ładowanie list produktów i sekcji rekomendacji, wczytując kolejne karty dopiero przy przewijaniu. Wstrzymuj ciężkie galerie i wideo do momentu interakcji. Zadbaj o a11y: alt, role i focus – poprawi to nie tylko SEO, ale i dostępność.

Krok 3: Fonty bez blokowania renderu

Wgraj fonty na własny serwer i użyj preload dla najważniejszych odmian. Dodaj font-display: swap, aby tekst pojawiał się natychmiast. Zmniejsz zestaw znaków (subset) do potrzebnych języków i unikaj ładowania ciężkich, zbędnych wariantów grubości. Rozważ zmniejszenie liczby rodzin do jednej‑dwóch – każdy dodatkowy plik to kolejne setki milisekund.

Krok 4: Redukcja rozmiaru i złożoności DOM

Przejrzyj motyw pod kątem nadmiarowych wrapperów, pustych węzłów, powtarzanych komponentów i wstrzykniętych snippetów modułów. Skondensuj karuzele i sekcje marketingowe. Na listingu ustaw mniejszą liczbę produktów na stronę i wyłącz zbyt agresywne infinite scroll. Ogranicz liczbę filtrów jednocześnie widocznych, a resztę schowaj pod rozwijane sekcje.

W modułach, które wstrzykują JS/CSS wszędzie, wprowadź warunkowe ładowanie tylko na potrzebnych podstronach. Zastąp ciężkie biblioteki lżejszymi alternatywami (np. rezygnacja z jQuery na stronach, gdzie nie jest potrzebne).

Krok 5: Kontrola jakości i regresji

Po każdej zmianie uruchom testy wizualne i Lighthouse w CI. Porównuj metryki, aby nie dopuścić do regresji. Wdróż budżety wydajności: pipeline przerywa się, gdy zasoby przekroczą ustalone limity. To najskuteczniejsza ochrona przed „przytyciem” front‑endu po kolejnych wdrożeniach.

Dane, moduły i utrzymanie

Krok 1: Audyt modułów i hooków

Wykonaj przegląd zainstalowanych rozszerzeń: wyłącz te nieużywane, zduplikowane lub dublujące funkcje motywu. Sprawdź, ile zapytań i ile czasu dodają na kluczowych podstronach. Moduły integracyjne często dorzucają requesty do zewnętrznych API – ładuj je leniwie i tylko tam, gdzie naprawdę działają (np. skrypty map w sklepie stacjonarnym tylko na stronie kontaktu).

Oceń wpływ nadpisań (override) klas i kontrolerów – niektóre implementacje zmieniają logikę zapytań lub ładują dodatkowe dane, co spowalnia generowanie widoków. Dobrą praktyką jest utrzymywanie listy modułów krytycznych i ich wersji, a zmiany wprowadzać na stagingu z równoległymi pomiarami.

Krok 2: Porządki w danych i harmonogram zadań

Wyczyść tabele logów i telemetrii – koszyki porzucone sprzed lat, sesje gości, stare wpisy w ps_connections i powiązanych tabelach. Ustal cykliczny cron do archiwizacji lub usuwania niepotrzebnych rekordów. Indeksuj na bieżąco wyszukiwanie i atrybuty, a reindeksację uruchamiaj poza godzinami szczytu. Regularne sprzątanie zmniejsza rozmiar bazy i przyspiesza backup oraz replikację.

Ustaw politykę wygaszania starych reguł promocji, kuponów i katalogowych zasad cenowych. Unikaj setek nakładających się warunków, które spowalniają kalkulację koszyka i cache cen. Przeglądaj raporty slow query po każdej większej kampanii – to wtedy wychodzą problemy z danymi brzegowymi.

Krok 3: Wyszukiwarka i filtrowanie

Jeśli katalog jest duży, dołóż silnik wyszukiwania zewnętrznego (np. Elasticsearch/OpenSearch) i ogranicz w PrestaShop kosztowne LIKE w bazie. Dla mniejszych katalogów zadbaj o sprawne indeksy i właściwy dobór pól w indeksacji. Faceted search konfiguruj tak, by nie generować tysięcy kombinacji filtrów – lepiej mniej, ale szybszych i użytecznych filtrów.

Krok 4: Monitoring, alerty i SLO

Wdróż metryki techniczne (Prometheus, Grafana) oraz RUM. Ustal cele SLO dla czasów odpowiedzi i stabilności. Zautomatyzuj alerty na skoki czasu odpowiedzi backendu, wzrost błędów 5xx, spadek hit‑ratio cache czy wzrost rozmiaru kolejek. Dzięki temu wykryjesz problem, zanim zrobią to klienci.

Krok 5: Przygotowanie na szczyty ruchu

Przed kampaniami prewencyjnie rozgrzej cache, zwiększ liczbę workerów PHP‑FPM i przygotuj plan awaryjny: wyłączanie niekrytycznych modułów, skrócenie TTL w FPC, uproszczenie strony głównej. Zaplanuj proces rollbacku i miej gotowe checklisty. Po wydarzeniu wróć do standardowych ustawień i przeanalizuj logi, by wyciągnąć wnioski na przyszłość.