Jak przyspieszyć sklep PrestaShop — pełny przewodnik po optymalizacji szybkości i Google PageSpeed

„Sklep ładuje się wolno" to jedna z najczęstszych skarg właścicieli PrestaShop — i jeden z najgorzej zdiagnozowanych problemów. Zwykle winą obarcza się hosting, czasem konkretny moduł, czasem szablon. W praktyce wolny sklep to prawie zawsze suma kilku niezależnych problemów: słabego hostingu, wyłączonego cache, nieoptymalizowanych obrazów, nadmiaru modułów i zewnętrznych skryptów śledzących. Żaden pojedynczy „magiczny" moduł tego nie naprawi w pojedynkę.

Ten artykuł rozkłada temat na czynniki pierwsze: jak zmierzyć rzeczywisty problem, co go najczęściej powoduje w PrestaShop, co zrobić krok po kroku na poziomie hostingu, cache, bazy danych, obrazów i frontendu — oraz jakich wyników realnie można się spodziewać w Google PageSpeed Insights i Core Web Vitals, bez nierealistycznych obietnic „100/100 w 5 minut".

Dlaczego szybkość sklepu ma znaczenie

Szybkość ładowania nie jest kosmetyką — to metryka biznesowa. Google od lat oficjalnie wykorzystuje Core Web Vitals jako jeden z sygnałów rankingowych w wyszukiwarce, a badania dotyczące zachowań użytkowników w e-commerce konsekwentnie pokazują tę samą zależność: im dłużej ładuje się strona, tym wyższy współczynnik odrzuceń i niższa konwersja, zwłaszcza na urządzeniach mobilnych i wolniejszych połączeniach.

W praktyce sklepu internetowego przekłada się to na trzy konkretne obszary:

• SEO — Core Web Vitals to jeden z czynników rankingowych Google (tzw. Page Experience). Wolna strona nie dyskwalifikuje sklepu z wyników wyszukiwania, ale przy dwóch podobnie wartościowych stronach szybsza ma przewagę.
• Konwersja — użytkownik, który czeka kilka sekund na kartę produktu, częściej wraca do wyników wyszukiwania niż czeka dalej. Dotyczy to szczególnie ruchu mobilnego i reklamowego, gdzie koszt pozyskania kliknięcia już został poniesiony.
• Koszt reklamy — Google Ads od dawna uwzględnia jakość strony docelowej (landing page experience) w ocenie jakości reklamy, co przekłada się na koszt kliknięcia (CPC).

Jak zmierzyć szybkość — narzędzia i metryki

Zanim cokolwiek zaczniesz optymalizować, zmierz punkt wyjścia — inaczej nie ocenisz, czy zmiana faktycznie pomogła. Podstawowe, bezpłatne narzędzia:

• Google PageSpeed Insights (pagespeed.web.dev) — najpopularniejsze narzędzie, łączy dane laboratoryjne (Lighthouse, symulacja na jednym urządzeniu) z danymi terenowymi (CrUX — realni użytkownicy Chrome, jeśli strona ma wystarczający ruch).
• Google Search Console → Podstawowe wskaźniki internetowe — pokazuje realne dane Core Web Vitals zbierane od użytkowników odwiedzających sklep, pogrupowane per typ strony (produkt, kategoria, strona główna).
• GTmetrix / WebPageTest — bardziej szczegółowa analiza wodospadu żądań (waterfall), przydatna do namierzenia konkretnego zasobu, który blokuje renderowanie.
• Chrome DevTools → zakładka Lighthouse i Network — do pracy deweloperskiej na własnym środowisku, bez wysyłania danych na zewnątrz.

Trzy metryki, na które warto patrzeć w pierwszej kolejności (Core Web Vitals):

• LCP (Largest Contentful Paint) — czas wyrenderowania największego widocznego elementu (w sklepie zwykle główne zdjęcie produktu lub baner). Cel: poniżej 2,5 s.
• INP (Interaction to Next Paint) — czas reakcji strony na interakcję użytkownika (klik, dotknięcie). Zastąpił FID jako oficjalna metryka w marcu 2024. Cel: poniżej 200 ms.
• CLS (Cumulative Layout Shift) — miara „skakania" układu strony podczas ładowania (np. baner reklamowy, który dogruzuje się i przesuwa treść). Cel: poniżej 0,1.

Co najczęściej spowalnia sklep PrestaShop

Z doświadczenia audytów sklepów PrestaShop najczęstsze przyczyny wolnego działania układają się w powtarzalny wzorzec, niezależnie od branży czy wielkości katalogu:

• Tani, współdzielony hosting bez PHP OPcache, z limitowaną liczbą procesów PHP-FPM i wspólnymi zasobami CPU/RAM z setkami innych stron.
• Wyłączone lub źle skonfigurowane opcje wydajności w PrestaShop (cache Smarty, tryb debug włączony na produkcji, wyłączone CCC).
• Setki nieoptymalizowanych zdjęć produktowych — zbyt duża rozdzielczość, format JPEG/PNG zamiast WebP/AVIF, brak lazy loading.
• Nadmiar zainstalowanych i aktywnych modułów, z których część nie jest już używana, a każdy dopięty do hooka wykonuje kod przy każdym renderze strony.
• Rozrośnięte tabele bazy danych — logi, statystyki wyszukiwań, sesje gości rosnące latami bez czyszczenia, spowalniające zapytania SQL.
• Nieaktualna wersja PHP — każda kolejna główna wersja PHP (7.4 → 8.1 → 8.3) przynosiła realny wzrost wydajności silnika, niezależny od kodu sklepu.
• Ciężki motyw z niezoptymalizowanym JS/CSS — biblioteki jQuery, sliderów i animacji ładowane w całości na każdej podstronie, nawet tam, gdzie nie są potrzebne.
• Zewnętrzne skrypty trackingowe — piksele reklamowe, czaty, heatmapy, dodane bez atrybutów async/defer, blokujące renderowanie strony.
• Brak CDN dla plików statycznych (CSS, JS, obrazy) przy sklepach sprzedających do klientów oddalonych geograficznie od serwera.

Hosting i serwer — fundament, którego nie obejdziesz modułem

Żaden moduł optymalizacyjny nie naprawi sklepu postawionego na hostingu współdzielonym za kilkanaście złotych miesięcznie, na którym jeden proces PHP obsługuje setki stron jednocześnie. To pierwszy punkt audytu, bo determinuje sufit, powyżej którego dalsze optymalizacje przestają mieć znaczenie.

Rzeczy, które warto zweryfikować:

• PHP 8.3 (lub najnowsza wersja wspierana przez Twoją wersję PrestaShop) zamiast przestarzałego PHP 7.x — sam skok wersji silnika PHP potrafi skrócić czas generowania strony o kilkadziesiąt procent bez zmiany jednej linii kodu.
• PHP OPcache włączony i poprawnie skonfigurowany (opcache.enable=1, wystarczająca wielkość pamięci opcache.memory_consumption) — bez tego PHP kompiluje kod od nowa przy każdym żądaniu.
• Nginx + PHP-FPM zamiast Apache z mod_php — niższe zużycie pamięci na proces, lepsza obsługa równoległych żądań.
• Serwer bazy danych na tej samej maszynie lub w tej samej sieci lokalnej co aplikacja — opóźnienia sieciowe do zewnętrznej bazy potrafią zjeść więcej czasu niż samo wykonanie zapytania.
• Dysk SSD/NVMe zamiast HDD — przy dużych katalogach produktowych różnica w operacjach I/O jest odczuwalna.

Cache — ustawienia PrestaShop, Smarty, Redis

PrestaShop ma wbudowany panel wydajności (Parametry sklepu → Wydajność w PS 1.6/1.7/8, w nowszych wersjach zbudowanych na Symfony ustawienia cache konfiguruje się częściowo przez zmienne środowiskowe), który w praktyce jest najczęściej zaniedbywanym miejscem w całym sklepie:

• Tryb debug (_PS_MODE_DEV_) musi być wyłączony na produkcji. Pozostawiony włączony tryb deweloperski to jeden z najczęstszych, a zarazem najbardziej kosztownych błędów — wyłącza cache, generuje dodatkowe logi i znacząco spowalnia każde żądanie.
• Cache szablonów Smarty powinien być włączony, a katalogi cache/smarty/compile i cache/smarty/cache zapisywalne i nieczyszczone bez potrzeby przy każdym wdrożeniu.
• CCC (Combine, Compress, Cache) — wbudowana funkcja łączenia, kompresji i cache'owania plików CSS/JS. Warto ją włączyć i przetestować wizualnie, bo przy niektórych kombinacjach modułów potrafi łamać układ strony — dlatego wymaga testu po włączeniu, nie tylko „włącz i zapomnij".
• Cache obiektowy (Redis lub Memcached) zamiast domyślnego cache plikowego — przy większym ruchu i katalogu znacząco odciąża zapytania do bazy danych powtarzane przy każdym żądaniu (kategorie, ustawienia sklepu, tłumaczenia).
• HTTP cache / reverse proxy (Varnish, Nginx FastCGI cache) dla treści niewymagających personalizacji na poziomie serwera — najskuteczniejsze rozwiązanie dla ruchu anonimowego (katalog, strony kategorii), bo omija PHP całkowicie przy trafieniu w cache.

Baza danych — indeksy, sprzątanie logów, zapytania

Baza danych PrestaShop rośnie w czasie w sposób niekontrolowany, jeśli nikt jej regularnie nie sprząta. Tabele, które najczęściej puchną bez potrzeby:

• ps_connections i ps_connections_page — logi każdej wizyty na stronie, używane do statystyk. Po latach działania sklepu potrafią liczyć miliony wierszy, spowalniając zapytania na całej bazie.
• ps_guest — rekordy gości tworzone przy każdej sesji niezalogowanego użytkownika.
• ps_statssearch — historia wyszukiwań w sklepie, rosnąca bez limitu.
• logi błędów i historia mailingu w odpowiednich tabelach modułów marketingowych.

PrestaShop udostępnia w Admin → Zaawansowane → Baza danych narzędzie do optymalizacji tabel, a część powyższych tabel warto czyścić cyklicznie (cron) zamiast trzymać dane sprzed kilku lat, które i tak nie są już analizowane. Dodatkowo warto zweryfikować, czy własne zapytania w customowych modułach mają odpowiednie indeksy — brakujący indeks na kolumnie używanej w WHERE lub JOIN potrafi zamienić zapytanie trwające milisekundy w zapytanie trwające sekundy przy większym katalogu.

Obrazy — zwykle największy pojedynczy winowajca

W audytach sklepów e-commerce obrazy odpowiadają najczęściej za największą część wagi strony — częściej niż CSS, JS i HTML razem wzięte. Karta kategorii z kilkudziesięcioma miniaturami produktowymi to typowo najcięższy widok w całym sklepie.

• Format WebP lub AVIF zamiast JPEG/PNG — od wersji 8.1 PrestaShop ma eksperymentalną funkcję „Multiple image formats" (Parametry zaawansowane → Nowe i eksperymentalne funkcje), która pozwala generować obrazy produktowe w WebP i AVIF; w starszych wersjach lub gdy funkcja jest wyłączona, potrzebny jest moduł konwertujący istniejące zdjęcia.
• Odpowiednia rozdzielczość dla każdego typu widoku — miniatura na liście kategorii nie potrzebuje zdjęcia w rozdzielczości karty produktu ani tym bardziej pliku źródłowego 4000×4000 px wgranego przez producenta.
• Lazy loading (atrybut loading="lazy" lub biblioteka JS) dla obrazów poniżej pierwszego ekranu — przeglądarka nie pobiera ich, dopóki użytkownik nie przescrolluje do nich strony.
• Kompresja bezstratna/stratna przy uploadzie — automatyczna kompresja nowo wgrywanych zdjęć eliminuje problem u źródła, zamiast naprawiać go później masowo.
• Atrybuty width/height na znacznikach <img> — przeglądarka rezerwuje miejsce na obraz przed jego załadowaniem, co bezpośrednio poprawia CLS.

CSS, JS i motyw — CCC, minifikacja, nadmiar modułów

Każdy zainstalowany i aktywny moduł, nawet ten pozornie niewinny, dopina się do hooków wykonywanych na każdej stronie sklepu — a często dokłada też własne pliki CSS/JS ładowane globalnie, niezależnie od tego, czy dana podstrona z nich korzysta.

• Audyt zainstalowanych modułów — odinstaluj (nie tylko wyłącz) moduły, które faktycznie nie są używane. Wyłączony moduł czasem nadal wykonuje część kodu inicjalizującego.
• Minifikacja i łączenie plików CSS/JS — mniej żądań HTTP i mniejsza waga transferu, szczególnie odczuwalne przy HTTP/1.1; przy HTTP/2 łączenie plików ma mniejsze znaczenie niż sama redukcja wagi.
• Atrybuty async/defer dla skryptów niekrytycznych — skrypt bez tych atrybutów blokuje parsowanie i renderowanie strony do czasu jego pobrania i wykonania.
• Usunięcie nieużywanego CSS/JS z motywu — wiele darmowych i płatnych szablonów PrestaShop ładuje pełne biblioteki (np. wszystkie warianty slidera, wszystkie ikony fontowe) niezależnie od tego, z ilu z nich sklep faktycznie korzysta.

Zewnętrzne skrypty — piksele, czaty, analytics

Piksel Facebooka, Google Ads, TikToka, widget czatu na żywo, skrypt heatmapy, kilka narzędzi analitycznych naraz — każdy z nich to dodatkowe żądanie do zewnętrznego serwera, poza kontrolą Twojego hostingu. W wielu audytach to właśnie zewnętrzne skrypty, a nie kod samego sklepu, odpowiadają za największe opóźnienia LCP i INP.

• Ładuj skrypty trackingowe asynchronicznie i, jeśli to możliwe, przez Google Tag Manager zamiast wklejać każdy piksel osobno w kodzie szablonu.
• Regularnie audytuj, które piksele i skrypty są faktycznie używane — porzucone kampanie reklamowe sprzed lat często zostawiają po sobie działający, zbędny kod śledzący.
• Widgety czatu warto ładować z opóźnieniem (np. po interakcji użytkownika lub po kilku sekundach) zamiast blokować nimi pierwsze renderowanie strony.

CDN i kompresja transferu

Jeśli sklep sprzedaje do klientów w różnych krajach, a serwer fizycznie znajduje się w jednym miejscu (np. w Polsce), użytkownik z innego kontynentu odczuje opóźnienie sieciowe niezależnie od tego, jak dobrze zoptymalizowany jest kod. CDN (sieć dostarczania treści) rozwiązuje to, serwując pliki statyczne (CSS, JS, obrazy) z serwera geograficznie bliższego użytkownikowi.

• CDN dla plików statycznych — CSS, JS, obrazy produktowe, czcionki. Skraca czas pobierania i odciąża serwer aplikacji od obsługi zwykłych żądań o pliki.
• Kompresja Brotli lub gzip na poziomie serwera — powinna być włączona domyślnie na każdym nowoczesnym hostingu, ale warto to zweryfikować w nagłówkach odpowiedzi HTTP.
• HTTP/2 lub HTTP/3 zamiast HTTP/1.1 — wielokrotne żądania w ramach jednego połączenia, bez narzutu na każde nowe połączenie TCP/TLS.

Jakie wyniki da się realnie osiągnąć

Trzeba tu być uczciwym: sklep e-commerce z dziesiątkami zdjęć produktowych, kilkoma skryptami trackingowymi i dynamicznie generowaną treścią nigdy nie będzie ładował się tak szybko jak statyczna strona wizytówkowa. Wynik 100/100 w Google PageSpeed Insights na urządzeniach mobilnych dla realnego sklepu z pełną ofertą jest rzadkością, a pogoń za nim bywa stratą czasu kosztem funkcjonalności.

Realistyczne, obserwowane w praktyce zakresy wyników:

• Sklep bez żadnej optymalizacji (tani hosting, debug włączony, ciężkie obrazy, brak cache) — zwykle 15–35 punktów mobile w PageSpeed Insights, LCP często powyżej 5–6 sekund.
• Po podstawowej optymalizacji (dobry hosting, PHP 8.3, cache Smarty, wyłączony debug, skompresowane obrazy) — typowo 50–70 punktów mobile, LCP w okolicach 3–4 sekund.
• Po pełnej optymalizacji (dodatkowo: CDN, cache obiektowy/Redis, WebP, lazy loading, ograniczenie zewnętrznych skryptów, minifikacja) — realistycznie 70–90 punktów mobile i zwykle 90+ na desktopie, LCP poniżej 2,5 sekundy.

Te liczby to orientacyjne przedziały z audytów sklepów o różnej wielkości katalogu, a nie gwarancja — ostateczny wynik zależy od liczby produktów, złożoności szablonu, liczby zainstalowanych modułów i realnego ruchu. Warto traktować je jako punkt odniesienia, a nie jako obietnicę konkretnej liczby.

Checklist — kolejność działań

Jeśli zaczynasz od zera, poniższa kolejność zwykle daje najlepszy stosunek efektu do włożonej pracy:

1. Zmierz punkt wyjścia w PageSpeed Insights i Search Console — bez tego nie ocenisz postępu.
2. Zweryfikuj hosting: PHP 8.3, OPcache, Nginx + PHP-FPM, dysk SSD/NVMe.
3. Wyłącz tryb debug na produkcji i włącz cache Smarty oraz CCC.
4. Wysprzątaj bazę danych — tabele logów, statystyk, sesji gości.
5. Skompresuj i skonwertuj obrazy do WebP, dodaj lazy loading i atrybuty width/height.
6. Zaudytuj i odinstaluj nieużywane moduły.
7. Uporządkuj zewnętrzne skrypty trackingowe — async/defer, opóźnione ładowanie czatu.
8. Dodaj CDN dla plików statycznych, jeśli sprzedajesz poza jeden region.
9. Zmierz ponownie i porównaj wynik z punktem wyjścia.

Podsumowanie

Szybki sklep PrestaShop to nie efekt jednej zmiany, tylko konsekwentnego domknięcia kilku obszarów naraz: hostingu, cache, bazy danych, obrazów, frontendu i zewnętrznych skryptów. Największy, najszybciej odczuwalny efekt zwykle daje kolejność: dobry hosting → wyłączony debug i włączony cache → optymalizacja obrazów → sprzątanie bazy → ograniczenie modułów i skryptów zewnętrznych. Realistycznym celem dla sklepu z pełną ofertą produktową jest wynik 70–90 punktów mobile w PageSpeed Insights i LCP poniżej 2,5 sekundy — nie 100/100, ale różnica odczuwalna zarówno przez klientów, jak i przez Google.