Jak poprawić szybkość PrestaShop

Przyspieszenie sklepu PrestaShop to jedno z najbardziej opłacalnych ulepszeń, jakie możesz wdrożyć: skraca czas oczekiwania klientów, zwiększa konwersję i obniża koszty infrastruktury. Poniższa instrukcja prowadzi od diagnozy i metryk, przez konfigurację panelu, po optymalizację serwera, bazy i front‑endu. Każdy krok możesz wdrażać osobno, testując efekty. Celem jest stabilne cache na wielu poziomach, mniejsza liczba zapytań i szybsze renderowanie pierwszego widoku.

Diagnoza i pomiar: od czego zacząć

Ustal metryki i cele

Zanim coś zmienisz, określ, co chcesz poprawić. Skup się na TTFB (czas odpowiedzi serwera), LCP (Largest Contentful Paint), INP (czas interakcji), CLS (stabilność układu) oraz na liczbie żądań i wadze strony startowej, kategorii i strony produktu. Zapisz wartości bazowe i zdefiniuj akceptowalny poziom (np. LCP do 2,5 s na 75. percentylu).

• Strona startowa: reprezentatywna dla grafik i skryptów promocyjnych.
• Kategoria z filtrami: ujawnia koszt zapytań i sortowania.
• Strona produktu: pokazuje wpływ modułów cross‑sell/komentarzy.

Narzędzia do pomiarów i profilowania

Użyj zestawu narzędzi, aby zobaczyć obraz całościowy i zdiagnozować wąskie gardła:

• Google Lighthouse i PageSpeed Insights – wskażą problematyczne zasoby, kompresja, LCP/INP oraz rekomendacje Core Web Vitals.
• WebPageTest – szczegółowy waterfall, rozdzielnie TTFB, DNS, TLS, pierwsze renderowanie.
• GTmetrix – szybkie porównania po zmianach, filmik z ładowania.
• DevTools w przeglądarce – Performance, Coverage (nadmiar CSS/JS), sieć i mem/cpu.
• Profilowanie PrestaShop – włącz tryb debug i profil SQL, aby namierzyć wolne zapytania.

Włączenie diagnostyki w PrestaShop

W środowisku testowym włącz tryb deweloperski i profiler:

• app/config/parameters.php lub .env: ustaw environment na dev.
• Włącz wyświetlanie panelu debug i czasu generowania strony.
• Aktywuj log slow queries w MySQL/MariaDB, aby wyłapać ciężkie zapytania.

Na podstawie profilera spisz: najwolniejsze kontrolery, zapytania bez indeksowanie, moduły doklejające ciężkie hooki oraz szablony Smarty renderujące za dużo logiki.

Utwórz plan testów A/B i checklistę

Każdą zmianę wdrażaj w osobnej gałęzi lub środowisku staging. Zbieraj pomiary przed i po, minimum z kilkoma przebiegami. Dokumentuj krok, hipotezę, wynik i decyzję. Dzięki temu unikniesz regresji i łatwo wrócisz do poprzedniej konfiguracji, jeśli coś pogorszy metryki.

Konfiguracja PrestaShop: ustawienia wydajności

Ustawienia Smarty i pamięć podręczna

Panel administracyjny → Parametry zaawansowane → Wydajność:

• Kompilacja szablonów: w produkcji ustaw “Nigdy nie kompiluj” i opróżniaj cache po wdrożeniach.
• Pamięć podręczna szablonów: włączona, najlepiej z backendem opartym o Redis lub Memcached.
• Funkcje debug: wyłącz w produkcji, pozostaw tylko na stagingu.

Opróżniaj cache po każdej zmianie w motywie, ale nie rób tego automatycznie przy każdym wejściu użytkownika. Dobrze ustawione TTL i tagowanie ograniczają koszt odświeżeń.

CCC: łączenie, minifikacja i odraczanie

Aktywuj mechanizmy CCC (Combine, Compress, Cache) dla CSS i JS:

• Łącz i minimalizuj arkusze oraz skrypty, aby zmniejszyć liczbę żądań i rozmiar zasobów.
• Odraczaj niekrytyczne JS do końca dokumentu lub ładuj async/defer. Skup się na skryptach modułów marketingowych, chat, heatmapy.
• Wprowadź krytyczny CSS dla above‑the‑fold, resztę doładowuj później.
• Utrzymuj mapę zależności, aby nie zrywać funkcjonalności koszyka i walidacji formularzy.

Po włączeniu CCC sprawdź w DevTools zakładkę Coverage – ile procent CSS nie jest używane na kluczowych podstronach. Usuń lub podziel nadmiarowe pliki.

Obrazy: formaty, rozmiary i lazy loading

W Parametry sklepu → Ruch → Obrazy ustaw precyzyjne wymiary miniaturek. Regeneruj miniatury, usuwając przeskalowania w przeglądarce. Włącz automatyczne lazy loading dla wszystkich listingów i karuzel.

• Wdrażaj WebP lub AVIF z fallbackiem do JPG/PNG.
• Stosuj responsywne atrybuty srcset/sizes; generuj kilka wariantów szerokości.
• Komunikuj przeglądarce preferencje aspektu (width/height) – ogranicza CLS.

Moduły: mniej znaczy szybciej

Każdy moduł to potencjalne hooki, zapytania i zasoby. Przejrzyj listę i:

• Wyłącz i odinstaluj nieużywane moduły, szczególnie te ładujące JS/CSS globalnie.
• Zastąp ciężkie integracje lżejszymi np. gotowy pixel bez bibliotek dodatkowych.
• Używaj hooków warunkowo (np. nie wczytuj slidera na stronach bez slidera).

Ustawienia pamięci i limitów

Wydłuż limity tylko tyle, ile potrzeba: memory_limit dla generowania miniaturek i importów, max_execution_time dla cronów. Zadbaj, by standardowe żądania mieściły się poniżej 1–2 s serwerowo, a długie zadania przenieś do kolejki w tle.

Front‑end: odchudzanie i szybkie renderowanie

Strategia ładowania zasobów

Najpierw użytkownik powinien zobaczyć szkielet i kluczowe elementy. Zastosuj:

• Preload najważniejszych czcionek i krytycznych CSS dla nagłówka, menu, hero.
• Defer/async dla skryptów marketingowych i widgetów stron trzecich.
• Priorytety ładowania obrazów: fetchpriority=high dla largest-contentful elementu.

CSS i JS: porządki, podział i minifikacja

Zidentyfikuj pakiety, które można rozbić. Nie ładuj wszystkiego na każdej podstronie.

• Podziel bundle: podstawowy (koszyk, nawigacja) oraz specyficzny dla widoku (np. filtry).
• Usuń polyfille niepotrzebne dla twojego targetu przeglądarek.
• Usuwaj martwy kod, logikę debug i komentarze; włącz sourcemapy tylko na stagingu.

Wynik potwierdź w zakładce Coverage i Performance. Zredukowana waga CSS/JS skraca czas parsowania i wykonania, co poprawia INP.

Obrazy i multimedia: kompresja bez utraty jakości

• Zastosuj wieloetapową kompresję: optymalizacja plików źródłowych, następnie generowanie wariantów WebP/AVIF i odpowiednie cache po stronie serwera.
• Dla galerii produktu użyj progressive loading i stopniowego ładowania miniatur.
• Wideo osadzaj jako obraz z przyciskiem play, a player dociągaj on‑demand.

Czcionki i ikony

• Subsetting: pozostaw tylko używane znaki (PL, podstawowe znaki). Zmniejsza rozmiar.
• display: swap – zapobiega opóźnieniu tekstu, ogranicza FOUT/FOIT.
• Ikony: preferuj sprite SVG lub font‑icon o minimalnym zestawie glifów.

Cache przeglądarki i nagłówki

Skonfiguruj długie TTL dla statycznych zasobów oraz wersjonowanie plików (query lub hash w nazwie). Ustaw etag/last-modified, brotli/gzip oraz vary dla języka/urządzenia jeśli istnieją wariunki.

• Pliki niezmienne: TTL 1–12 miesięcy, cache‑busting przez nazwę pliku.
• HTML: krótkie TTL, bo zawartość dynamiczna.
• Service Worker: tylko jeśli posiadasz kompetencje PWA i testy regresji.

Serwer i baza danych: fundamenty wydajności

PHP: wersja, FPM i OPcache

Używaj wspieranej, możliwie najnowszej stabilnej wersji PHP, zgodnej z twoją wersją PrestaShop. Włącz i wyreguluj OPcache (rozmiar pamięci, validate_timestamps off w produkcji) oraz FPM z odpowiednim process managerem (dynamic/ondemand) dostosowanym do ruchu.

• pm.max_children i pm.max_requests dostosuj do pamięci i profilu ruchu.
• Ustaw realpath cache i JIT zgodnie z rekomendacjami dla twojej wersji PHP.

Serwer WWW: HTTP i TLS

Preferuj Nginx lub dobrze skonfigurowany Apache z mpm_event. Włącz HTTP/2 lub HTTP/3 (QUIC) dla równoległych pobrań i mniejszych opóźnień. Zadbaj o OCSP stapling, HSTS i nowoczesne szyfry. Minimalizuj liczbę przekierowań i sprawdź TTFB z narzędziami curl/WebPageTest.

MySQL/MariaDB: konfiguracja i indeksowanie

PrestaShop intensywnie korzysta z InnoDB. Skup się na:

• innodb_buffer_pool_size: 50–75% RAM serwera bazy, aby trzymać gorący zestaw danych w pamięci.
• innodb_log_file_size: odpowiednie do wsadu zapisów, aby zmniejszyć checkpointing.
• slow_query_log i long_query_time: rejestruj i analizuj zapytania powolne.
• EXPLAIN i indeksy złożone: dodaj indeksy dla kolumn sortowanych i filtrowanych w listingu (np. price, manufacturer, active, id_category_product).
• Unikaj SELECT *, ograniczaj pola, paginuj z użyciem indeksów rather than offset heavy – rozważ keyset pagination dla długich list.

Sprawdź, czy moduły filtrów nie generują kaskady zapytań, oraz czy cache warstwowy ogranicza powtarzalne pobrania atrybutów.

Pamięci podręczne: obiektowa i treści

Warstwuj cache: application (Smarty), object cache oraz reverse proxy/CDN. Dla cache obiektowego wybierz Redis – szybki i przewidywalny. Przechowuj tam sesje i cache zapytań, ogranicz I/O na dysku. Memcached to alternatywa, lecz Redis daje dodatkowe struktury i trwałość.

• Tagowanie cache: umożliwia precyzyjne odświeżanie po zmianach katalogu.
• TTL różne dla stron: krótki dla koszyka i konta, dłuższy dla statycznych bloków.
• Unikaj nadmiernego odświeżania: batchuj invalidacje po imporcie.

CDN i geograficzna dystrybucja

Włącz dostarczanie statycznych zasobów przez CDN z HTTP/2/3 i edge cache. Skonfiguruj domenę bez cookies dla obrazów, CSS i JS. Dla obrazów z wariantami rozmiarów skorzystaj z funkcji optymalizacji on‑the‑fly po stronie CDN lub generuj warianty z góry.

• Ustaw regionalne POPy najbliżej głównych rynków.
• Używaj origin shield, aby zmniejszyć hit na serwer źródłowy.
• Pamiętaj o invalidacji ścieżek po deployu lub wersjonowaniu plików.

Bezpieczeństwo i stabilność

Aktualizuj PHP, serwer www, bazę i PrestaShop. Włącz rate limiting na endpointach wrażliwych (wyszukiwarka, logowanie), aby złośliwe skany nie zjadały zasobów. Monitoruj błędy 500/502 i czas odpowiedzi. Sprawdzaj, czy cron nie uruchamia ciężkich zadań w godzinach szczytu.

Utrzymanie, dobre praktyki i automatyzacja

Workflow: staging, kopie i testy regresji

Pracuj na środowisku staging z danymi z maskowanego dumpa produkcyjnego. Wdrażaj zmiany przez CI/CD, z automatycznym budowaniem assetów i smoke testami. Miej szybki rollback. Testuj krytyczne ścieżki (listowanie, filtr, koszyk, checkout) przed każdym releasem.

Cron i zadania w tle

• Planowanie: generowanie feedów, synchronizacje ERP/marketplace i importy zrób poza godzinami szczytu.
• Podział: jedno ciężkie zadanie rozbij na mniejsze batch’e, aby uniknąć timeoutów.
• Kolejki: rozważ użycie workerów do wysyłek e‑mail, aktualizacji stanów, przeliczania cen. Ogranicz obciążenie requestów użytkowników.

Higiena katalogu i wyszukiwania

Przemyśl strukturę kategorii i liczebność wariantów. Zadbaj, aby filtry nie tworzyły nieindeksowanych, kosztownych zapytań. Cache’uj i paginuj wyniki. Jeśli masz bardzo duży katalog, rozważ dedykowany silnik wyszukiwania (np. Elasticsearch u partnerów), ograniczając koszt LIKE i JOIN w bazie.

Wtyczki i motywy: standardy jakości

• Wybieraj motywy modularne, które ładują zasoby tylko w potrzebnych widokach.
• Audytuj moduły komercyjne: sprawdź liczbę zapytań, rozmiar JS, wpływ na TTFB.
• Aktualizacje rób po testach – nowsza wersja często poprawia profilowanie i zużycie pamięci.

Monitorowanie i alerty

Wdróż stały monitoring syntetyczny i rzeczywisty (RUM). Ustaw alerty na wzrost TTFB, spadek hit ratio cache, błędy 5xx i niską dostępność. Zbieraj logi powolnych zapytań i śledź trendy – wyłapiesz regresje po deployu i sezonowe anomalie.

Checklist: wdrażaj krok po kroku

• Diagnoza: baseline Lighthouse, WebPageTest, profiler PS; zrzut slow queries.
• PrestaShop: Smarty cache, CCC, odraczanie JS, responsywne obrazy, lazy loading.
• Front‑end: krytyczny CSS, minifikacja, preload czcionek, brotli.
• Serwer: aktualne PHP, FPM, OPcache, Nginx/Apache event, HTTP/2.
• Baza: InnoDB tuning, log slow, EXPLAIN, brakujące indeksowanie.
• Cache: obiektowy Redis, długie TTL, wersjonowanie zasobów.
• Sieć: CDN, cookie‑less statics, edge rules, origin shield.
• Proces: staging, CI/CD, cron poza szczytem, monitoring metryk.

Przykładowy plan na 7 dni

• Dzień 1: Pomiary bazowe, identyfikacja 3 najwolniejszych widoków, profil SQL.
• Dzień 2: Włączenie CCC, porządki w modułach, wyłączenie zbędnych hooków.
• Dzień 3: Obrazy – generacja WebP/AVIF, srcset, kompresja, włączenie lazy loading.
• Dzień 4: Krytyczny CSS, podział bundli, odroczenie skryptów zewnętrznych.
• Dzień 5: Konfiguracja PHP‑FPM, OPcache, serwer www z HTTP/2, brotli.
• Dzień 6: Tuning MySQL, EXPLAIN, dodanie brakujących indeksów, testy obciążeniowe.
• Dzień 7: CDN, wersjonowanie zasobów, polityki cache, końcowe RUM i Lighthouse.

Częste pułapki i jak ich unikać

• Nadmierny purge cache po deployu – używaj tagowania i segmentowego odświeżania.
• Ładowanie skryptów śledzących w head – przenieś je na koniec i wczytuj asynchronicznie.
• Ogromne obrazy w sliderach – limituj maksymalny rozmiar i stosuj WebP.
• Moduły, które “dla wygody” ładują swoje JS wszędzie – ograniczaj do konkretnych widoków.
• Brak testów po aktualizacji – zawsze staging i szybki smoke test koszyka.

Zaawansowane wskazówki

• Edge Side Includes: fragmentacja cache HTML na CDN dla bloków (np. koszyk bez cache, reszta z cache).
• Preconnect/DNS‑prefetch do kluczowych domen trzecich (płatności, analityka).
• Server Push jest przestarzały – preferuj preload i poprawne priorytetyzowanie zasobów.
• Reguły anti‑bloat: limituj liczbę widgetów zewnętrznych; każdy to nowe żądania i JS.

Po wdrożeniu powyższych kroków regularnie wracaj do metryk. Utrzymanie efektów wymaga dyscypliny w dodawaniu modułów, mediów i integracji oraz stałego przeglądu, czy cache oraz warstwy Redis/CDN działają z wysokim hit ratio. Dzięki temu sklep PrestaShop pozostanie szybki, stabilny i ekonomiczny w utrzymaniu, nawet przy rosnącym ruchu i katalogu.