PrestaShop nie jest z natury wolny. Dobrze skonfigurowany sklep PrestaShop 1.7 lub 8.x z rozsądnym katalogiem produktów i sensownym doborem modułów ładuje się w mniej niż dwie sekundy. Ale większość sklepów nie jest dobrze skonfigurowana, niesie lata nagromadzonego balastu modułów i działa na hostingu wybranym za cenę, a nie za wydajność. Przyjrzyjmy się, co faktycznie powoduje wolne działanie i co realistycznie możesz zrobić z każdą przyczyną.
Jak mierzyć zanim zaczniesz naprawiać
Zanim cokolwiek zmienisz, ustal punkt odniesienia. Nie możesz poprawić tego, czego nie mierzysz.
- TTFB (Time to First Byte): Czas od wysłania żądania przez przeglądarkę do otrzymania pierwszego bajtu odpowiedzi. Mierzy wydajność po stronie serwera. Dla PrestaShop zdrowy TTFB to poniżej 300ms. Jeśli Twój TTFB przekracza 1 sekundę, Twój serwer lub aplikacja ma poważny problem.
- Pełne ładowanie strony: Całkowity czas do momentu, gdy strona jest wizualnie kompletna i interaktywna. Poniżej 3 sekund jest dobrze, poniżej 2 sekund jest doskonale.
- Google PageSpeed Insights: Daje zarówno dane laboratoryjne, jak i dane od rzeczywistych użytkowników. Skup się na Core Web Vitals — LCP (Largest Contentful Paint), FID/INP (Interaction to Next Paint) i CLS (Cumulative Layout Shift).
Testuj stronę główną, stronę kategorii z wieloma produktami i stronę produktu. Problemy z wydajnością często pojawiają się na konkretnych typach stron, nie wszędzie jednakowo.
Baza danych: gdzie kryje się większość problemów
Z naszego doświadczenia baza danych jest najczęstszym źródłem problemów z wydajnością PrestaShop. Oto dlaczego:
Brakujące indeksy
Rdzeń PrestaShop tworzy niezbędne indeksy bazodanowe podczas instalacji. Ale moduły często tworzą tabele bez odpowiednich indeksów, a z czasem tabele te rosną. Zapytanie, które jest natychmiastowe na tabeli z 1000 wierszy, staje się boleśnie wolne na tabeli z 1 000 000 wierszy, jeśli nie ma indeksu na kolumnach używanych w klauzulach WHERE lub JOIN.
Sprawdź log wolnych zapytań. Jeśli widzisz tę samą tabelę pojawiającą się wielokrotnie, sprawdź, czy ma odpowiednie indeksy dla wykonywanych na niej zapytań.
Rozdęte tabele
Kilka tabel PrestaShop rośnie ciągle i rzadko jest czyszczonych:
- ps_connections i ps_connections_source: Śledzą każde połączenie odwiedzającego. W ruchliwym sklepie tabele te mogą mieć miliony wierszy. PrestaShop odpytuje je dla statystyk, ale rzadko potrzebuje więcej niż 90 dni danych.
- ps_log: Logi aplikacji, które rosną w nieskończoność. Bezpieczne do okresowego obcięcia.
- ps_cart: Każdy porzucony koszyk jest przechowywany na zawsze. Stare koszyki sprzed lat nie służą żadnemu celowi, ale spowalniają zapytania związane z koszykami.
- ps_guest: Rekordy gości odwiedzających, które gromadzą się przez lata.
- ps_pagenotfound: Loguje każdy błąd 404. Może urosnąć do ogromnych rozmiarów w sklepach z wieloma uszkodzonymi linkami lub ruchem botów.
Kosztowne zapytania z modułów
Niektóre moduły wykonują ciężkie zapytania bazodanowe przy każdym załadowaniu strony. Moduły analityczne liczące odwiedzających, moduły zarządzania stanami sprawdzające zapasy w czasie rzeczywistym i moduły cross-sell obliczające powiązania produktów — każdy z nich może dodać 50-200ms do każdego żądania. Pomnóż to przez 10 modułów robiących to samo i masz pełną sekundę czasu bazodanowego zanim jakakolwiek treść strony zostanie w ogóle wygenerowana.
Moduły: największa zmienna wydajności
Różnica między szybkim a wolnym sklepem PrestaShop to zazwyczaj moduły. Oto na co zwracać uwagę:
Zbyt wiele hooków
Każdy moduł, który podpina się do displayHeader, displayFooter, displayTop lub actionFrontControllerSetMedia, uruchamia się przy każdym załadowaniu strony. Jeśli masz 30 modułów podpiętych do tych pozycji, to 30 funkcji PHP wykonujących się zanim strona może się wyrenderować. Niektóre z tych funkcji mogą być lekkie, ale inne mogą ładować konfigurację, wykonywać zapytania bazodanowe lub dołączać zewnętrzne pliki.
Zewnętrzne wywołania API
Moduły, które wywołują zewnętrzne API przy ładowaniu strony, to zabójcy wydajności. Kalkulator kosztów wysyłki wywołujący API przewoźnika na stronie produktu. Konwerter walut pobierający kursy na żywo. Widget mediów społecznościowych pobierający dane z Facebooka lub Instagrama. Każde zewnętrzne wywołanie dodaje opóźnienie sieciowe — często 200-500ms — a jeśli zewnętrzna usługa jest wolna lub niedostępna, cała Twoja strona czeka.
Rozwiązaniem jest cache. Wszelkie dane pobierane ze źródła zewnętrznego powinny być cache'owane lokalnie i odświeżane według harmonogramu (cron), nie przy każdym załadowaniu strony.
Zduplikowane moduły
Wiele sklepów ma wiele modułów robiących podobne rzeczy. Dwa moduły SEO, trzy trackery analityczne, dwa banery zgody na cookies — każdy dodaje narzut. Zrób audyt zainstalowanych modułów i usuń duplikaty. Jeden dobrze wybrany moduł SEO przewyższy trzy konkurujące, walczące o te same meta tagi.
Hosting: fundament
Hosting współdzielony zazwyczaj nie wystarczy
PrestaShop na tanim hostingu współdzielonym to jak prowadzenie restauracji w budce telefonicznej. Technicznie działa, dopóki nie przyjdzie więcej niż dwóch klientów. Hosting współdzielony oznacza dzielenie CPU, RAM i I/O dysku z dziesiątkami innych stron. Gdy Twój sąsiad na serwerze uruchamia ciężki backup, Twój sklep zwalnia.
Co minimum poważny sklep PrestaShop potrzebuje:
- VPS lub dedykowany serwer z co najmniej 2GB RAM (rekomendowane 4GB+)
- Dyski SSD (nie obrotowe)
- PHP 8.1 lub nowszy z włączonym OPcache
- MySQL 8.0 lub MariaDB 10.6+ z prawidłowo dostrojonymi buforami
Konfiguracja PHP
Najbardziej wpływowe ustawienie PHP dla PrestaShop to OPcache. OPcache przechowuje skompilowany bytecode PHP w pamięci, eliminując potrzebę parsowania plików PHP przy każdym żądaniu. Prawidłowo skonfigurowany OPcache może poprawić TTFB o 30-50%.
Kluczowe ustawienia OPcache:
opcache.enable=1opcache.memory_consumption=256(MB — PrestaShop z modułami może łatwo zużyć 128MB+)opcache.max_accelerated_files=20000opcache.validate_timestamps=0w produkcji (wymaga ręcznego czyszczenia cache po wdrożeniach)
Strojenie MySQL
Domyślna konfiguracja MySQL jest zaprojektowana dla małego serwera z minimalną pamięcią. Dla sklepu PrestaShop najważniejsze ustawienia do skorygowania:
innodb_buffer_pool_size— powinien wynosić 50-70% dostępnej RAM na dedykowanym serwerze bazy, lub co najmniej 512MB na współdzielonym serwerzequery_cache_type=0— cache zapytań MySQL jest przestarzały i faktycznie szkodzi wydajności przy obciążeniach z dużą liczbą zapisów, jak e-commerceinnodb_flush_log_at_trx_commit=2— akceptowalny kompromis między wydajnością a trwałością dla większości sklepów
Wbudowane mechanizmy cache PrestaShop
PrestaShop posiada kilka wbudowanych mechanizmów cache, których wielu właścicieli sklepów nigdy prawidłowo nie konfiguruje:
- Cache Smarty: Cache kompilacji szablonów. Powinien być zawsze włączony w produkcji (
Wymuszaj kompilację: Niew ustawieniach wydajności). - CCC (Combine, Compress, Cache): Łączy i minifikuje pliki CSS i JavaScript, zmniejszając liczbę żądań HTTP. Włącz w Wydajność > CCC.
- Cache stron: Cache pełnej strony może dramatycznie poprawić wydajność dla anonimowych odwiedzających. Nie wbudowany w rdzeń PrestaShop, ale dostępny przez moduły.
- Cache obiektów: PrestaShop może używać Redis lub Memcached do cache'owania wyników zapytań bazodanowych. To jedna ze zmian o najwyższym wpływie, jaką możesz wprowadzić, jeśli baza danych jest wąskim gardłem.
Realistyczna lista kontrolna wydajności
Jeśli Twój sklep jest wolny, przerabiaj te punkty po kolei:
- Zmierz aktualny TTFB i czasy ładowania stron. Zanotuj je.
- Włącz OPcache, jeśli nie jest jeszcze włączony.
- Włącz cache Smarty (wyłącz wymuszanie kompilacji).
- Włącz CCC dla CSS i JavaScript.
- Zrób audyt modułów — wyłącz lub usuń wszystko, czego aktywnie nie używasz.
- Sprawdź bazę danych pod kątem rozdętych tabel i wyczyść je.
- Dodaj Redis lub Memcached do cache obiektów, jeśli jest dostępny na Twoim hostingu.
- Przejrzyj log wolnych zapytań i dodaj brakujące indeksy.
- Zmierz ponownie. Porównaj z punktem odniesienia.
- Jeśli nadal wolno, rozważ upgrade hostingu.
Większość sklepów zobaczy 50-70% poprawę TTFB tylko dzięki krokom 2-6. Nie potrzebujesz egzotycznych rozwiązań — potrzebujesz prawidłowo wykonanych podstaw.
Wydajność to nie jednorazowa poprawka. W miarę dodawania produktów, instalowania modułów i wzrostu bazy klientów, okresowo mierz ponownie i ponownie optymalizuj. Sklep, który był szybki z 500 produktami, może wymagać uwagi, gdy osiągnie 5000. Wbudowanie monitorowania wydajności w Twoją rutynę — nawet szybkie sprawdzenie raz na kwartał — zapobiega stopniowemu spowolnieniu, które zaskakuje wielu właścicieli sklepów.
Powiązane Artykuły
- Czyszczenie bazy danych: dlaczego Twój sklep PrestaShop z czasem zwalnia
- Twój sklep działa wolno? Jak to sprawdzić i co z tym zrobić
- Redis Cache dla PrestaShop: konfiguracja i wzrost wydajnosci
Komentarze
Brak komentarzy. Bądź pierwszy!
Bądź pierwszy: zadaj pytanie albo podziel się przydatną opinią.
Dodaj komentarz
Dodaj pytanie, szczegół montażu albo opinię, która może pomóc innemu czytelnikowi.