Jak przyspieszyć sklep na PrestaShop

Najpierw zmierz, potem zmieniaj. W sklepie, którego nikt nie profilował, połowa oczywistych poprawek okazuje się nieistotna, a prawdziwa przyczyna siedzi w miejscu, o którym nikt nie pomyślał.

Ten tekst prowadzi przez kolejność, w jakiej sam to robię, i pokazuje miejsca charakterystyczne dla PrestaShopa, których nie ma w ogólnych poradnikach o szybkości stron.

Zacznij od trzech pomiarów

PageSpeed Insights na widoku produktu, nie na stronie głównej. Strona główna jest zwykle najlepiej zoptymalizowaną podstroną sklepu i najmniej reprezentatywną. Klient wchodzi z wyszukiwarki na kartę produktu albo na listing kategorii i to tam decyduje się, czy zostanie.

Czas odpowiedzi serwera osobno. W raporcie szukaj pozycji mówiącej o czasie do pierwszego bajtu. Jeśli sam serwer myśli ponad sekundę, optymalizowanie obrazków niczego nie zmieni, bo problem jest przed nimi.

Zakładka Wydajność w panelu PrestaShopa. Pokazuje, czy działa pamięć podręczna, czy włączone jest łączenie plików CSS i JavaScript oraz ile modułów jest zainstalowanych. To pierwsze miejsce, w którym widać zaniedbania konfiguracyjne.

Dopiero mając te trzy rzeczy wiesz, czy pracujesz nad serwerem, nad bazą, czy nad tym, co widzi przeglądarka.

Jeden przebieg PageSpeed to za mało, bo wynik skacze między pomiarami o kilka punktów. Biorę medianę z kilku przebiegów puszczonych w odstępie około minuty. Pomiary puszczone jeden po drugim zawyżają czasy ładowania.

Jeśli sklep stoi za zaporą w rodzaju Cloudflare, sprawdź też, co narzędzie w ogóle zobaczyło. Zapora potrafi podać mu ekran weryfikacji przeglądarki zamiast sklepu, a pusta strona dostaje wynik bliski 100. Taki przebieg poznasz po wadze strony w raporcie: kilkanaście kilobajtów zamiast kilkuset.

Profiler, czyli pomiar od środka

Narzędzia zewnętrzne mówią, że strona ładuje się wolno. Nie mówią, dlaczego. Odpowiedź na to drugie pytanie PrestaShop potrafi dać sam, bo ma wbudowany profiler.

Włącza się go w config/defines.inc.php, ustawiając _PS_DEBUG_PROFILING_ na true. Zwykle idzie to w parze z _PS_MODE_DEV_, który wyłącza ukrywanie błędów.

Profiler dokleja do strony tabelę z tym, czego nie widać z zewnątrz:

• czas generowania strony rozbity na etapy, więc widać, czy czas idzie na zapytania do bazy, czy na renderowanie szablonu
• liczbę zapytań SQL i ich czasy, z wyróżnieniem tych najwolniejszych i powtarzających się
• czas wykonania każdego modułu w każdym punkcie zaczepienia, co jest najcenniejszą częścią, bo wskazuje winnego z imienia
• zużycie pamięci na kolejnych etapach

Ten trzeci punkt rozstrzyga większość sporów. Zamiast zgadywać, który z dwudziestu modułów spowalnia listing kategorii, dostajesz listę posortowaną po czasie.

Dwa ostrzeżenia. Tryb deweloperski pokazuje komunikaty błędów odwiedzającym i sam w sobie spowalnia sklep, więc na produkcji włączaj go na chwilę pomiaru i wyłączaj od razu potem. Jeśli sklep ma ruch, ogranicz widoczność profilera do własnego adresu IP albo zrób pomiar na kopii sklepu.

Zaraz po pomiarze zajrzyj też do logów wolnych zapytań na serwerze bazy. Profiler pokazuje zapytania z perspektywy strony, logi z perspektywy bazy, i te dwa obrazy razem wskazują, czy problemem jest jedno ciężkie zapytanie, czy setka lekkich powtórzonych w pętli.

Gdzie w PrestaShopie najczęściej ucieka czas

Wyłączona pamięć podręczna

Brzmi banalnie, a zdarza się regularnie: ktoś wyłączył cache na czas wdrażania zmian i nigdy nie włączył z powrotem. Sklep generuje wtedy każdą stronę od zera przy każdym wejściu.

Sprawdź to zanim zaczniesz cokolwiek innego. To jedna zmiana w panelu i bywa, że załatwia większość problemu.

Na tej samej stronie, niżej, jest natomiast ustawienie, którego lepiej nie ruszać w ciemno: wybór mechanizmu pamięci podręcznej. PrestaShop pozwala tam włączyć między innymi APC czy Memcached, ale to są rozszerzenia instalowane na serwerze. Jeśli hosting ich nie ma albo nie są skonfigurowane, włączenie kończy się białą stroną zamiast sklepu, od razu i także dla klientów.

Zasada jest prosta: pamięć podręczna plikowa działa wszędzie i wystarcza większości sklepów. Mechanizmy wymagające rozszerzeń włączaj dopiero wtedy, gdy masz potwierdzone od hostingu, że są dostępne, i po zrobieniu kopii, z której da się wrócić w minutę.

Kombinacje produktów

Charakterystyczna przypadłość tej platformy. Produkt z pięcioma rozmiarami i trzema kolorami to piętnaście kombinacji, każda z własnym stanem magazynowym i ceną. Katalog tysiąca takich produktów to kilkanaście tysięcy rekordów, które sklep przelicza przy generowaniu listingu.

Objaw jest rozpoznawalny: strona główna działa dobrze, a kategoria z dużą liczbą wariantów ładuje się sekundami. Lekarstwem bywa ograniczenie liczby atrybutów pokazywanych na listingu albo indeks w bazie, ale dobór zależy od tego, co pokazał profil.

Moduły, których nikt już nie używa

Każdy moduł dokłada zapytania do bazy i swoje pliki do strony, nawet jeśli nic nie wyświetla. Sklepy po kilku latach mają zwykle kilka modułów zainstalowanych „na próbę" i nigdy nieodinstalowanych.

Takie moduły trzeba odinstalować. Wyłączony moduł nadal bywa ładowany.

Biblioteki, które moduły przynoszą ze sobą

Moduł z karuzelą, galerią albo wyszukiwarką dokłada własne skrypty, niezależnie od tego, co już jest na stronie. Po kilku latach strona główna potrafi ładować trzy różne biblioteki karuzel, z których każda robi to samo.

Drugi typowy przypadek to ciężka biblioteka ładowana na każdej podstronie dla jednej funkcji. W sklepie, którym się opiekuję, wyszukiwarka ciągnęła za sobą pełne jQuery UI: 228 kB z 620 kB skryptów pobieranych przy każdym wejściu. Po zmianie te pliki pobierają się dopiero wtedy, gdy klient zacznie korzystać z wyszukiwarki.

Naprawa to jedna biblioteka dla wszystkich karuzel i galerii oraz ładowanie skryptów dopiero wtedy, gdy są potrzebne. Wymaga to pracy programisty nad modułami i motywem, ale pliki rdzenia zostają nietknięte.

Osobny problem to moduły z zaszyfrowanym kodem. Nie da się ich poprawić ani odchudzić, można je tylko zastąpić. Jeśli taki moduł wychodzi w pomiarze jako ciężki, licz się z napisaniem zamiennika.

Obrazy katalogu

Zdjęcia produktów wgrywane wprost z aparatu albo od producenta potrafią ważyć po kilka megabajtów. PrestaShop generuje z nich miniatury, ale tylko w rozmiarach, które ma zdefiniowane, i tylko w formacie, który ma ustawiony.

Przejście na WebP daje przy dużym katalogu więcej niż jakakolwiek pojedyncza zmiana w kodzie. Ten sam kadr w WebP waży zwykle wyraźnie mniej niż w JPEG przy porównywalnej jakości, a przy katalogu liczonym w tysiącach zdjęć różnica sumuje się w transferze i w czasie ładowania listingów. Nowsze wersje PrestaShopa mają ustawienie formatu w panelu, starsze wymagają modułu.

Warunek jest jeden i łatwo go przeoczyć: po zmianie ustawień trzeba zregenerować miniatury, bo stare pliki zostają na serwerze i sklep dalej je podaje.

Osobnej uwagi wymaga slider na stronie głównej. Pierwszy slajd jest zwykle największym elementem na ekranie, więc od niego zależy LCP, czyli moment, w którym klient widzi główną treść strony. Pomagają trzy rzeczy: osobny obrazek na telefon zamiast przeskalowanego kadru z komputera, pliki w AVIF i WebP w kilku szerokościach oraz wskazanie przeglądarce, żeby pobrała pierwszy slajd z wyprzedzeniem.

Skrypty marketingowe

Piksele reklamowe, czaty, narzędzia analityczne, mapy ciepła. Każde z nich dokłada od kilkudziesięciu do kilkuset kilobajtów i wykonuje się na głównym wątku przeglądarki.

To najczęściej największa pojedyncza pozycja w raporcie wydajności sklepu. Pierwsza decyzja jest biznesowa: które z tych skryptów są jeszcze komuś potrzebne. Druga jest techniczna: kiedy mają się uruchamiać.

Narzędzia analityczne w rodzaju Microsoft Clarity wymagają zgody na cookies, więc mogą startować dopiero po jej udzieleniu. Przy Consent Mode v2 ustawionym domyślnie na brak zgody nie obciążają wtedy pierwszego wczytania strony.

Kolejność, która oszczędza pracę

1. Konfiguracja w panelu: pamięć podręczna, łączenie plików, kompresja.
2. Serwer: wersja PHP, pamięć podręczna kodu bajtowego, parametry bazy.
3. Katalog: obrazy, miniatury, indeksy przy dużej liczbie kombinacji.
4. Moduły: odinstalowanie nieużywanych.
5. Skrypty zewnętrzne: odroczenie albo usunięcie.
6. Na końcu motyw i kod.

Kolejność idzie od zmian tanich i odwracalnych do drogich i ryzykownych. Jeśli problemem był czas odpowiedzi serwera, sklep po punktach od pierwszego do piątego rzadko wymaga szóstego.

Z wynikiem PageSpeed na telefonie bywa inaczej. O LCP decyduje tam zwykle to, co motyw i moduły ładują przy starcie strony, a tego konfiguracja w panelu nie naprawi. W sklepie z drzwiami i blatami wynik strony głównej na telefonie poprawił się dopiero po pracy nad sliderem, bibliotekami modułów i paskiem zgód.

Gdzie pomaga AI, a gdzie nie

Profiler i logi wypluwają dużo danych naraz: kilkaset zapytań SQL, lista modułów z czasami, log wolnych zapytań z tygodnia. Przeczytanie tego ze zrozumieniem zajmuje godziny, a większość to szum.

Tu model językowy realnie skraca pracę. Wrzucam wynik profilera albo fragment logu i proszę o pogrupowanie zapytań po wzorcu, wskazanie tych powtarzających się w pętli i posortowanie modułów po łącznym czasie. To praca mechaniczna, w której komputer jest szybszy i nie przeoczy trzydziestego szóstego wiersza. Podobnie przy szukaniu w kodzie modułu miejsca, które odpowiada za konkretne zapytanie.

Granica jest w dwóch miejscach i oba warto znać, jeśli ktoś ci sprzedaje optymalizację „przez AI".

Wniosek weryfikuję pomiarem. Model potrafi przekonująco wskazać przyczynę, która nią nie jest. Każda hipoteza z analizy wraca do profilera i albo potwierdza się w liczbach, albo wypada.

Danych klientów nie przepuszczam przez zewnętrzne narzędzia. Log zapytań SQL ze sklepu zawiera adresy, numery zamówień i czasem dane kontaktowe. Przed analizą wychodzą z niego wartości, zostają same wzorce zapytań. Zrzuty bazy nie opuszczają serwera.

Zmian w konfiguracji cen, stawek podatku i stanów magazynowych nie oddaję narzędziu w żadnej formie. Pomyłka o jedno miejsce po przecinku kosztuje tam realne pieniądze, więc te liczby sprawdzam ręcznie.

Czego nie robić

Nie instaluj modułu przyspieszającego, zanim nie wiesz, co jest wolne. Moduły do optymalizacji robią zwykle to samo, co ustawienia w panelu, tylko dokładają własną warstwę do utrzymania. Bywa, że po ich instalacji sklep działa wolniej, bo dwa mechanizmy pamięci podręcznej wchodzą sobie w drogę.

Nie zmieniaj kilku rzeczy naraz. Bez pomiaru po każdej zmianie nie wiesz, która pomogła, a która zaszkodziła. Przy sklepie ma to dodatkowe znaczenie, bo część poprawek potrafi popsuć koszyk w sposób niewidoczny do pierwszego zamówienia.

Nie optymalizuj strony głównej kosztem ścieżki zakupowej. Wynik w narzędziu poprawia się najłatwiej tam, gdzie mało się dzieje. Pieniądze robią się na karcie produktu i w koszyku.

Nie dotykaj plików rdzenia. Pierwsza aktualizacja skasuje zmiany. Do modyfikacji służą moduły i nadpisania.

Kiedy problem leży po stronie serwera

PrestaShop jest wrażliwszy na konfigurację serwera niż WordPress. Sklep z dużym katalogiem na hostingu współdzielonym potrafi działać poprawnie do momentu, w którym przestaje. Zwykle dzieje się to przy kampanii reklamowej albo przy imporcie katalogu.

Objawy wskazujące na serwer: panel administracyjny zwalnia tak samo jak sklep, czas do pierwszego bajtu jest wysoki niezależnie od podstrony, a problemy nasilają się o określonych porach dnia.

Wtedy przeprowadzka na mocniejszy serwer załatwia więcej niż tygodnie pracy nad kodem.

Zanim jednak zaczniesz szukać mocniejszego serwera, sprawdź wersję PHP. Sklep chodzący na wersji z gałęzi 7.x traci wydajność wyłącznie przez zaniedbanie. Kolejne wydania PHP przyniosły realny wzrost szybkości wykonania tego samego kodu, więc podniesienie wersji bywa najtańszym przyspieszeniem, jakie da się zrobić. Zwykle wystarczy do tego przełącznik w panelu hostingu.

Jest jedno „ale" i jest poważne. Każda wersja PrestaShopa obsługuje PHP tylko do określonej wersji, a przełączenie na wyższą niż obsługiwana wywali sklep, zwykle na białą stronę. Sprawdź w dokumentacji swojej wersji sklepu, jaki jest górny limit, i przełączaj się w godzinach najmniejszego ruchu, mając pod ręką sposób na szybki powrót. Jeśli twoja wersja PrestaShopa nie obsługuje już wspieranych wersji PHP, to sygnał, że czas na aktualizację samego sklepu. To już osobny projekt.

Częste pytania

Ile da się realnie ugrać? Zależy od punktu wyjścia, dlatego nie obiecuję z góry żadnej liczby. Sklep z wyłączoną pamięcią podręczną i nieprzetworzonymi zdjęciami poprawia się skokowo. Sklep już raz porządnie zoptymalizowany wymaga pracy nad pojedynczymi dziesiątymi sekundy. Przykład z praktyki: w sklepie z drzwiami i blatami wynik PageSpeed strony głównej na telefonie wzrósł z 75 do 90, a LCP spadło z 5,7 do 3,4 s.

Jak włączyć profiler w PrestaShopie? W pliku config/defines.inc.php ustaw stałą _PS_DEBUG_PROFILING_ na true, zwykle razem z _PS_MODE_DEV_. Profiler dokleja do strony tabelę z czasami zapytań i modułów. Na sklepie z ruchem włączaj go tylko na czas pomiaru albo ogranicz widoczność do własnego adresu IP, bo tryb deweloperski pokazuje błędy odwiedzającym i sam spowalnia sklep.

Czy szybszy sklep sprzedaje więcej? Szybkość wpływa na to, ilu odwiedzających w ogóle doczeka do treści, i na pozycję w wyszukiwarce. Oferty, zdjęć produktów ani jasnych kosztów dostawy nie zastąpi. Wolny sklep traci klientów, ale szybki sam z siebie ich nie przyciągnie.

Czy warto przejść na nowszą wersję PrestaShopa dla wydajności? Bywa, że tak, ale to osobny projekt z własnym ryzykiem, bo trzeba sprawdzić zgodność motywu i wszystkich modułów. Nie zaczynaj od tego, jeśli nie zrobiłeś wcześniej punktów od pierwszego do piątego.

Mam sklep na hostingu współdzielonym. To wystarczy? Dla sklepu startowego z katalogiem do stu produktów zwykle tak. Przy tysiącach pozycji z wariantami zaczyna brakować mocy i wtedy przeprowadzka jest tańsza niż walka o każdą dziesiątą sekundy na słabszym serwerze. Ceny hostingu i VPS-a rozpisałem w tekście o tym, ile kosztuje sklep na PrestaShopie.

Czy włączyć Memcached, skoro jest w panelu? Tylko jeśli hosting faktycznie ma to rozszerzenie i jest ono skonfigurowane. Sama obecność opcji w panelu niczego nie gwarantuje. To ustawienie każe sklepowi korzystać z rozszerzenia, ale go na serwerze nie instaluje. Włączenie bez zaplecza kończy się białą stroną. Na hostingu współdzielonym pamięć podręczna plikowa jest zwykle właściwym wyborem.

Czy zmiana wersji PHP jest bezpieczna? Podniesienie wersji w obrębie tych, które obsługuje twoja wersja PrestaShopa, tak, i zwykle daje darmowy przyrost szybkości. Przeskok na wersję wyższą niż obsługiwana wywali sklep. Sprawdź górny limit dla swojej wersji sklepu przed przełączeniem i rób to poza godzinami szczytu.

Jeśli twój sklep zwolnił i nie wiesz, od czego zacząć, prześlij mi adres. Zacznę od pomiaru i powiem, gdzie faktycznie ucieka czas, zanim cokolwiek zmienię. Pracą nad wydajnością zajmuję się w ramach wdrożeń i rozwoju sklepów, także przy sklepach zbudowanych przez kogoś innego.