Wydajność PrestaShop i Shoper: co najczęściej spowalnia sklep

Wolny sklep internetowy potrafi mieć kilka przyczyn jednocześnie. Wydajność sklepu na PrestaShop albo Shoperze zależy nie tylko od samej platformy, ale też od liczby modułów, sposobu zbudowania szablonu, zapytań do bazy danych, plików JavaScript i CSS oraz konfiguracji środowiska, na którym działa sklep. Dlatego samo uruchomienie testu szybkości nie odpowiada jeszcze na pytanie, co konkretnie spowalnia stronę.

Diagnostykę najlepiej zacząć od ustalenia, czy problem pojawia się przed wysłaniem strony do przeglądarki, podczas generowania HTML, czy dopiero po pobraniu zasobów przez użytkownika. Inaczej szuka się przyczyny wysokiego czasu odpowiedzi serwera, a inaczej ciężkiego JavaScriptu, dużych zdjęć czy rozbudowanego szablonu.

Od czego zacząć diagnostykę wydajności PrestaShop i Shopera

Pierwszy krok to nie zmiana ustawień, lecz zebranie kilku obserwacji. Sprawdź stronę główną, kategorię, kartę produktu, wyniki wyszukiwania oraz koszyk. Nie zakładaj, że skoro strona główna działa szybko, cały sklep jest szybki. W sklepie internetowym różne podstrony wykonują różną pracę po stronie serwera i mogą ładować zupełnie inne zasoby.

Zwróć uwagę na trzy sytuacje. Jeżeli HTML zaczyna przychodzić późno, szukaj problemu po stronie serwera, aplikacji, modułów, zapytań lub cache. Jeżeli HTML pojawia się szybko, ale przeglądarka długo pobiera pliki i obrazy, sprawdź frontend. Jeżeli zasoby są już pobrane, a strona nadal długo pozostaje zajęta, przeanalizuj JavaScript, CSS i pracę głównego wątku przeglądarki.

Pomocny jest podział czasu ładowania na TTFB, pobieranie zasobów i ich renderowanie. W przypadku LCP Google wskazuje między innymi na czas oczekiwania na pierwszy bajt, opóźnienie rozpoczęcia pobierania głównego zasobu, czas jego pobierania oraz opóźnienie renderowania. Taki podział pozwala przestać zgadywać i zacząć szukać konkretnego miejsca problemu.

Jeżeli chcesz szerzej przeanalizować zależność między serwerem, frontendem i zasobami strony, przydatne będzie również zestawienie co realnie skraca czas ładowania sklepu, bo pozwala uporządkować diagnostykę poza samą platformą.

Dobrym początkiem jest też porównanie kilku pomiarów wykonanych w podobnych warunkach. Jeden test może pokazać chwilowe przeciążenie, brak rozgrzanego cache albo problem z siecią. Nie wyciągaj więc wniosków z pojedynczego wyniku.

Moduły i dodatki jako źródło problemów

W PrestaShop moduły są jednym z pierwszych miejsc, które trzeba sprawdzić. Sklep może działać poprawnie po instalacji, a następnie stopniowo zwalniać wraz z kolejnymi integracjami, filtrami, systemami rekomendacji, narzędziami marketingowymi, modułami płatności czy dodatkami do obsługi produktów.

Problem nie musi polegać na tym, że moduł jest źle napisany. Czasem moduł wykonuje dużo pracy, której użytkownik nie widzi. Może dodawać zapytania do bazy, ładować własne pliki JavaScript i CSS, wykonywać operacje na każdym produkcie albo podpinać się do wielu hooków strony.

Przy pomiarach warto zacząć od dodatków, które z natury wykonują dużo pracy: kreatorów wyglądu (np. Creative Elements), rozbudowanych modułów blogowych, mega menu, modułów dodatkowych zakładek produktu, zaawansowanych filtrów przy dużym katalogu, rekomendacji produktów, popupów marketingowych, integracji z marketplace i programów lojalnościowych. Sama nazwa modułu nie jest dowodem problemu. Rozstrzyga pomiar przed i po jego wyłączeniu na kopii sklepu. Sprawdź też moduły, których nikt już nie używa, a które nadal dołączają swoje pliki CSS i JavaScript do każdej podstrony.

W praktyce diagnostykę PrestaShop zacznij od spisania zmian, które pojawiły się przed wystąpieniem problemu. Jeżeli sklep był szybki przed instalacją konkretnego dodatku, a po jego wdrożeniu pojawiło się opóźnienie, masz pierwszy trop. Następnie sprawdź, czy moduł można tymczasowo wyłączyć na kopii testowej sklepu i porównać zachowanie strony.

Nie usuwaj modułów produkcyjnych w ciemno. Najpierw wykonaj kopię zapasową i, jeżeli to możliwe, testuj na środowisku testowym. Szczególnie ostrożnie podchodź do dodatków związanych z płatnościami, zamówieniami, wysyłką i integracjami z zewnętrznymi systemami.

W Shoper sytuacja wygląda inaczej pod względem technicznym, ale diagnostyka dodatków nadal ma sens. Platforma udostępnia aplikacje i integracje, a w rozwiązaniach opartych na Storefront można również korzystać z dodatkowych elementów i własnego kodu JavaScript. Jeżeli problem pojawił się po zmianie funkcjonalności, szukaj zależności między wdrożeniem a momentem pogorszenia szybkości.

Przy większej liczbie dodatków nie oceniaj ich wyłącznie na podstawie tego, czy widzisz ich element na stronie. Dodatek może wykonywać pracę w tle albo dołączać zasoby do wielu podstron, nawet jeśli jego widoczny komponent znajduje się tylko w jednym miejscu.

Szablon i frontend: CSS, JavaScript oraz obrazy

Druga grupa problemów dotyczy tego, co ostatecznie pobiera przeglądarka. Rozbudowany szablon może wyglądać atrakcyjnie, ale jednocześnie dostarczać dużą liczbę plików CSS, JavaScript, fontów, obrazów i elementów interaktywnych.

Jeżeli sklep ma dużo animacji, sliderów, popupów, filtrów, liczników, dodatkowych menu i zewnętrznych skryptów, sprawdź, czy wszystkie te elementy są ładowane podczas pierwszego wejścia. Część funkcji może być potrzebna dopiero po interakcji użytkownika, więc nie ma powodu, aby obciążała początkowe renderowanie strony.

Szczególną uwagę zwróć na JavaScript. Duży plik nie jest jedynym problemem. Liczy się również czas jego parsowania i wykonania. Skrypt może blokować główny wątek przeglądarki, przez co strona wizualnie wygląda na załadowaną, ale użytkownik nadal nie może sprawnie z niej korzystać.

W DevTools sprawdź zakładkę Network i Performance. Zobacz, które zasoby są pobierane jako pierwsze, ile zajmują oraz co blokuje renderowanie. Jeżeli wiele plików pochodzi z zewnętrznych domen, sprawdź również, czy wszystkie są rzeczywiście potrzebne.

Obrazy wymagają osobnej kontroli. Na karcie produktu zdjęcie może mieć rozmiar znacznie większy niż rzeczywisty obszar, w którym jest wyświetlane. W takim przypadku przeglądarka pobiera więcej danych, niż użytkownik potrzebuje. Responsive images pozwalają dostarczać różne warianty obrazu zależnie od urządzenia i rozmiaru ekranu.

W PrestaShop sprawdź też typy obrazów i generowanie miniatur oraz to, czy motyw nie wstawia większych wersji zdjęć tam, gdzie wystarczy mniejsza.

Nie ustawiaj jednak leniwego ładowania na wszystko bez sprawdzenia. Jeżeli główne zdjęcie produktu lub baner jest elementem LCP, jego opóźnione pobieranie może pogorszyć wynik. Zasada jest prosta: element widoczny od razu powinien być traktowany inaczej niż obrazy znajdujące się daleko poniżej pierwszego ekranu.

Jeżeli chcesz połączyć problemy techniczne z konkretnymi wskaźnikami przeglądarki, przydatny będzie materiał jak analizować Core Web Vitals sklepu, szczególnie gdy problem jest widoczny w LCP, INP albo CLS.

Baza danych i generowanie strony w PrestaShop

W przypadku PrestaShop baza danych może być częścią problemu wtedy, gdy sklep wykonuje dużo zapytań lub zapytania są kosztowne. Nie chodzi wyłącznie o wielkość bazy. Znaczenie ma również sposób, w jaki moduły i mechanizmy sklepu korzystają z danych.

Typowym sygnałem jest sytuacja, w której strona długo czeka na odpowiedź serwera jeszcze zanim przeglądarka zacznie pobierać większość zasobów. Jeżeli problem powtarza się na stronach wymagających filtrowania, wyszukiwania lub przetwarzania dużej liczby produktów, warto sprawdzić część backendową.

W diagnostyce sprawdź logi aplikacji, czas wykonywania zapytań oraz obciążenie bazy podczas generowania problematycznej strony. Jeżeli masz dostęp do serwera, przydatne są również informacje o CPU, pamięci, dysku i procesach PHP oraz MySQL lub MariaDB.

Nie optymalizuj tabel tylko dlatego, że baza jest duża. Najpierw ustal, które operacje są wolne. Bez tego łatwo wykonać zmianę, która nie ma związku z rzeczywistym problemem.

PrestaShop ma mechanizmy cache, a dokumentacja opisuje między innymi cache Smarty oraz pliki używane do przechowywania informacji potrzebnych aplikacji. Przy diagnostyce sprawdź więc, czy cache działa zgodnie z założeniami środowiska produkcyjnego. W dokumentacji dotyczącej benchmarków PrestaShop zwraca również uwagę na znaczenie konfiguracji cache oraz pracy sklepu w trybie produkcyjnym.

W panelu i konfiguracji sprawdź także ustawienia kompilacji szablonów, łączenie i kompresję plików CSS i JavaScript (CCC), zgodność modułów z wersją sklepu oraz nadpisania klas (override), bo każde z nich zmienia sposób działania rdzenia sklepu.

Warto też pamiętać o różnicy między pierwszym a kolejnym wejściem. Jeżeli strona po odświeżeniu działa znacznie szybciej, może to wskazywać na wykorzystanie cache. Jeżeli oba przypadki są wolne, szukaj przyczyny głębiej.

Co spowalnia sklep Shoper

W przypadku Shopera nie masz takiej kontroli nad serwerem i bazą danych jak w instalacji PrestaShop na własnym środowisku. Diagnostyka wygląda więc nieco inaczej. Większy nacisk kładziesz na szablon, aplikacje, konfigurację strony, zasoby frontendowe, obrazy oraz zewnętrzne skrypty.

Jeżeli pytasz, co spowalnia sklep Shoper, zacznij od sprawdzenia, co zostało dodane do strony poza podstawową konfiguracją. Analizuj zmiany w szablonie, własny JavaScript, narzędzia analityczne, systemy reklamowe, czaty, popupy oraz inne elementy ładowane z zewnętrznych serwerów.

Shoper rozwija technologię Storefront, która wykorzystuje modułową konstrukcję i mechanizmy związane z ładowaniem potrzebnych elementów. Nie oznacza to jednak, że każdy sklep oparty na tej technologii będzie automatycznie szybki. Sposób przygotowania grafik, liczba dodatków, własny kod i zewnętrzne skrypty nadal mają wpływ na to, co pobiera przeglądarka.

Jeżeli problem występuje tylko na konkretnej stronie, porównaj ją z prostszą podstroną. Przykładowo, jeżeli karta produktu jest wolna, a strona kontaktowa ładuje się sprawnie, nie zaczynaj od szukania problemu w całym sklepie. Sprawdź elementy charakterystyczne dla karty produktu: galerie, warianty, rekomendacje, opinie, dodatkowe aplikacje i skrypty.

Jeżeli natomiast wszystkie podstrony mają podobnie wysoki TTFB, przyczyna może znajdować się poza elementami widocznymi w szablonie. W takim przypadku zbierz wyniki z kilku adresów i przekaż je do supportu platformy wraz z informacją o czasie wystąpienia problemu oraz konkretnymi adresami stron.

Serwer, PHP i czas odpowiedzi

W PrestaShop serwer ma bezpośredni wpływ na działanie aplikacji. Możesz mieć dobrze przygotowany frontend, a mimo tego strona będzie reagowała wolno, jeżeli PHP czeka na zasoby, baza danych jest przeciążona albo środowisko nie ma odpowiednich zasobów.

Przy diagnozie sprawdź CPU, RAM, obciążenie procesów PHP, dostępne miejsce na dysku oraz czas odpowiedzi bazy. Jeżeli sklep działa na VPS, zwróć uwagę również na limity procesów i konfigurację usług. Sam fakt, że serwer ma dużo pamięci, nie oznacza jeszcze, że aplikacja korzysta z niej efektywnie.

PrestaShop w swojej dokumentacji dotyczącej optymalizacji serwera zaleca podejście oparte na pomiarze, zmianie i ponownym pomiarze. To ważniejsze niż wybieranie konfiguracji na podstawie ogólnych porad. Parametry serwera trzeba odnosić do konkretnego obciążenia sklepu.

W przypadku hostingu współdzielonego dodatkowym problemem może być konkurencja o zasoby. Jeżeli sklep okresowo zwalnia, sprawdź, czy spadki szybkości pokrywają się z większym ruchem lub obciążeniem środowiska. Jeżeli masz dostęp do logów, szukaj powtarzających się błędów i długich odpowiedzi.

W Shopera sytuacja jest prostsza od strony infrastruktury, ponieważ hosting stanowi część usługi platformy. Nie oznacza to jednak, że możesz pominąć analizę serwera. Jeśli pomiary pokazują wysoki TTFB na wielu podstronach, a frontend nie generuje nietypowego obciążenia, problem trzeba rozpatrywać na poziomie infrastruktury platformy.

Tabela: obszary wydajności obu platform i typowe źródła problemów

Obszar	PrestaShop	Shoper	Co sprawdzić najpierw
Moduły i aplikacje	Moduły, integracje, hooki, dodatkowe zapytania	Aplikacje, integracje i dodatkowe funkcje	Co zostało dodane przed pojawieniem się problemu
Szablon	Smarty, własny kod, motywy, dodatkowe komponenty	Szablon, Storefront, własny kod i moduły	Liczbę zasobów CSS i JavaScript
JavaScript	Skrypty modułów i szablonu	Własny kod, aplikacje i zewnętrzne skrypty	Long tasks, blokowanie głównego wątku
CSS	Duże arkusze, nieużywane style, moduły	Style szablonu i dodatkowych elementów	Pliki blokujące renderowanie
Obrazy	Galerie, miniatury, zdjęcia produktów	Galerie, banery, zdjęcia produktów	Rozmiar, format i sposób ładowania
Baza danych	Zapytania produktów, kategorii, filtrów i modułów	Zarządzana przez platformę	Czy problem dotyczy konkretnych operacji
Cache	Cache aplikacji, Smarty i mechanizmy serwera	Mechanizmy platformy	Różnicę między pierwszym i kolejnym wejściem
Serwer	VPS, hosting, PHP, baza, webserver	Infrastruktura platformy	TTFB i powtarzalność problemu
Zewnętrzne usługi	Analityka, reklamy, płatności, CDN	Analityka, reklamy, czaty, integracje	Czas i liczbę połączeń do innych domen

Tabela pokazuje też podstawową różnicę w podejściu. W PrestaShop możesz zejść znacznie głębiej, aż do konfiguracji PHP, bazy danych i webservera. W Shoperze większa część infrastruktury pozostaje po stronie dostawcy, dlatego więcej czasu poświęcasz na frontend i elementy konfigurowalne w sklepie.

Jak sprawdzić wydajność PrestaShop krok po kroku

Jeżeli chcesz wiedzieć, jak sprawdzić wydajność PrestaShop bez chaotycznego zmieniania ustawień, zastosuj stałą kolejność.

Najpierw wybierz kilka reprezentatywnych adresów. Nie ograniczaj się do strony głównej. Dodaj kategorię, produkt, wyszukiwarkę oraz koszyk. Następnie wykonaj pomiary w podobnych warunkach i zapisz TTFB, LCP, INP, CLS oraz informacje o liczbie i rozmiarze zasobów.

Następnie otwórz DevTools i przejdź do Network. Posortuj żądania według czasu. Zobacz, czy najdłuższe operacje dotyczą dokumentu HTML, obrazów, JavaScriptu, CSS czy zewnętrznych usług.

Jeżeli dokument HTML jest wolny, przejdź do backendu. Sprawdź moduły, logi, PHP, bazę danych, cache i serwer. Jeżeli HTML jest szybki, ale strona długo się renderuje, przejdź do CSS, JavaScriptu, obrazów i fontów.

Potem wykonaj jeden test po drugiej zmianie. Jeżeli wyłączasz moduł, mierz przed i po. Jeżeli zmniejszasz obraz, sprawdź zmianę w Network. Jeżeli zmieniasz sposób ładowania JavaScriptu, sprawdź Performance. Dzięki temu wiesz, co faktycznie zmieniło zachowanie strony.

Taką samą metodę można zastosować do Shopera, z tym że część backendowa jest mniej dostępna. Wtedy większą uwagę zwróć na zasoby przeglądarki, szablon, aplikacje i zewnętrzne skrypty.

Jak odróżnić problem serwera od problemu frontendowego

To jedno z najważniejszych rozróżnień podczas audytu. Jeżeli TTFB jest wysoki, przeglądarka długo czeka na HTML. Wtedy optymalizacja obrazów może nie rozwiązać głównego problemu, ponieważ przeglądarka nie ma jeszcze strony, na której mogłaby te obrazy wyświetlić.

Jeżeli TTFB jest niski, ale LCP pojawia się późno, sprawdź zasób odpowiedzialny za LCP. Może to być duże zdjęcie, blok tekstu albo inny element widoczny w pierwszym widoku. Sprawdź, kiedy przeglądarka odkrywa ten zasób i czy wcześniej nie wykonuje niepotrzebnej pracy.

Jeżeli strona wygląda na gotową, ale reaguje z opóźnieniem, przeanalizuj JavaScript i długie zadania głównego wątku. W takim przypadku problemem może być nie czas pobierania strony, lecz czas wykonywania kodu w przeglądarce.

To rozróżnienie pozwala uniknąć częstego błędu: optymalizacji nie tego elementu, który rzeczywiście tworzy opóźnienie. Zanim zmienisz hosting, sprawdź TTFB. Zanim przebudujesz szablon, sprawdź waterfall. Zanim skompresujesz wszystkie zdjęcia, ustal, które z nich rzeczywiście wpływa na LCP.

Jeżeli zastanawiasz się nad samą architekturą sklepu i chcesz porównać ograniczenia oraz możliwości platform, pomocny może być tekst porównanie WooCommerce PrestaShop i Shoper, szczególnie przed większą przebudową sklepu.

Tę samą metodę dla sklepów na WordPressie opisuje materiał o wydajności WooCommerce.

Co zrobić po znalezieniu przyczyny

Po znalezieniu źródła problemu nie wprowadzaj od razu wielu zmian. Jeżeli usuniesz kilka modułów, zmienisz obrazy, przebudujesz CSS i zmienisz konfigurację cache jednocześnie, później trudno ustalić, która zmiana miała znaczenie.

Zapisz stan początkowy. Wybierz jedną przyczynę, wprowadź zmianę i ponów pomiar. Przy problemach z modułami zacznij od dodatku, który pojawił się przed pogorszeniem szybkości. Przy problemach frontendowych zacznij od zasobu wskazanego przez waterfall. Przy wysokim TTFB przejdź do backendu i infrastruktury.

W PrestaShop szczególnie opłaca się rozdzielić diagnostykę aplikacji od diagnostyki serwera. Jeżeli oba obszary analizujesz jednocześnie, łatwo pomylić skutek z przyczyną. W Shoperze z kolei pierwszym miejscem kontroli zwykle będzie warstwa dostępna po stronie właściciela sklepu, czyli szablon, aplikacje, obrazy i zewnętrzne skrypty.

Jeżeli sklep ma wiele integracji i problem dotyczy kilku różnych podstron, zamiast poprawiać pojedynczy element na ślepo, przygotuj pełną listę zasobów i zależności. Taka lista porządkuje pracę wtedy, gdy problem nie ogranicza się do jednego obrazu czy jednego modułu.

Gdy z pomiarów wynika, że potrzebujesz analizy konkretnego sklepu, audyt szybkości sklepu internetowego pozwala przejść od ogólnych wskazówek do sprawdzenia rzeczywistych przyczyn spowolnienia.

Podsumowanie: najpierw pomiar, potem optymalizacja

Wydajność PrestaShop i wydajność Shoper mogą pogarszać się z zupełnie różnych powodów, ale sposób diagnozowania pozostaje podobny. Najpierw ustalasz, czy opóźnienie powstaje po stronie serwera, aplikacji czy przeglądarki. Dopiero potem wybierasz konkretną zmianę.

W PrestaShop szczególną uwagę poświęć modułom, zapytaniom do bazy, cache, PHP i serwerowi. W Shoperze sprawdź przede wszystkim szablon, aplikacje, własny kod, obrazy oraz zewnętrzne skrypty. W obu przypadkach przeanalizuj CSS, JavaScript, fonty i sposób dostarczania głównego elementu strony.

Nie zaczynaj od przypadkowego instalowania kolejnej wtyczki optymalizacyjnej ani od zmiany hostingu bez pomiarów. Jeżeli wiesz, czy problemem jest TTFB, pobieranie zasobu, renderowanie czy wykonanie JavaScriptu, lista możliwych przyczyn szybko się zawęża.

To właśnie od takiej kolejności powinno zaczynać się diagnozowanie wolnego sklepu: adres strony, pomiar, waterfall, identyfikacja najwolniejszego elementu, jedna zmiana i ponowny pomiar. Dopiero na tej podstawie ma sens dalsza optymalizacja PrestaShop albo optymalizacja Shoper.