Jak przyspieszyć PrestaShop na serwerze

Szybkość sklepu wpływa bezpośrednio na sprzedaż i pozycje SEO. Ten przewodnik pokazuje praktyczne kroki, jak przyspieszyć PrestaShop na poziomie infrastruktury i konfiguracji, bez przepłacania za zasoby. Skupimy się na diagnozie, konfiguracji WWW i PHP, bazie danych, pamięciach podręcznych oraz ustawieniach aplikacji. Każdy krok jest opisany tak, abyś mógł wdrożyć go samodzielnie lub przekazać adminowi z jasnymi zaleceniami i kryteriami sukcesu.

Diagnoza i metodyka optymalizacji

Ustal cele i metryki, zanim coś zmienisz

Zdefiniuj metryki, które będziesz śledzić: TTFB (czas do pierwszego bajtu), czas pełnego załadowania, LCP, FID, CLS, średnie i 95 percentyl. Określ budżet wydajności (np. LCP ≤ 2,5 s dla ruchu mobilnego). Zaznacz kluczowe ścieżki użytkownika: strona główna, listing kategorii, karta produktu, koszyk, checkout. Mierz oddzielnie dla ruchu zalogowanego i niezalogowanego, bo ścieżki cache i personalizacja różnią się znacząco.

Profilowanie: gdzie ucieka czas

Włącz profilowanie po stronie aplikacji i serwera. W środowisku testowym uruchom narzędzia APM (np. Blackfire, New Relic, Tideways), aby zidentyfikować wolne kontrolery, zapytania SQL i wąskie gardła w I/O. Włącz log wolnych zapytań w bazie (slow query log) i ustaw próg np. 300 ms. Sprawdź logi serwera WWW pod kątem błędów 5xx i opóźnień w odpowiedziach. Zanotuj, które moduły Presta generują najwięcej hooków i zapytań.

Testy obciążeniowe zamiast zgadywania

Zanim wdrożysz zmiany w produkcji, użyj narzędzi do testów: k6, JMeter lub Locust. Przygotuj realistyczne scenariusze (proporcje stron: 60% listing, 25% produkt, 10% koszyk, 5% checkout). Rozdziel strumienie między gości a zalogowanych. W testach uwzględnij RTT z typowych lokalizacji klientów. Zbieraj czasy odpowiedzi, liczbę błędów, saturację CPU, IO wait, zużycie pamięci oraz limity połączeń.

Szybka checklista przed zmianami

• Kopia zapasowa bazy i plików, snapshot VPS.
• Plan wycofania zmian i okno serwisowe.
• Środowisko staging odzwierciedla produkcję.
• Zdefiniowane kryteria akceptacji (np. -30% TTFB na karcie produktu, -50% czas generowania PDF faktury).
• Monitoring na czas wdrożenia (APM + metryki systemowe).

Konfiguracja serwera WWW i PHP

Wybór i aktualizacja środowiska wykonawczego PHP

Aktualizuj PHP do stabilnej wersji wspieranej przez Twój sklep i moduły (np. 8.1/8.2). Zaktualizuj rozszerzenia i zależności (intl, mbstring, gd/imagick). Sprawdź kompatybilność motywu i modułów na stagingu. Podnieś memory_limit zgodnie z rozmiarem katalogu i zestawem modułów, ale monitoruj realne zużycie pamięci procesów PHP, by nie przewymiarować.

Konfiguracja PHP-FPM pod ruch produkcyjny

Ustal model procesu: dynamic dla większości sklepów, static tylko przy stałym, przewidywalnym ruchu i precyzyjnie przydzielonych rdzeniach. Dobierz pm.max_children na podstawie RAM: zsumuj RSS jednego procesu pod typowym obciążeniem i policz ile procesów zmieści się w dostępnym RAM z buforem 30%. Ustaw pm.max_requests (np. 500–2000) by ograniczyć fragmentację pamięci. Włącz request_terminate_timeout i slowlog z progiem 3–5 s, aby łapać wolne żądania.

OPTYMALIZACJA OPCODE: OPcache i preloading

Włącz OPcache i dobrą konfigurację: memory_consumption tak, by nie pojawiały się restarty z braku pamięci, validate_timestamps=0 na produkcji (z wdrożeniami przez deploy), revalidate_path=0, max_accelerated_files dostosowane do liczby plików PHP w sklepie i modułach. Rozważ preloading dla często używanych klas, jeżeli wersja PHP i infrastruktura na to pozwala. Po wdrożeniu obserwuj hit rate i liczbę restartów w metrykach.

Serwer WWW: Nginx/Apache, protokoły i kompresja

Skonfiguruj keep-alive i wielowątkowość zgodnie z profilem ruchu. Włącz HTTP/2 dla domeny głównej i zasobów statycznych. Zadbaj o TLS 1.3, OCSP stapling, sesje TLS i rozsądne krzywe ECDSA. Włącz kompresję GZIP (lub Brotli, gdy dostępne) dla tekstowych zasobów: HTML, CSS, JS, JSON, SVG. Pomiń kompresję obrazów i archiwów. Skonfiguruj cache-control, ETag i vary dla zasobów statycznych i API. Dopilnuj, aby nie wysyłać Set-Cookie przy plikach stałych, aby nie psuć cachowania przeglądarki i proxy.

Reverse proxy i warstwa frontowa

Jeżeli stosujesz reverse proxy (np. Nginx przed Apache, bądź load balancer), zadbaj o prawidłowe nagłówki X-Forwarded-*. Rozważ lokalny cache na poziomie Nginx dla gości (short TTL, vary po cookies), ale pamiętaj o wykluczeniu koszyka, konta i checkoutu. Varnish może przyspieszyć ruch gości, jednak wymaga precyzyjnej polityki omijania dynamicznych komponentów i czasem ESI dla bloków mini-koszyka.

Pliki, I/O i system

Włącz sendfile, ustaw właściwe limity ulimit i worker_connections. Na dyskach SSD używaj noatime i monitoruj IOPS. Zadbaj o rotację logów, by nie zapełniały dysku. W kontenerach przydziel realne limity CPU i pamięci oraz sterowniki cgroup v2, aby uniknąć zgubnych throttlingów.

Baza danych i pamięć podręczna

Projekt i konfiguracja MySQL dla sklepu

Upewnij się, że wszystkie tabele krytyczne działają na InnoDB. Ustaw innodb_buffer_pool_size na 60–75% RAM serwera bazy (po odjęciu innych usług), a innodb_log_file_size i innodb_log_buffer_size tak, by ograniczyć flush. Włącz innodb_flush_method=O_DIRECT, ustaw innodb_flush_log_at_trx_commit=1 dla pełnej trwałości (ew. 2 gdy ważniejsza jest wydajność i akceptujesz ryzyko). Wyłącz query_cache (w nowszych wersjach i tak usunięty), zwiększ table_open_cache, tmp_table_size i max_heap_table_size, ale monitoruj, by nie tworzyły się on-disk temp tables.

Indeksowanie i optymalizacja zapytań

Przeanalizuj EXPLAIN dla najcięższych zapytań z logu wolnych zapytań. Upewnij się, że pola filtrowań i sortowania w listingach mają odpowiednie indeksy złożone. Dla wyszukiwania pełnotekstowego używaj FULLTEXT lub rozważ zewnętrzny silnik (np. OpenSearch/Elasticsearch) przy dużych katalogach, ograniczając obciążenie bazy. Oczyszczaj duże tabelki telemetryczne: ps_connections, ps_guest, ps_statssearch, archiwizuj starsze dane. Nie nadużywaj LIKE z leading wildcard, bo zabija indeksy.

Pamięci podręczne w warstwie danych: Redis i friends

Przenieś sesje PHP oraz cache obiektów aplikacyjnych do Redis. Użyj separacji logicznych DB (SELECTEDB) lub instancji, aby odizolować sesje od cache. Zadbaj o politykę LRU i limit pamięci. W Presta użyj modułów wspierających Redis dla cache i sessions. Włącz persistent connections i monitoruj latencję oraz trafienia cache. Jeżeli używasz Memcached, dopasuj rozmiary slabów i unikanie oversized itemów.

Transakcje, blokady i skalowanie

Minimalizuj długie transakcje, które blokują wiersze, zwłaszcza w checkout. Rozdziel workload: odczyty raportowe kieruj do replik tylko, jeśli aplikacja jest na to gotowa, a opóźnienie replikacji jest małe i przewidywalne. Użyj poolingu połączeń (proxy SQL) w środowiskach o bardzo dużej liczbie krótkich żądań.

Konfiguracja aplikacji i zasobów

Tryby wydajności i cache w ustawieniach sklepu

Włącz tryb produkcyjny i pamięć podręczną. Dla silnika szablonów wyłącz sprawdzanie zmian szablonów i włącz kompilację tylko po wdrożeniu. Włącz scalanie i minifikację CSS/JS (CCC), opóźnij ładowanie skryptów, przenieś ciężkie JS na dół. Zapisuj cache na szybkich dyskach lub w pamięci (Redis/Memcached), a nie w gniazdach NFS. Regularnie czyść i przebudowuj cache po wdrożeniach, unikając ręcznego kasowania katalogów w losowych momentach ruchu.

Media, obrazy i sieć dostarczania treści

Skonfiguruj generowanie miniaturek i konwersję do WebP/AVIF, gdy motyw i przeglądarki docelowe to wspierają. Stosuj lazy-load, a krytyczne obrazy preloaduj. Rozdziel domenę statyczną (cookieless) dla CSS/JS/obrazów, aby nie wysyłać ciastek. Rozważ CDN z POP-ami w krajach, gdzie masz sprzedaż. Ustaw odpowiednie nagłówki cache i wersjonowanie plików (cache busting), aby minimalizować missy po deployu.

Moduły, hooki i nadpisania

Audytuj moduły: wyłącz i odinstaluj zbędne, a krytyczne aktualizuj. Sprawdź, które hooki są wywoływane na każdej stronie i czy nie wykonują kosztownych operacji (np. zapytań bez indeksów). Unikaj wielokrotnych wywołań API w czasie renderu. W motywie zredukuj liczbę zapytań, łącząc dane w mniejsze paczki. Dla dynamicznych bloków zastosuj mikrocache po stronie aplikacji z krótkim TTL.

Checkout i koszyk

Checkout to najwrażliwszy obszar. Ogranicz liczbę zewnętrznych skryptów, walidacji i widżetów. Buforuj adresy i metody dostawy po stronie serwera z krótkim TTL, ograniczając zapytania do bazy. Unikaj synchronizacji koszyka na każdym żądaniu – aktualizuj tylko, gdy zmienia się jego stan. Mierz end-to-end czas przejścia przez checkout i 95 percentyl, nie tylko średnią.

Wyszukiwarka i katalog

Przy dużym katalogu (setki tysięcy produktów) wdroż zewnętrzny silnik wyszukiwania, aby odciążyć bazę i przyspieszyć autouzupełnianie. Ustaw harmonogram indeksacji poza godzinami szczytu. W listingach ogranicz liczbę filtrów wykonywanych w locie, stosuj preagregacje lub indeksy złożone dostosowane do najpopularniejszych kombinacji filtrów.

Infrastruktura, skalowanie i operacje

Wybór środowiska i skalowanie w poziomie

Dla małych sklepów wystarczy zoptymalizowany VPS. Dla rosnących – rozdziel role: WWW+PHP, baza, cache, storage. Dla dużych – load balancer, kilka frontów WWW, osobny serwer bazy i replik, dedykowany cache, niezależny storage na media. Planuj sticky sessions tylko, gdy to konieczne; lepiej trzymaj sesje w zewnętrznym magazynie. Projektuj pod bezstanowość, aby łatwiej skalować fronty w poziomie.

Monitoring, alerting i SLO

Zbieraj metryki: CPU, RAM, IO, sieć, liczbę procesów PHP, kolejki żądań, czasy odpowiedzi per endpoint, błędy. Ustal SLO dla stron krytycznych (np. 99% żądań karty produktu < 600 ms TTFB). Skonfiguruj alerty przy przekroczeniach progów i anomaliach (np. spadek hit rate cache). Analizuj tygodniowe trendy, nie tylko incydenty.

Strategia wdrożeń i porządków

Automatyzuj deploy: build artefaktów, migracje bazy z planem wycofania, czyszczenie cache bez przestojów. Ustal harmonogram porządków: czyszczenie starszych logów, archiwizacja tabel statystyk, regeneracja miniaturek poza godzinami szczytu. W aktualizacjach modułów i motywu kontroluj diff SQL i koszt migracji.

Bezpieczeństwo a wydajność

Aktualizacje bezpieczeństwa często poprawiają także wydajność. Włącz WAF na poziomie reverse proxy z wykluczeniami dla endpointów wymagających wysokiej przepustowości. Limituj rozmiary uploadów i request body. Stosuj rate limiting dla endpointów podatnych na nadużycia (wyszukiwarka, formularze). Szyfruj połączenia wewnętrzne tylko tam, gdzie jest to wymagane polityką – unikniesz zbędnego narzutu.

Sieć i DNS

Skróć czas rozwiązywania nazw, stosując szybkie serwery DNS i krótkie TTL dla rekordów podlegających zmianom. Włącz HTTP keep-alive, co zmniejsza liczbę handshake. Dla globalnej sprzedaży rozważ georouting i Anycast dla DNS. Upewnij się, że routing do POP-ów CDN jest optymalny z głównych regionów Twoich klientów.

Kroki wdrożeniowe – praktyczny plan

Krok 1: Pomiar stanu wyjściowego

Zmierz TTFB i LCP na głównych stronach, odczytaj metryki APM, wygeneruj raport z logu wolnych zapytań i zbadaj strukturę modułów. Zanotuj wartości bazowe i ustal cele.

Krok 2: PHP i WWW

Zaktualizuj PHP, włącz i dostrój OPcache. Skonfiguruj PHP-FPM i limity procesów. Włącz HTTP/2 i kompresję GZIP. Ustaw właściwe nagłówki cache-control i wersjonowanie zasobów. Przetestuj staging i porównaj czasy odpowiedzi.

Krok 3: Baza i pamięć

Strojenie InnoDB (buffer pool, logi), włączenie slow query log i optymalizacja indeksów. Przeniesienie sesji i cache aplikacji do Redis. Weryfikacja hit rate i opóźnień. Czyszczenie dużych tabel statystycznych.

Krok 4: Aplikacja i moduły

Włączenie trybu produkcyjnego, ustawienia CCC i szablonów, audyt modułów i hooków, optymalizacja motywu. Konfiguracja obrazów i ewentualny CDN. Testy A/B krytycznych zmian.

Krok 5: Skalowanie i operacje

Rozdzielenie ról serwerów, automatyczny deploy i monitoring, harmonogram porządków i testów obciążeniowych. Zdefiniowanie SLO i procesów reagowania na incydenty.

Po realizacji planu wróć do punktu pierwszego: ponowne pomiary, porównanie z wartościami bazowymi, korekty konfiguracji i kolejna iteracja. Utrzymanie wydajności to cykl, nie jednorazowy sprint – ale właściwa metodyka i świadome decyzje pozwolą wycisnąć maksimum z Twojej infrastruktury i oprogramowania.

W całym procesie pamiętaj, że najtańszym przyspieszeniem jest eliminacja zbędnej pracy: mniej zapytań, mniej transferu, mniej renderowania. Dopiero potem dokładamy mocniejsze maszyny lub bardziej złożoną architekturę. Dobry serwer pomaga, ale to precyzyjna konfiguracja i mądre wykorzystanie zasobów dają największe zwroty.