Optymalizacja PrestaShop: jak przyspieszyć sklep i poprawić Core Web Vitals

Optymalizacja PrestaShop polega na ustaleniu, czy sklep spowalnia serwer, czy front-end, a następnie usunięciu przyczyny, najczęściej modułów wstrzykujących własny CSS i JavaScript na każdym szablonie. Core Web Vitals uznaje się za zdane, gdy 75% wizyt mieści się w LCP do 2,5 s, INP do 200 ms i CLS do 0,1. Ten poradnik prowadzi przez pomiar, diagnozę i kolejność wdrożenia.

Poradnik dotyczy PrestaShop 1.7.8, 8.x, 9.0 i 9.1. Różnice między wersjami zaznaczamy przy każdej sekcji.

To najważniejsza tabela w całym artykule, bo od niej zależy, czy jakakolwiek zmiana PHP pomoże, czy zepsuje sklep. PrestaShop 1.7.8 nie obsługuje PHP 8.x w ogóle, a PrestaShop 8.x ma sufit na PHP 8.1 i nie ruszy na 8.2 ani nowszym. Popularna rada „przejdź na PHP 8″ podana bez tego zastrzeżenia potrafi położyć sklep, więc najpierw sprawdź swoją wersję w tabeli, a dopiero potem dobieraj PHP.

Dlaczego wolny sklep PrestaShop kosztuje Cię sprzedaż

Każda sekunda ładowania powyżej progu Core Web Vitals to mierzalny spadek konwersji, a w PrestaShop najdroższe są opóźnienia na karcie produktu i w koszyku, czyli tam, gdzie klient jest najbliżej decyzji o zakupie.

Skala jest policzalna. W badaniu Deloitte i Google „Milliseconds Make Millions” skrócenie czasu ładowania o zaledwie 0,1 sekundy podniosło konwersję w handlu detalicznym o 8,4%, a średnią wartość koszyka o 9,2% w próbie 37 marek (Deloitte, 2020). To nie efekt kosmetyczny, tylko różnica w przychodzie z tego samego ruchu. Na jednym z naszych wdrożeń, sklepie Vetplanet, uporządkowanie backendu i modułów skróciło czas generowania strony o około 30%.

Wolny sklep przepala też budżet reklamowy, bo płacisz za wejścia, które kończą się porzuceniem, zanim strona się załaduje. Jeśli chcesz oddać diagnozę i wdrożenie w jedne ręce, sprawdź, jak wygląda kompleksowa optymalizacja PrestaShop prowadzona od audytu po poprawki. Szybszy sklep to zarazem lepsza optymalizacja SEO PrestaShop, bo Core Web Vitals są jednym z sygnałów, których Google używa w rankingu.

Core Web Vitals w PrestaShop: co Google naprawdę mierzy

Core Web Vitals to trzy metryki, LCP, INP i CLS, którymi Google opisuje realne doświadczenie użytkownika: szybkość ładowania, responsywność i stabilność układu. Ocena nie opiera się na pojedynczym teście, tylko na danych z realnego ruchu w przeglądarce Chrome, zbieranych w raporcie CrUX. Google bierze pod uwagę 75. percentyl, czyli uznaje stronę za zdaną dopiero wtedy, gdy dobry wynik ma co najmniej 75% wizyt, i liczy to osobno dla urządzeń mobilnych i komputerów. Dane to średnia krocząca z ostatnich 28 dni, a nie opóźnienie publikacji. Sam raport CrUX ma około dwóch dni obsuwy, ale każdy pomiar uśrednia 28 dni, dlatego poprawka wdrożona dziś pojawia się stopniowo, a pełny efekt widać po około czterech tygodniach.

LCP, czyli czas ładowania największego elementu

LCP (Largest Contentful Paint) mierzy, po jakim czasie pojawia się największy widoczny element strony. Próg dobrego wyniku to 2,5 sekundy, a strefa słaba zaczyna się powyżej 4 sekund. W PrestaShop tym elementem jest zwykle slider na stronie głównej, czyli moduł ps_imageslider, albo główne zdjęcie na karcie produktu. Jeśli slider ładuje ciężką grafikę bez kompresji albo serwer długo odpowiada, LCP rośnie, zanim klient zobaczy cokolwiek konkretnego. To metryka, którą poprawia się z dwóch stron naraz: od lekkiego, priorytetowo ładowanego obrazu i od szybkiego czasu odpowiedzi serwera. Samo podmienienie zdjęcia na WebP nie pomoże, jeśli backend generuje stronę wolno, i odwrotnie.

INP, czyli reakcja na interakcje

INP (Interaction to Next Paint) mierzy, jak szybko strona odpowiada na kliknięcia i dotknięcia w całym cyklu wizyty, nie tylko przy pierwszej interakcji. Próg dobrego wyniku to 200 milisekund, a słaby zaczyna się powyżej 500 ms. INP zastąpił dawny wskaźnik FID w marcu 2024 roku, więc każdy poradnik, który wciąż opisuje First Input Delay, jest już nieaktualny. W PrestaShop najczęstsze źródła słabego INP to jQuery, AJAX-owe przeładowanie listingu po kliknięciu filtra oraz dodawanie do koszyka, bo te operacje uruchamiają skrypty blokujące główny wątek przeglądarki. Im więcej modułów dokłada własny JavaScript, tym dłużej strona zwleka z reakcją, a to najtrudniej przechodzi na urządzeniach mobilnych.

CLS, czyli stabilność układu

CLS (Cumulative Layout Shift) opisuje, jak bardzo elementy przeskakują podczas ładowania. Próg dobrego wyniku to 0,1, a słaby zaczyna się powyżej 0,25. W PrestaShop typowe źródła przeskoków to slider, baner zgody na cookies, miniatury produktów bez zadeklarowanych atrybutów width i height oraz fonty webowe, które podmieniają się już po wyrenderowaniu tekstu. Scenariusz, który kosztuje najwięcej, wygląda tak: klient celuje w przycisk „dodaj do koszyka”, a w tym momencie doładowuje się baner i spycha treść w dół. CLS poprawia się przez rezerwowanie miejsca z góry, czyli podawanie wymiarów obrazów i planowanie przestrzeni na elementy pojawiające się z opóźnieniem.

Kluczowy warunek, o którym łatwo zapomnieć: stronę uznaje się za zdaną tylko wtedy, gdy wszystkie trzy wskaźniki mieszczą się w progu „dobry” dla co najmniej 75% wizyt. Poprawa dwóch metryk nie da zielonego statusu, jeśli trzecia zostaje w strefie słabej, dlatego w PrestaShop pracuje się nad LCP, INP i CLS równolegle, a nie po kolei do skutku.

Jak zmierzyć wydajność sklepu, zanim cokolwiek zmienisz

Na wydajność PrestaShop składa się kilka warstw naraz, dlatego zanim zmienisz jedną linijkę, zmierz cztery szablony osobno, bo strona główna, listing kategorii, karta produktu i koszyk zachowują się zupełnie inaczej. Zanim zmienisz jedną linijkę, zmierz cztery szablony osobno, bo strona główna, listing kategorii, karta produktu i koszyk zachowują się w PrestaShop zupełnie inaczej. Jeden wynik „dla sklepu” nie istnieje. Listing kategorii renderuje kilkadziesiąt miniatur i odpytuje wyszukiwarkę fasetową, karta produktu doładowuje kombinacje i powiązane produkty, a koszyk przelicza reguły cenowe i przeliczniki przy każdej zmianie. Dlatego strona główna potrafi mieć zielone Core Web Vitals, a karta produktu czerwone, i to właśnie karta produktu decyduje o sprzedaży. Pomiar zaczynasz od danych polowych, żeby wiedzieć, czy w ogóle jest problem, a laboratorium traktujesz jako narzędzie do ustalania przyczyny, nie werdykt.

Dane polowe a laboratoryjne: dlaczego Lighthouse kłamie

Lighthouse to symulacja na Twoim sprzęcie i łączu, a CrUX to realni użytkownicy z ostatnich 28 dni. To dlatego można mieć 95/100 w Lighthouse i czerwone Core Web Vitals w Search Console naraz. Twój laptop z szybkim łączem nie odwzorowuje klienta na średniej klasy telefonie w słabym zasięgu, a Google ocenia właśnie tego drugiego. Dane laboratoryjne służą do jednego: pokazują, co i dlaczego jest wolne, żebyś mógł to naprawić. O tym, czy sklep zdał, decydują wyłącznie dane polowe. Jeśli te dwa światy się rozjeżdżają, to nie błąd narzędzia, tylko różnica między testem a rzeczywistością.

PageSpeed Insights i raport Core Web Vitals w Search Console

PageSpeed Insights łączy oba światy: na górze pokazuje dane polowe z CrUX, niżej analizę laboratoryjną Lighthouse z listą konkretnych problemów. Raport Core Web Vitals w Search Console grupuje z kolei adresy URL całego sklepu na Dobre, Wymaga poprawy i Słabe, osobno dla urządzeń mobilnych i komputerów, więc od razu widać, który typ szablonu ciągnie wynik w dół. W sklepie o małym ruchu CrUX pokaże „brak wystarczających danych”, i to normalne. Wtedy opierasz diagnozę na Lighthouse i pomiarze laboratoryjnym poszczególnych szablonów, a wynik polowy zaczniesz widzieć dopiero, gdy ruch przekroczy próg zbierania danych przez Google.

Lighthouse, Chrome DevTools i GTmetrix

Najwięcej wyciągniesz z Chrome DevTools. Zakładka Network pokazuje waterfall, czyli kolejność i czas ładowania każdego zasobu, dzięki czemu widać, który plik blokuje renderowanie i który obraz opóźnia LCP. Panel Performance nagrywa, co dzieje się na głównym wątku, i pokazuje długie zadania odpowiedzialne za słaby INP. Lighthouse, wbudowany w te same DevToolsy, daje szybką listę zaleceń i punktację laboratoryjną. GTmetrix to w praktyce Lighthouse w innej skórce z wygodnym porównaniem przed i po, więc traktuj go jako dodatek, nie osobne źródło prawdy.

Profiler PrestaShop: zapytania SQL i czas hooków

Profiler to narzędzie, które odpowiada na pytanie „który moduł mnie zabija”. Włącza się go, ustawiając _PS_DEBUG_PROFILING_ na true w pliku config/defines.inc.php, często razem z PS_MODE_DEV. Profiler pokazuje liczbę zapytań SQL, czas wykonania każdego hooka i zużycie pamięci osobno dla każdego szablonu, więc od razu widać, że jeden moduł generuje kilkaset zapytań albo że hook renderuje się dłużej niż cała reszta strony. Orientacyjnie dobrze zoptymalizowana karta produktu mieści się w kilkuset zapytaniach SQL, a kilkukrotnie wyższa liczba to sygnał, że moduły odpytują bazę w pętli. Jedno ostrzeżenie: tryb debug włączaj wyłącznie na środowisku testowym albo z ograniczeniem dostępu po IP, nigdy na żywym sklepie, bo ujawnia strukturę bazy i spowalnia front.

Gdzie leży problem: serwer czy front-end

Jeśli TTFB przekracza 600 ms, problem jest po stronie serwera i optymalizacja obrazów nic nie da. Jeśli TTFB jest niski, a LCP mimo to wysoki, winny jest front-end. TTFB, czyli czas do pierwszego bajtu, to moment, w którym serwer zaczyna odpowiadać, zanim przeglądarka narysuje cokolwiek. Nie jest to Core Web Vital, ale to pierwsza rozgałęziająca się decyzja w całej optymalizacji, bo kieruje Cię do właściwej połowy sklepu.

Ta tabela to całe drzewo decyzyjne w pigułce. Zamiast optymalizować wszystko naraz, zaczynasz od jednego pomiaru TTFB, który mówi Ci, czy tracisz czas na serwerze, czy w przeglądarce, i dopiero potem schodzisz do konkretnej sekcji niżej.

Backend: hosting, PHP, baza danych i cache

Backend odpowiada za TTFB, a w PrestaShop optymalizacja tego obszaru ma jedną sensowną kolejność: najpierw wersja PHP, potem OPcache, potem cache aplikacji, a dopiero na końcu mocniejszy serwer.Ta kolejność jest odwrotna niż odruch większości właścicieli sklepów, którzy najpierw dokupują moc. Tanie zmiany konfiguracyjne zwykle dają większy skok niż droższy hosting.

Hosting dopasowany do skali sklepu

Hosting musi odpowiadać wielkości katalogu i ruchowi, a nie cennikowi. Współdzielony plan przestaje wystarczać zwykle wtedy, gdy katalog przekracza kilka tysięcy SKU, dochodzą integracje i regularny ruch z kampanii, bo wtedy sklep konkuruje o zasoby z innymi stronami na tej samej maszynie. Przy wyborze serwera pod PrestaShop patrz na konkretne parametry: liczbę i wydajność rdzeni CPU, ilość RAM z zapasem na cache, szybkie dyski NVMe z wysokim IOPS oraz limity, które PrestaShop realnie napina, jak max_execution_time przy imporcie czy generowaniu miniatur. Minimalne memory_limit to 256 MB dla PrestaShop 8 i 512 MB dla PrestaShop 9, a baza to co najmniej MySQL 5.7 lub MariaDB 10.2. Dobierz parametry pod realne obciążenie w godzinach szczytu, nie pod wartości z ulotki.

PHP w wersji zgodnej z Twoim PrestaShop, plus OPcache

Nowsza wersja PHP to szybszy sklep bez zmiany ani jednej linijki kodu, ale najpierw sprawdź, którą wersję w ogóle uniesie Twój sklep. Wróć do tabeli z początku artykułu: sklep na 1.7.8 nie przejdzie na PHP 8, więc tam decyzją jest migracja PrestaShopa, a nie zmiana PHP. Sklep na 8.x ma sufit na PHP 8.1. Dopiero PrestaShop 9 sięga PHP 8.4. Po dobraniu wersji włącz i skonfiguruj OPcache, który trzyma skompilowany kod PHP w pamięci i eliminuje ponowną kompilację przy każdym żądaniu. Wartości zalecane w oficjalnej dokumentacji PrestaShop możesz wkleić jako gotowy blok:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=16229
opcache.revalidate_freq=10
opcache.max_wasted_percentage=10
opcache.enable_cli=0
realpath_cache_size=4096K
realpath_cache_ttl=600

Dwie ostatnie linie, realpath_cache_size i realpath_cache_ttl, pochodzą z tego samego źródła i są prawie nieobecne w polskich poradnikach, a przyspieszają rozwiązywanie ścieżek plików, których PrestaShop ma tysiące. To zmiana tania i szybka, a efekt widać bezpośrednio w TTFB.

Optymalizacja i czyszczenie bazy danych

PrestaShop domyślnie gromadzi dane, które z czasem obciążają bazę i spowalniają każde zapytanie. Najczęściej puchną tabele ps_connections, ps_guest, ps_statssearch, ps_log oraz ps_cart z porzuconymi koszykami, które potrafią urosnąć do setek tysięcy rekordów, mimo że nikt z nich nie korzysta. Statystyki połączeń i gości można czyścić bezpiecznie, logi po przejrzeniu również, ale porzucone koszyki i zamówienia wymagają ostrożności i backupu, bo wiążą się z danymi zamówień. Do tego zadbaj o właściwe indeksy na kolumnach, po których PrestaShop najczęściej filtruje, i o silnik InnoDB zamiast starego MyISAM. Wyłączenie zbędnych modułów statystyk odcina problem u źródła, bo baza przestaje zapisywać dane, których i tak nie oglądasz.

Cache: Smarty, CCC i Redis lub Memcached

Cache działa na trzech poziomach i warto je rozdzielić. Smarty kompiluje szablony i w produkcji powinien mieć włączone cache oraz ustawienie „nigdy nie rekompiluj szablonów”, przy wyłączonym trybie debug. CCC (Combine, Compress and Cache) to natywna funkcja PrestaShopa, która skleja i kompresuje pliki CSS oraz JavaScript. Redis lub Memcached cache’ują dane aplikacji przy większych sklepach. Zgodnie z oficjalną dokumentacją typ cache ustaw na „System plików”, nie MySQL, przy jednym froncie użyj APC, a przy kilku wspólnego serwera memcached, nie localhost, i nie włączaj sekcji „Cache”, jeśli MySQL poniżej 8 lub MariaDB stoi na tej samej maszynie, bo query cache bazy będzie wtedy wydajniejszy. Dwa ostrzeżenia z praktyki: CCC regularnie psuje layout i skrypty niektórych modułów, więc włączaj je i testuj sekcja po sekcji, a źle skonfigurowany cache Smarty potrafi rozsypać setki plików szablonów i wygenerować więcej operacji I/O, niż oszczędza. Pełną konfigurację cache krok po kroku opisaliśmy w osobnym poradniku o cache w PrestaShop.

Moduły i hooki: najczęstsza przyczyna wolnego PrestaShop

W sklepie z kilkudziesięcioma modułami każdy z nich dokłada własny CSS i JavaScript do każdego szablonu, i to, a nie hosting, jest w PrestaShop najczęstszą przyczyną wolnego ładowania. Konkurencja kwituje to jednym zdaniem „usuń nieużywane moduły”. Problem leży głębiej i warto zrozumieć mechanizm.

Moduł podpina się do sklepu przez hooki, czyli punkty, w których PrestaShop pozwala mu coś wyrenderować. Hook displayHeader wykonuje się na każdej stronie, więc moduł podpięty tutaj ładuje swoje zasoby globalnie, nawet tam, gdzie nie są potrzebne. W efekcie moduł do koszyka ładuje swój JavaScript na stronie kontaktowej, a moduł galerii na koszyku. Typowy sklep z kilkudziesięcioma modułami potrafi w ten sposób ładować kilkadziesiąt osobnych plików JS i CSS na jednym szablonie, a każdy z nich to osobne żądanie i kolejne milisekundy do INP.

Jak to zmierzyć, już wiesz: profiler pokaże czas każdego hooka, a waterfall w DevTools pokaże wszystkie pliki ładowane przez moduły. Jak naprawić: zacznij od różnicy między wyłączeniem a odinstalowaniem. Wyłączony moduł często nadal ładuje część zasobów, dopiero odinstalowanie usuwa go z hooków. Kolejne kroki to odpinanie modułów od hooków, których nie potrzebują, warunkowe ładowanie zasobów tylko na właściwych szablonach oraz audyt modułu przed instalacją, a nie po.

Tu zaczyna się różnica między teorią a praktyką. Piszemy własne moduły PrestaShop, więc wiemy, jak wygląda moduł napisany wydajnie: ładuje zasoby tylko tam, gdzie działa, nie odpytuje bazy w pętli i nie podpina się globalnie „na wszelki wypadek”. Zły moduł poznasz jeszcze przed zakupem po kilku sygnałach: podpina się do displayHeader bez potrzeby, ciągnie własne biblioteki jQuery mimo że PrestaShop już je ma, i nie daje opcji ograniczenia, na których stronach się ładuje. To wiedza, której nie napisze wiarygodnie nikt, kto sklepów PrestaShop nie buduje.

Front-end: obrazy, CSS, JavaScript i motyw

Front-end odpowiada za LCP i CLS, a w PrestaShop największy pojedynczy zysk daje zdjęcie główne wyjęte spod lazy loadingu i oznaczone jako priorytetowe. To tu, w przeglądarce, klient odczuwa szybkość, więc nawet mocny serwer nie pomoże, jeśli motyw ładuje megabajty grafiki i dziesiątki skryptów, zanim strona stanie się użyteczna.

Obrazy WebP lub AVIF, lazy loading i wymiary

Obrazy to zwykle najcięższy element sklepu, więc od nich zaczyna się poprawa LCP. Serwuj grafiki w formacie WebP lub AVIF, które ważą znacznie mniej niż JPEG przy tej samej jakości, i włącz lazy loading dla zdjęć poniżej pierwszego ekranu. Uwaga na najczęstszy błąd: element LCP nie może być lazy-loadowany, a część motywów domyślnie ładuje leniwie także główne zdjęcie produktu, przez co przeglądarka zwleka z jego pobraniem. Zdjęcie główne oznacz atrybutem fetchpriority=”high”, żeby trafiło na początek kolejki. Do tego każda miniatura i baner muszą mieć zadeklarowane atrybuty width i height, bo to one chronią przed przeskokami układu, czyli słabym CLS.

CSS i JavaScript: minifikacja, defer i krytyczny CSS

Nadmiarowy i blokujący kod to główna przyczyna słabego INP i opóźnionego LCP. Minifikuj pliki i steruj ładowaniem skryptów: defer wykonuje skrypt po zbudowaniu strony, zachowując kolejność, a async uruchamia go, gdy tylko się pobierze, bez gwarancji kolejności, więc defer pasuje do skryptów zależnych od siebie, a async do niezależnych, jak niektóre tagi analityczne. Krytyczny CSS to minimalny zestaw stylów potrzebny do wyrenderowania pierwszego ekranu, wczytywany od razu, podczas gdy reszta ładuje się później. W PrestaShop jest to trudniejsze niż w WordPressie, bo strona główna, listing i karta produktu mają inny critical path, więc jeden krytyczny CSS dla całego sklepu nie wystarczy i trzeba go wyznaczać per typ szablonu.

Skrypty zewnętrzne, GTM i fonty

Wtyczki zewnętrzne bywają cichym obciążeniem, bo doklejają własny kod do każdej strony. Widżety czatu, piksele, mapy i tagi w Google Tag Manager potrafią zauważalnie pogorszyć INP, bo wykonują się na głównym wątku dokładnie wtedy, gdy klient próbuje kliknąć. Przejrzyj, co naprawdę jest potrzebne, i ładuj resztę z opóźnieniem. Fonty webowe dodawaj z ustawieniem font-display: swap, żeby tekst był widoczny od razu, i wczytuj z wyprzedzeniem font używany na pierwszym ekranie. Samohostuj fonty zamiast pobierać je z Google Fonts, bo to eliminuje dodatkowe połączenie. Pamiętaj o związku fontów z CLS: podmiana fontu po wyrenderowaniu tekstu, czyli przejście z FOIT w FOUT, przesuwa układ, jeśli zapasowy i docelowy font mają różne szerokości.

Motyw sklepu: Classic a Hummingbird w PrestaShop 9

Motyw potrafi przesądzić o wydajności, zanim zaczniesz cokolwiek optymalizować, ale trzeba tu obalić mit, który krąży po branżowych blogach. Hummingbird jest motywem domyślnym dopiero od PrestaShop 9.1, a nie od 9.0. W wersji 9.0 Hummingbird był dostępny obok Classica, ale domyślny pozostawał Classic, a nowy motyw zbierał zgłoszenia o niestabilności. Zdanie „Hummingbird to domyślny motyw PrestaShop 9″ jest więc nieprawdziwe. Hummingbird jest zbudowany na Bootstrap 5 i TypeScript, jest znacznie lżejszy od Classica i natywnie wspiera WebP oraz AVIF, co bezpośrednio pomaga LCP. Ma jednak koszt: nie jest wstecznie zgodny z motywami potomnymi opartymi na Classicu, więc migracja to realny projekt, nie przełącznik. Bywają sklepy, w których zmiana motywu na lekki jest tańsza niż optymalizowanie ciężkiego szablonu komercyjnego linia po linii, ale to decyzja do policzenia, nie odruch. Więcej o różnicach między wersjami piszemy w przeglądzie wersji PrestaShop.

Zabójcy wydajności, o których mało kto pisze

Cztery przyczyny spoza standardowych checklist potrafią zniweczyć całą optymalizację: fasety generujące tysiące adresów URL, katalog z kombinacjami produktów, multistore z importami i sklep z wstrzykniętym kodem. To one najczęściej odpowiadają za sytuację, w której sklep „nagle” zwolnił, choć nikt nie zmieniał grafik ani szablonu.

Filtry i wyszukiwarka fasetowa

Wyszukiwarka fasetowa obciąża sklep na dwa sposoby naraz, a drugi bywa niedoceniany. Po stronie wydajności moduł ps_facetedsearch generuje ciężkie zapytania i utrzymuje własne tabele pośrednie, które przy dużym katalogu potrafią spuchnąć. Po stronie SEO każda kombinacja filtrów tworzy osobny sparametryzowany adres URL, więc kilka filtrów mnoży się w tysiące adresów, które zapychają indeksowanie i rozmywają budżet crawlowania. Do tego dochodzą boty, które masowo uderzają właśnie w parametry filtrów, dokładając serwerowi pracy. To właśnie na filtrach w PrestaShop optymalizacja SEO i wydajności spotykają się najmocniej, więc rozwiązanie jest dwutorowe: indeksy i konfiguracja modułu po stronie wydajności oraz świadome sterowanie indeksacją i crawlowaniem filtrów po stronie SEO.

Duży katalog, kombinacje produktów i koszyk B2B

Sklep bywa większy, niż wygląda na pierwszy rzut oka. Kombinacje produktów rosną wykładniczo, więc katalog z pozoru średni potrafi generować setki tysięcy wariantów obciążających karty produktu i panel. Do tego koszyk B2B rządzi się własnymi prawami: indywidualne ceny, role klientów i reguły cenowe przeliczają się przy każdej zmianie pozycji, a przy koszykach z kilkuset produktami to realne obciążenie, bo PrestaShop nie był projektowany pod takie ilości. To obszar, w którym mamy konkretną specjalizację, od indywidualnych cenników i ról po integracje z ERP, takimi jak np. Subiekt. Optymalizacja takiego sklepu polega często nie na przyspieszaniu wszystkiego, tylko na odciążeniu tych kilku operacji, które przeliczają się najczęściej.

Multistore, boty i importy z hurtowni

Multistore to osobna liga, bo współdzieli zasoby i cache między sklepami, więc problem jednego potrafi ciągnąć w dół pozostałe. Do tego dochodzą dwa częste, niewidoczne obciążenia. Importy z hurtowni odpalane w godzinach największego ruchu sprawiają, że sklep muli codziennie o tej samej porze, mimo że nikt nic nie zmienił. Boty scrapujące katalog i uderzające w parametry filtrów potrafią zjeść znaczną część mocy serwera. Rozwiązania są proste, gdy zna się przyczynę: przeniesienie importów i ciężkich zadań CRON poza godziny szczytu oraz sterowanie ruchem botów, żeby nie indeksowały w kółko tych samych sparametryzowanych adresów.

Zainfekowany lub nieaktualny sklep

Wolny sklep bywa objawem, a nie chorobą, i tego wątku nie łączy z wydajnością prawie nikt. Zawirusowany PrestaShop niemal zawsze działa wolno, bo wstrzyknięty obcy kod, przekierowania czy ukryte koparki kryptowalut dokładają serwerowi pracy w tle. Charakterystyczny objaw to nagły spadek wydajności bez żadnych zmian w sklepie, którego nie tłumaczy ani nowy moduł, ani wzrost ruchu. Zanim zaczniesz cokolwiek optymalizować, upewnij się, że sklep jest czysty i zaktualizowany, bo nieaktualna wersja silnika to nie tylko luki bezpieczeństwa, ale i gorsza wydajność względem nowszych wydań. W przeciwnym razie poprawiasz coś, co i tak będzie sabotowane w tle.

Plan wdrożenia: co zrobić i w jakiej kolejności

Pytanie, jak przyspieszyć PrestaShop najmniejszym kosztem, ma prostą odpowiedź: zacznij od zmian o najlepszym stosunku efektu do nakładu, czyli wersji PHP i OPcache, potem audytu modułów, a dopiero na końcu przepisywania motywu. Poniższa tabela łączy plan wdrożenia z checklistą, posortowaną tak, żeby dało się przejść od góry i przestać, gdy skończy się budżet.

Tabela jest ułożona według zwrotu z pracy, więc pierwsze cztery pozycje to szybkie zyski, które da się wdrożyć w jeden dzień i które zwykle dają największy skok. Nie oceniaj efektu tego samego dnia: dane polowe w CrUX aktualizują się w oknie 28 dni, więc realny obraz zobaczysz w Search Console po kilku tygodniach, a wcześniej weryfikuj pojedyncze zmiany w laboratorium.

Kiedy wystarczy samodzielna optymalizacja, a kiedy audyt

Optymalizacja sklepu PrestaShop w większości przypadków mieści się w tym, co zrobisz samodzielnie: PHP, OPcache, obrazy i porządek w modułach to zmiany bezpieczne i dobrze udokumentowane. Audytu wymaga sklep, w którym mimo tych zmian TTFB nie schodzi poniżej sekundy, problem wraca po każdej aktualizacji albo dotyczy specyficznych obszarów, jak koszyk B2B, multistore czy ciężka wyszukiwarka fasetowa, gdzie przyczyn jest zwykle kilka naraz i trzeba je rozdzielić pomiarem, a nie zgadywaniem. Audyt nie jest natomiast potrzebny, jeśli sklep po szybkich zyskach z checklisty przechodzi Core Web Vitals i ładuje się w akceptowalnym czasie. Wtedy wystarczy okresowa kontrola i porządek w modułach.

W takich projektach pracujemy na co dzień jako certyfikowany PrestaShop Expert, od optymalizacji wydajności po migracje do multistore i integracje z ERP. Jeśli chcesz zacząć od rzetelnej diagnozy, dobrym punktem wyjścia jest bezpłatna konsultacja i audyt, na którym mierzymy wydajność i pokazujemy, co realnie ciągnie sklep w dół, zanim cokolwiek zlecisz.