Spis treści
- Gdy każda sekunda kosztuje sprzedaż
- Diagnoza: gdzie naprawdę tracisz czas ładowania
- Serwer i hosting: baza wydajności, którą możesz kontrolować
- Ustawienia PrestaShop i cache: szybkie zyski bez kodowania
- Baza danych i moduły: porządek, który skraca TTFB
- Front‑end i multimedia: WebP/AVIF, CDN i Core Web Vitals
- Plan utrzymania: monitoring, testy A/B i bezpieczne wdrożenia
- Szybkość jako przewaga: sklep, który nie zwalnia tempa
Gdy każda sekunda kosztuje sprzedaż
1 sekunda opóźnienia = 20% spadku konwersji (Google)
Brzmi dramatycznie? No, może trochę. Ale jeśli prowadzisz sklep PrestaShop i widzisz, że czasy ładowania przekraczają 3 sekundy, to porzucone koszyki stają się normą, nie wyjątkiem.
Dlaczego PrestaShop bywa ciężki
PrestaShop generuje wszystko dynamicznie. PHP odpytuje MySQL, moduły dorzucają swoje zapytania, szablony ładują zasoby. Na pojedynczej stronie produktu? Spokojnie może być 200-300 zapytań do bazy. Na współdzielonym hostingu za 15 zł miesięcznie to po prostu nie zadziała płynnie, bez względu na optymalizację.
Temat „wolny sklep” wraca regularnie na polskich forach PS. Społeczność dzieli się workaroundami, właściciele sklepów szukają szybkich recept. PrestaShop 9 obiecuje do 40% szybsze wczytywanie dzięki WebP i AVIF, ale to nie zmienia architektury.
Co możesz zrobić
Diagnoza to pierwszy krok. Potem przychodzi czas na hosting (albo dedykowany serwer dla Prestashop), konfigurację cache, optymalizację bazy, przegląd modułów i front-end z CDN. Brzmi jak dużo pracy? Trochę tak, ale każdy element da ci wymierne przyspieszenie.
Zacznijmy od sprawdzenia, gdzie faktycznie jest problem. Bez tego strzelasz na ślepo.
Diagnoza: gdzie naprawdę tracisz czas ładowania
Zanim zainwestujesz w droższy hosting albo przepiszesz połowę kodu, musisz wiedzieć, co naprawdę spowalnia Twój sklep. Bez konkretnych liczb strzelasz na oślep.
Narzędzia i metryki, które mają znaczenie
Google PageSpeed Insights to dobry start, bo pokazuje Core Web Vitals i daje ocenę mobilną (którą Google faktycznie bierze pod uwagę w rankingu). GTmetrix i Pingdom dodają waterfall, czyli wizualną mapę tego, co się ładuje i w jakiej kolejności. Widzisz tam każdy plik, każde żądanie, każde opóźnienie.
Ale dla PrestaShop kluczowy jest PrestaShop Profiler w trybie debug. On pokaże Ci zapytania SQL, które trwają wieczność. Bo często to nie hosting jest wolny, tylko zapytanie do bazy ciągnie się 4 sekundy przez źle skonfigurowany moduł.
Metryki, na które patrzę najpierw:
| Metryka | Co to znaczy | Cel |
|---|---|---|
| TTFB | Czas do pierwszego bajtu, reakcja serwera | <600 ms |
| LCP | Largest Contentful Paint, główny element widoczny | <2,5 s |
| Zapytania | Liczba requestów HTTP na stronę | PS 1.7: ~120, PS 1.6: może 180 |
| Rozmiar | Cała waga strony ze wszystkim | <3 MB |
Plan testów: co, gdzie i jak mierzyć
Zmierz trzy typy stron: główną, kategorię z produktami i kartę produktu. Desktop i mobile osobno. Powtórz każdy pomiar 3 razy w różnych porach dnia (rano, południe, wieczór) i weź medianę, bo hosting współdzielony potrafi skakać jak szalony przez „noisy neighbors”.
Zapisz wyniki w prostej tabeli. Jeśli widzisz TTFB powyżej 1 sekundy albo slider waży 3 MB, to już wiesz, od czego zacząć. Długie zapytania SQL? Profiler wskaże konkretne moduły. Render‑blocking JS w<head>? Waterfall pokaże czerwone bloki.
Mając te dane, możesz wreszcie zdecydować, czy problem leży w serwerze, czy w konfiguracji sklepu.
Serwer i hosting: baza wydajności, którą możesz kontrolować
Zacznijmy od podstaw. Jeśli PrestaShop działa wolno mimo optymalizacji, to często problem tkwi głębiej – w samym serwerze. Hosting współdzielony za 15 zł miesięcznie po prostu nie udźwignie sklepu z 500+ produktami i kilkuset odwiedzin dziennie.
Jaki typ hostingu do jakiego sklepu?
Mały sklep (do 100 produktów, może 50 zamówień miesięcznie) przetrwa na przyzwoitym współdzielonym, ale już średniej wielkości operacja potrzebuje VPS‑a z conajmniej 4 GB RAM. Duże sklepy? Tutaj mówisz o 8 GB RAM minimum, NVMe zamiast HDD (różnica w czasie zapytań do bazy: z ~200 ms spadasz do ~20 ms), oraz PHP 8.1 albo nowszy. MariaDB 10+ też się przyda.
| Wielkość sklepu | RAM | Hosting |
|---|---|---|
| Mały (do 100 produktów) | 2-4 GB | VPS lub lepszy współdzielony |
| Średni (do 1000 produktów) | 6-8 GB | VPS z NVMe |
| Duży (1000+ produktów) | 16+ GB | Dedykowany lub LiteSpeed |
Cache serwerowe, które robią różnicę
Redis albo Memcached (cache obiektowy) przyspiesza sesje i zapytania. Varnish (full‑page cache) potrafi zbić czas ładowania z 5 sekund do 0,3 s przy dobrze skonfigurowanym stosie. LiteSpeed z wtyczką LSCache daje podobne efekty, a „zarządzany hosting” często ustawia to automatycznie – płacisz więcej, ale dostajesz 99,9% uptime i czasy <2 s bez majstrowania.
Tak naprawdę? Dobry serwer to fundament. Możesz potem śrubować ustawienia w PrestaShop, ale jeśli baza wyjściowa jest słaba, naprawisz tylko objawy.
Ustawienia PrestaShop i cache: szybkie zyski bez kodowania
Zanim sięgniesz po drogie usprawnienia serwera, możesz dużo wycisnąć z samego PrestaShop. Mówimy o ustawieniach, które zajmują kilka kliknięć, a potrafią skrócić czas ładowania o sekundy. Nie każdy o nich pamięta, więc warto sprawdzić.
CCC i Smarty: ustaw i przyspiesz
W panelu PS znajdziesz sekcję „Wydajność” (albo „Performance” w starszych wersjach). Tutaj włączasz tzw. CCC, czyli Combine, Compress, Cache dla CSS i JavaScript. Brzmi skomplikowanie, ale to tylko checkboxy:
- Łączenie plików CSS/JS – mniej żądań HTTP
- Kompresja plików – mniejszy rozmiar do przesłania
- Cache Smarty – szablony kompilują się raz, nie za każdym razem
- Clear cache on save – żeby zmiany od razu były widoczne
Smarty to silnik szablonów PS. Gdy włączysz cache szablonów i kompilację, serwer przestaje generować HTML od zera przy każdym wejściu. To naprawdę robi różnicę, szczególnie przy mało wydajnym hostingu.
Cache pełno‑stronicowy w praktyce
Jeśli masz LiteSpeed na serwerze, moduł LSCache to must have. Dla Apache/nginx sprawdź Page Cache Ultimate. Oba cache’ują całą stronę i serwują ją natychmiast, bez odpytywania bazy.
Realne liczby? Sklep ze średnią 5 s potrafi spaść do 0,3 s po włączeniu cache pełno‑stronicowego.
Oczywiście to działa najlepiej dla gości (zalogowani użytkownicy widzą dynamiczną treść), ale goście to większość ruchu. Nowsze wersje PS (8 i 9) dodają natywne wsparcie WebP i AVIF przez Hummingbird, co daje około 40% szybsze wczytywanie bez dodatkowych pluginów.
Jeszcze jedno: wyłącz zbędne moduły statystyk w panelu. Stare moduły potrafiły generować dziesiątki zapytań SQL i blokować połączenia MySQL. Higiena modułów to temat na osobny rozdział, ale już samo ich przejrzenie i wyłączenie nieużywanych funkcji potrafi odciążyć bazę.
Baza danych i moduły: porządek, który skraca TTFB
TTFB to skrót od Time To First Byte, czyli moment, kiedy serwer zaczyna odpowiadać na zapytanie. I właśnie tutaj baza danych ma największy wpływ. Jeśli każde otwarcie strony generuje 150 zapytań SQL, z których kilka trwa po 200ms, liczby się nie zgadzają.
Profilowanie SQL i szybkie wygrane
Włącz PrestaShop Profiler w trybie deweloperskim (zaawansowane parametry → wydajność). Od razu zobaczysz, które zapytania zajmują najwięcej czasu. Szukaj SELECT z wieloma JOIN-ami, zapytań wykonywanych 20+ razy na jednej stronie albo tych bez odpowiednich indeksów. Profilowanie pokazuje też całkowitą liczbę zapytań, a wszystko powyżej 100 na stronę główną to już za dużo. Z tym można coś zrobić.
Czyszczenie, indeksy i moduły do weryfikacji
Oto co warto sprawdzić w pierwszej kolejności:
| Tabela | Problem | Działanie |
|---|---|---|
| ps_connections | Miliony starych wpisów | CRON co tydzień, pruning |
| ps_page_viewed | Rośnie bez kontroli | Archiwum + wyłączenie |
| ps_guest | Setki tysięcy gości | Rotacja co 30 dni |
| ps_log_* | Wszystkie logi | Przegląd i czyszczenie |
Indeksy dorzuć do kolumn używanych w WHERE i JOIN (id_product, id_category, active). Moduły statystyk PrestaShop to historycznie problem, potrafiły zostawiać otwarte połączenia MySQL. Ciężkie filtry warstwowe też, szczególnie stare. Wyłącz to, czego nie używasz aktywnie.
Jeszcze jedno: MariaDB 10.4+ lokalnie na serwerze (nie zdalne połączenie) to standard. Opóźnienie sieciowe do zdalnej bazy potrafi dodać 20-50ms do każdego zapytania, więc lokalna baza zawsze wygrywa.
Front‑end i multimedia: WebP/AVIF, CDN i Core Web Vitals
Obrazy bez balastu: WebP/AVIF i lazy loading
Serwer może być szybki jak błyskawica, ale jeśli slider na głównej waży 3 MB, użytkownik i tak będzie czekał. Tak działa front‑end, kończy wyścig, który backend rozpoczął.
PrestaShop 8 i 9 wspierają WebP, a nawet AVIF (jeszcze lepszy format). Konwersja z JPEG/PNG to oszczędność 50-70% wagi przy tej samej jakości. Plus lazy loading dla obrazów poniżej zakładki, żeby przeglądarka nie ładowała wszystkiego od razu. Iframy z filmami? Też lazy. Tylko kluczowe grafiki hero powinny mieć atrybutpreload, reszta może poczekać, aż użytkownik zescrolluje.
Krytyczny CSS warto wyodrębnić inline, resztę załadować asynchronicznie. JavaScript?defer albo async, żeby nie blokował renderowania. Kompresja GZIP to minimum, Brotli jeszcze lepsze (oszczędza kolejne 15-20%). HTTP/2 multiplex redukuje liczbę połączeń, więc zasoby lecą szybciej.
CDN i mobilne Core Web Vitals
Cloudflare albo podobny CDN skraca czas odpowiedzi dla użytkowników mobilnych nawet o 35%. Dlaczego? Bo dane lecą z najbliższego serwera brzegowego, nie z Warszawy do kogoś w Gdańsku przez przeciążony węzeł. Plus filtracja botów oszczędza transfer i obciążenie serwera.
Cel LCP: <2,5 s (Largest Contentful Paint)
Optymalizacja front‑endu stabilizuje Core Web Vitals, czyli metryki Google, które wpływają na pozycję w wynikach. LCP poniżej 2,5 sekundy, CLS bliski zera (brak przeskoków layoutu), FID szybki. To wszystko razem daje lepsze UX i wyższe konwersje, niezależnie od tego, co dzieje się po stronie PHP.
Plan utrzymania: monitoring, testy A/B i bezpieczne wdrożenia
Wydajność to nie jest jednorazowy projekt. Przeprowadzisz optymalizacje, wszystko leci, PageSpeed pokazuje zieleń… a po tygodniu ktoś wgra nowy moduł, coś się sypnie, i znów wracasz do punktu wyjścia. Żeby tego uniknąć, potrzebujesz regularnego rytmu pomiarów i bezpiecznych procedur wdrożeniowych.
Rytm pomiarów i wskaźniki, które zapisujesz
Co tydzień (albo po każdym większym wdrożeniu) warto uruchomić szybki test w PageSpeed Insights, GTmetrix czy Pingdom. Wybierz 2-3 narzędzia i trzymaj się ich konsekwentnie. Ważniejsze od samego wyniku są trendy: czy TTFB rośnie, czy LCP się pogarsza, czy rozmiar strony nagle podskoczył o 400 KB.
Trzymaj prosty arkusz z kolumnami:
| Data | TTFB (s) | LCP (s) | Rozmiar (MB) | Zapytania |
|---|---|---|---|---|
| 12.01 | 0,8 | 2,1 | 1,2 | 48 |
| 19.01 | 0,9 | 2,4 | 1,5 | 52 |
Jeśli coś skoczy, wiesz, kiedy szukać przyczyny. Często to nowy moduł albo zaktualizowany plugin, który dodał 10 skryptów do head.
Staging, rollback i testy A/B
Każda zmiana (nowy moduł, upgrade PrestaShop do wersji 9.x, zmiana ustawień cache) najpierw ląduje na kopii produkcyjnej. Testujesz tam wpływ na wydajność i dopiero potem wgrywasz na live. Rollback plan to nie paranoja, to higiena: masz backup bazy i plików sprzed wdrożenia, żeby w razie czego wrócić w 5 minut.
Testy A/B? Idealnie sprawdzają się przy cache. Włączasz pełno-stronicowe cache dla połowy ruchu, mierzysz konwersję i czas ładowania przez tydzień, porównujesz. Podobnie z CDN: Cloudflare ogranicza boty i oszczędza transfer, co stabilizuje TTFB nawet przy większym ruchu. Co ważne, pilnuj zgodności: PHP 8.1+ i MariaDB 10+ to minimum dla nowszych wersji PS.
Szybkość jako przewaga: sklep, który nie zwalnia tempa
Wolny sklep to jak kolejka w sklepie stacjonarnym, gdzie kasjerka sprawdza cenę każdego produktu ręcznie. Klienci po prostu odchodzą do konkurencji, która działa sprawniej. W e-commerce ta zasada jest jeszcze bardziej brutalna, bo alternatywa to dosłownie jeden klik. Nie chodzi tu o perfekcję techniczną, tylko o zdrowy rozsądek biznesowy.
Jeśli twój PrestaShop ładuje się ponad 3 sekundy, tracisz pieniądze. Konkretne, policzalne pieniądze. Serwer to fundament, na którym stoi cała reszta optymalizacji. Możesz mieć najlepszy design i świetne produkty, ale kiepski hosting zniweczy każdy wysiłek.
Dobra wiadomość? Większość problemów z szybkością da się naprawić bez przepisywania sklepu od zera. Wystarczy zrozumieć, gdzie leży problem i zabrać się za niego systematycznie.
Potrzebujesz profesjonalisty i doradztwa w wyborze serwera dla Prestashop? Zapraszam do kontaktu!
