Optymalizacja PrestaShop — jak przyspieszyć sklep i poprawić konwersję
Wolny sklep PrestaShop to mniej sprzedaży i gorsze pozycje w Google. Sprawdź, co realnie przyspiesza ładowanie — od konfiguracji serwera i PHP przez cache i obrazy po bazę danych i Core Web Vitals. Artykuł z perspektywy software house, nie generycznych porad hostingowych.
Optymalizacja PrestaShop to nie włączenie jednego modułu cache i zapomnenie o temacie. To układ wielu warstw: fizyczny serwer, wersja PHP, konfiguracja OPcache, liczba i jakość aktywnych modułów, rozmiar i format obrazów, struktura szablonu, stan bazy danych oraz konfiguracja sieci dostarczania treści. Każda z tych warstw może być wąskim gardłem — a szukanie wąskiego gardła bez pomiaru to przepalanie budżetu.
Z perspektywy software house pracującego przy kilkudziesięciu sklepach PrestaShop rocznie widzimy ten sam schemat: właściciel sklepu kupuje moduł cache za 80 zł, TTFB spada o 50 ms, a wolny serwer shared z 256 MB RAM na PHP 7.4 pozostaje niezmieniony. Piszemy ten artykuł, żeby pokazać, w jakiej kolejności realnie działamy przy optymalizacji — i dlaczego kolejność ma znaczenie.
Dlaczego wolny sklep to problem biznesowy, nie techniczny
Google potwierdza: prawdopodobieństwo odrzucenia sesji rośnie o 32% gdy czas ładowania wydłuża się z 1 do 3 sekund, a przy 5 sekundach — już o 90%. W kampaniach Google Ads i Meta Ads płacisz za każde kliknięcie. Jeśli strona docelowa ładuje się 6 sekund na mobile, znaczna część ruchu odpada zanim zobaczy produkt. Core Web Vitals bezpośrednio wpływają na ranking w wyszukiwarce — w szczególności LCP i CLS, które Google mierzy w terenie (field data), nie tylko w laboratorium.
Zanim zaczniesz optymalizację: co zmierzyć
Zanim dotkniesz konfiguracji serwera czy szablonu, zrób pomiary. Optymalizacja bez danych bazowych jest jak leczenie bez diagnozy — możesz przypadkowo coś poprawić, ale nie wiesz co i o ile. Mierz zawsze te same URL-e: stronę główną, kategorię z filtrowaniem, kartę produktu i stronę koszyka.
PageSpeed Insights (pagespeed.web.dev) — uruchom dla mobile i desktop osobno, zapisz wyniki LCP, INP, CLS oraz TBT.
Lighthouse w trybie deweloperskim Chrome — zakładka Performance, uruchom przy wyłączonych rozszerzeniach i w trybie incognito.
TTFB (Time to First Byte) w zakładce Network przeglądarki — filtruj po typie Doc, sprawdź czas Waiting (TTFB) dla HTML strony.
WebPageTest.org — uruchom test z Frankfurtu lub Warszawy, Throttling: 4G, pobierz waterfall i HAR. Sprawdź, co blokuje render.
Search Console → Core Web Vitals — jakie URL-e mają status „Poor” i „Needs improvement” według danych z urządzeń realnych użytkowników.
Chrome UX Report (CrUX Dashboard) lub PageSpeed Insights w sekcji Field Data — dane z 28 ostatnich dni.
Krok 1Hosting i serwer — fundament bez którego reszta nic nie da
Hosting to fundament. Tani shared hosting z setkami klientów na jednym serwerze fizycznym może dawać TTFB 1–3 s nawet przy pustej stronie. Żaden moduł cache nie zastąpi wydajnego serwera — cache skraca czas generowania HTML, ale HTML musi jeszcze dotrzeć do przeglądarki przez sieć i serwer.
W projektach PrestaShop rekomendujemy minimum: VPS z 2 vCPU i 2 GB RAM lub hosting zarządzany zoptymalizowany pod PHP (np. Cloudways, Kinsta, SiteGround Business lub dedykowany hosting PrestaShop). Kluczowe jest to, żeby TTFB na pustej stronie (bez cache) wynosiło mniej niż 600 ms — jeśli jest wyższy, problem leży w infrastrukturze, nie w kodzie.
Wymagania serwerowe dla sklepu PrestaShop 8.x w dobrej konfiguracji:
PHP 8.2 lub 8.3 (PHP 8.1 jest EOS w grudniu 2025, PHP 7.x jest krytycznie przestarzały i kilkukrotnie wolniejszy).
MySQL 8.0+ lub MariaDB 10.11+ z innoDB jako domyślnym silnikiem i odpowiednim rozmiarem innodb_buffer_pool_size (min. 256 MB dla małego sklepu, 1 GB+ dla katalogów 10k+ produktów).
OPcache włączony z opcache.memory_consumption >= 256 MB i opcache.validate_timestamps=0 na produkcji.
HTTP/2 lub HTTP/3 (QUIC) — weryfikuj w nagłówkach response, klucz dla równoległego ładowania zasobów.
Dysk SSD NVMe — nie HDD, nie SATA SSD. Różnica w I/O dla operacji bazodanowych i plików tymczasowych jest ogromna.
Serwer w Europie, najlepiej Niemcy lub Polska — każde 100 ms RTT to 100 ms do każdego zasobu.
Gzip lub Brotli kompresja odpowiedzi HTTP — HTML, CSS, JS powinny być kompresowane.
Krok 2Konfiguracja PHP — OPcache, limity i rozszerzenia
PHP ma ogromny wpływ na wydajność PrestaShop. Każde żądanie bez OPcache powoduje ponowne parsowanie i kompilację plików PHP — a PrestaShop to kilkaset plików PHP na jedno żądanie. OPcache cache'uje skompilowany bytecode w pamięci, eliminując tę pracę przy kolejnych żądaniach.
Optymalna konfiguracja PHP dla PrestaShop 8.x w pliku php.ini lub przez panel hostingu:
memory_limit = 512M (dla multistore lub dużego katalogu rozważ 1G).
max_execution_time = 300 (wyższy limit dla importów i zadań cron).
opcache.enable = 1
opcache.memory_consumption = 256 (w MB).
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000 (PrestaShop ma dużo plików).
opcache.validate_timestamps = 0 (na produkcji — przyspiesza, ale wymaga ręcznego czyszczenia po deployu).
opcache.revalidate_freq = 0 (razem z validate_timestamps=0).
opcache.jit = 1255 i opcache.jit_buffer_size = 64M (PHP 8.x JIT, szczególnie efektywny dla operacji obliczeniowych w modułach).
realpath_cache_size = 4096K i realpath_cache_ttl = 120 — zmniejsza liczbę operacji stat() na systemie plików.
Sprawdź aktywne rozszerzenia PHP. PrestaShop wymaga: curl, gd lub imagick, intl, mbstring, openssl, pdo_mysql, xml, zip. Rozszerzenia których nie używasz (np. xdebug na produkcji — to krytyczny błąd wydajnościowy, xdebug może spowalniać PHP o 2–5x) powinny być wyłączone.
Krok 3Audit modułów — każdy moduł to koszt
Moduły to najczęstsze, najgroźniejsze i najtrudniejsze do wykrycia źródło problemów z wydajnością PrestaShop. Każdy aktywny moduł może dokładać zapytania SQL, ładować własne pliki CSS i JavaScript, rejestrować hooki które uruchamiają się na każdej stronie, oraz zwiększać zużycie pamięci PHP.
W sklepach, które rozwijają się kilka lat, spotykamy regularnie 60–120 aktywnych modułów. Wiele z nich to moduły zainstalowane do jednorazowego zadania (import, eksport, konwersja danych) i nigdy niewyłączone, moduły z kupionego szablonu których nie używasz, oraz zduplikowane funkcje realizowane przez kilka modułów jednocześnie.
Jak przeprowadzić audit modułów:
Włącz Symfony Profiler lub moduł deweloperski PrestaShop i sprawdź liczbę zapytań SQL na stronach: główna, kategoria, produkt. Norma: poniżej 50 zapytań. Powyżej 100 — problem.
Przejrzyj Back Office → Moduły → Zainstalowane — segreguj na: aktywne i potrzebne, aktywne i zbędne, nieaktywne (odinstaluj lub usuń).
Dla każdego modułu JavaScript sprawdź: czy skrypt ładuje się na każdej stronie (globalnie) czy tylko tam gdzie jest potrzebny? Moduł live chat, Google Analytics, popupy — czy są odroczane czy blokują render?
Używaj Network Throttling w DevTools i sprawdzaj Waterfall — które zewnętrzne skrypty i piksele śledzące blokują interaktywność strony.
Moduły statystyk wbudowane w PS (np. ps_statsvisits, ps_statssales) generują duże tabele w bazie. Jeśli używasz zewnętrznego GA/GTM — możesz je wyłączyć i wyczyścić tabele.
Slidery na stronie głównej (Nivo Slider, Revolution Slider, moduł slidera z szablonu) to zwykle 100–300 KB JavaScript + CSS. Jeśli slider ma 5 slajdów ze zdjęciami 1600px — to kolejne 2–4 MB obrazów ładowanych przy starcie.
Odraczanie i ładowanie warunkowe skryptów modułów
PrestaShop nie ma natywnego mechanizmu ładowania skryptów modułów tylko na wybranych stronach — moduł musi to sam obsługiwać przez hookContextualAssetsAlter lub sprawdzenie kontrolera. Jeśli modułu nie możesz zmienić, możesz dodać filtr w szablonie lub przez override, który usuwa skrypt na stronach gdzie nie jest potrzebny. To technicznie wymagające, ale możliwe bez modyfikacji modułu — przez Child Theme lub override `BlockCarrierStep.php`.
PrestaShop ma kilka warstw cache wbudowanego. Zrozumienie ich różnic jest kluczowe — włączenie złego cache może nie pomóc wcale albo spowodować błędy wyświetlania nieaktualnych danych.
Smarty Cache: cache skompilowanych szablonów Smarty. Włącz w Back Office → Wydajność → Smarty → Cache template — opcja 'Recompile templates if the files have been updated' na produkcji powinna być wyłączona (opcja 'Never recompile'). To eliminuje operacje file stat przy każdym żądaniu.
Cache modułów (CCC — Combine, Compress, Cache): w Back Office → Wydajność włącz Combine i Compress dla CSS i JavaScript. Zanim włączysz — przetestuj na dev, bo część starszych modułów ma błędy przy minifikacji.
Zewnętrzne backend'y cache dla PrestaShop:
Memcached lub Redis jako backend dla ps_cache — przechowuje skompilowane zapytania, adresy URL i inne obiekty w pamięci RAM zamiast na dysku. Redis jest lepszym wyborem (trwałość, struktury danych, replikacja).
Page Cache (pełna strona): PrestaShop nie ma wbudowanego pełnego page cache jak WordPress. Możesz go dodać przez LiteSpeed Cache (jeśli hosting obsługuje LiteSpeed), Nginx FastCGI cache po stronie serwera, lub zewnętrzny CDN z cache HTML (Cloudflare APO, Fastly).
Varnish Cache: zaawansowany reverse proxy cache, bardzo efektywny przy dużym ruchu. Wymaga konfiguracji VCL i uwzględnienia ciasteczek koszyka i sesji — nie możesz cache'ować stron z aktywną sesją użytkownika.
Pamiętaj o inwalidacji cache po zmianie produktów, cen i promocji — bez automatycznej inwalidacji klienci będą widzieć nieaktualne dane.
Uwaga na konfigurację Debug Mode w PrestaShop. Jeśli Debug Mode jest włączony na produkcji (Back Office → Wydajność → Debug mode), każde żądanie generuje dodatkowe dane i wyłącza cache. Sprawdź czy flaga PS_MODE_DEV jest false w bazie lub przez panel.
Krok 5Optymalizacja obrazów — WebP, lazy loading i prawidłowe rozmiary
Obrazy są najczęściej największym niezoptymalizowanym zasobem w sklepach PrestaShop. Główny obraz produktu 2000×2000 px jako JPEG 800 KB ładowany na karcie produktu gdzie wyświetlany jest w 600×600 px to błąd, który kosztuje sekundy LCP i megabajty transferu na mobile.
PrestaShop generuje automatycznie miniatury w zdefiniowanych rozmiarach (Back Office → Preferencje → Obrazy). Skonfiguruj właściwe rozmiary dla każdego kontekstu: lista produktów w kategorii, karta produktu, koszyk, miniaturki w wyszukiwarce. Nie twórz 10 rozmiarów gdy używasz 3.
Konwersja do WebP i AVIF:
PrestaShop 8.x obsługuje WebP natywnie przy użyciu Imagick lub GD — włącz w Back Office → Preferencje → Obrazy → Generate images in WebP format.
Jeśli masz starą wersję bez natywnej obsługi WebP, użyj modułu (np. WebP by Make it Biz) lub przeprowadź konwersję batch w CLI: `for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done`.
AVIF daje jeszcze lepszą kompresję niż WebP (szczególnie przy małych obrazach), ale generowanie jest wolniejsze i wymaga Imagick 7.0.7+. Dla większości sklepów WebP z fallback do JPEG jest wystarczające.
Lazy loading dla obrazów poza viewport: dodaj `loading="lazy"` do tagów <img> w szablonie dla miniatur w listach kategorii, powiązanych produktów i blokach na stronie głównej. Obraz główny na stronie produktu (LCP) NIE powinien mieć lazy loading.
Atrybut `fetchpriority="high"` dla obrazu LCP — główne zdjęcie produktu lub baner hero na stronie głównej. Informuje przeglądarkę, że ma priorytetowo pobrać ten zasób.
Sprawdź EXIF i metadane: nowe zdjęcia z iPhone mogą mieć EXIF z danymi GPS, profilami ICC (kilkadziesiąt KB samych metadanych). Strip metadata przy konwersji: `convert input.jpg -strip output.jpg`.
Responsive images (srcset): PrestaShop nie generuje srcset automatycznie dla wszystkich kontekstów. Dla głównego obrazu produktu i banera hero warto dodać ręcznie lub przez override szablonu.
Grafiki SVG i ikony — alternatywa dla sprite'ów
Ikony ładowane jako osobne PNG (10–20 żądań HTTP po 2–10 KB każde) to stary problem. Inline SVG lub SVG sprite eliminuje żądania sieciowe. Jeśli szablon używa FontAwesome lub innego zestawu ikon — sprawdź czy ładujesz cały zestaw (700 KB) dla 10 ikon. Możesz wyciąć tylko używane ikony przez tree-shaking lub użyć Heroicons/Material Symbols w wersji SVG.
Krok 6Optymalizacja bazy danych MySQL/MariaDB
Baza danych to drugie, po hostingu, najbardziej zaniedbywane obszar optymalizacji PrestaShop. Przez lata działania sklep akumuluje: dziesiątki milionów rekordów w tabelach logów (ps_log, ps_statssearch, ps_connections, ps_connections_page, ps_connections_source), logi zadań cron (ps_import_data, tabele modułów), historię e-maili (ps_mail_message), oraz porzucone koszyki i tabele modułów które odinstalowałeś ale ich tabele zostały.
Czyszczenie nieużywanych danych w bezpieczny sposób:
Back Office → Zaawansowane → Baza danych → Optymalizacja tabel MySQL — uruchom analizę i optymalizację. Odbudowuje indeksy i fragmentację.
Back Office → Zaawansowane → Baza danych → Kopia baza danych — zawsze backup przed czyszczeniem.
Usuń stare statystyki: `TRUNCATE TABLE ps_connections; TRUNCATE TABLE ps_connections_page; TRUNCATE TABLE ps_connections_source; TRUNCATE TABLE ps_statssearch;` — te tabele często mają miliony rekordów i spowalniają całą instancję MySQL.
Porzucone koszyki: `DELETE FROM ps_cart WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH);` — przed tym sprawdź czy masz jakiekolwiek integracje marketingowe bazujące na porzuconych koszykach.
OPTIMIZE TABLE dla największych tabel: `OPTIMIZE TABLE ps_product_lang, ps_category_product, ps_search_index;` — odbudowuje strukturę i odzyskuje miejsce po DELETE.
Slow Query Log: włącz `slow_query_log = 1` i `long_query_time = 1` w konfiguracji MySQL na czas diagnozy. Przeanalizuj wynik przez pt-query-digest (Percona Toolkit) — znajdziesz zapytania których nie podejrzewasz.
Indeksy bazy danych: PrestaShop ma dobre indeksy na standardowych tabelach, ale moduły deweloperów trzecich często tworzą tabele bez indeksów. Zapytanie SELECT na tabeli z 2 milionami rekordów bez indeksu wykonuje się 100× wolniej niż z indeksem. Narzędziem do analizy jest `EXPLAIN SELECT ...` — jeśli widzisz `type: ALL` (full table scan) na dużej tabeli, brakuje indeksu.
Krok 7Minifikacja i łączenie CSS/JS — CCC i zaawansowane techniki
Combine, Compress, Cache (CCC) w PrestaShop (Back Office → Wydajność) to podstawowe narzędzie do redukcji liczby żądań HTTP i rozmiaru CSS/JS. Włącz kompresję i łączenie dla CSS i JavaScript osobno — najpierw CSS, przetestuj, potem JS.
Zachowaj ostrożność przy JS — niektóre moduły mają skrypty z błędami po minifikacji lub zakładają określoną kolejność ładowania. Testuj na środowisku staging.
Co zrobić gdy CCC nie wystarcza:
Defer/Async dla skryptów zewnętrznych: Google Tag Manager, Facebook Pixel, Hotjar, czaty — dodaj `defer` lub `async` przez hookActionFrontControllerSetMedia lub moduł Google Tag Manager.
Preload dla kluczowych zasobów: font (woff2), CSS global, główny obraz LCP — dodaj `<link rel="preload">` w <head> szablonu. Przeglądarka pobierze je wcześniej nie czekając na parsowanie HTML.
Preconnect dla zewnętrznych domen: Google Fonts, CDN, API zewnętrzne — `<link rel="preconnect" href="https://fonts.googleapis.com">`. Eliminuje koszt DNS + TLS handshake przy pierwszym żądaniu do danej domeny.
Resource Hints: `<link rel="dns-prefetch">` dla domen gdzie nie możesz użyć preconnect (np. domen analytics ładowanych po scroll).
Critical CSS: wyodrębnij CSS potrzebny do wyrenderowania widocznej części strony (above the fold) i wstaw go inline w <head>. Resztę CSS ładuj asynchronicznie przez `<link rel="preload" as="style">`. Narzędzia: critical (npm), penthouse.js. To zaawansowane, ale eliminuje render-blocking CSS.
Usuń nieużywany CSS: PostCSS PurgeCSS lub moduł który analizuje użyte selektory. Szczególnie skuteczne dla szablonów Bootstrap gdzie używasz 10% klas.
Krok 8CDN — Content Delivery Network dla sklepu PrestaShop
CDN serwuje statyczne zasoby (obrazy, CSS, JS, fonty) z serwerów edge rozproszonych geograficznie. Zamiast każdego żądania trafiającego do Twojego serwera w Niemczech, użytkownik z Gdańska pobiera obrazy z node'a CDN w Warszawie lub Berlinie — czas odpowiedzi spada drastycznie dla zasobów statycznych.
CDN dla PrestaShop: konfiguracja i opcje:
Cloudflare (Free/Pro/Business): najprostszy start — zmień NS na Cloudflare, w kilka minut masz CDN + DDoS protection + HTTP/3 + Brotli. Free tier wystarczy dla większości sklepów do ~50k unikalnych wizyt/miesiąc.
Cloudflare w trybie proxy (Proxied, pomarańczowa chmurka): cały ruch przechodzi przez Cloudflare. Włącz: Auto Minify (HTML/CSS/JS), Brotli compression, Rocket Loader (uważaj — może powodować błędy JS, testuj), HTTP/3.
Cloudflare Page Rules lub Transform Rules: możesz ustawić agresywny cache dla zasobów statycznych (obrazy, CSS, JS z haszem w URL) z TTL 1 rok, wyłączyć cache dla stron koszyka i checkout.
BunnyCDN, KeyCDN: tańsze alternatywy do serwowania samych assetów statycznych (pull zone). Konfiguracja w PrestaShop: Back Office → Wydajność → Multimedia → Media Server URL.
Amazon CloudFront: enterprise opcja z integracją AWS. Sensowne przy dużym ruchu i istniejącej infrastrukturze AWS.
ImageKit lub Cloudinary: specjalistyczne CDN z automatyczną konwersją formatów (WebP/AVIF on-the-fly), resizingiem po URL i lazy loading. Eliminuje problem formatów obrazów bez zmian w PrestaShop.
Przy wdrożeniu CDN przetestuj: czy koszyk i checkout działają poprawnie (ciasteczka sesji nie powinny być cache'owane), czy strony z ceną w PLN i promocjami nie są cache'owane błędnie dla różnych użytkowników, czy certyfikat SSL działa poprawnie przez proxy CDN.
Krok 9Optymalizacja szablonu i frontendu
Szablon PrestaShop (motyw) ma ogromny wpływ na wydajność frontendu. Popularne premium motywy (TheDress, Warehouse, Leo Apparis itp.) są rozbudowane i mają wbudowane slidery, mega menu, liczniki, moduły AJAX i zaawansowane animacje — każda z tych funkcji kosztuje czas ładowania.
Audyt szablonu — od czego zacząć:
Sprawdź ile fontów ładuje szablon. Jeden font z 4 wagami to minimum 4 żądania HTTP + 80–200 KB transferu. Ogranicz do 1–2 fontów, 2–3 wag. Użyj `font-display: swap` żeby tekst był widoczny podczas ładowania fontu.
Sprawdź JavaScript w <head>: każdy skrypt bez `defer` lub `async` blokuje parsowanie HTML i opóźnia FCP/LCP. Przenieś niestandardowe skrypty na koniec <body> lub dodaj defer.
Mega menu z rozbudowanymi animacjami CSS: często kilkadziesiąt KB CSS i JS tylko dla menu. Jeśli masz prostą strukturę kategorii — uproszczone menu to kilkakrotnie mniej kodu.
Animacje on-scroll (AOS, WOW.js, GSAP w szablonie): każda animacja to JS i obliczenia w main thread. Szanuj prefers-reduced-motion. Jeśli animacje nie wspierają biznesowo konwersji — usuń.
Czcionki Google Fonts: zamiast zewnętrznego żądania do fonts.googleapis.com, hostuj fonty samodzielnie. Narzędzie google-webfonts-helper generuje pliki i CSS do self-hostingu. Eliminuje zewnętrzne połączenie i ryzyko GDPR.
HTML inline CSS: szablony często generują styl `style="..."` bezpośrednio w tagach HTML dla dynamicznych kolorów czy rozmiarów. To zwiększa rozmiar HTML i utrudnia cache'owanie.
DOM size: Google zaleca mniej niż 1400 elementów DOM. Strona produktu z rozbudowanym szablonem, mega menu i wieloma modułami bocznymi może mieć 3000–5000 elementów. Duży DOM spowalnia rendering i interaktywność.
Krok 10Core Web Vitals — LCP, INP i CLS w praktyce PrestaShop
Core Web Vitals to trzy metryki które Google mierzy i używa jako sygnał rankingowy. Nie wystarczy je przeczytać z Lighthouse — liczy się Field Data z realnych użytkowników, raportowane w Search Console i PageSpeed Insights.
LCP (Largest Contentful Paint) — główny kandydat do optymalizacji:
Zidentyfikuj co jest elementem LCP na każdej strategicznie ważnej stronie (PSI pokaże Ci element w zakładce Diagnostics). Najczęściej: główne zdjęcie produktu, baner hero, duże logo.
Dla obrazu LCP: użyj `fetchpriority="high"`, usuń `loading="lazy"`, upewnij się że jest w formacie WebP, odpowiednio skompresowany i servowany z CDN lub LiteSpeed cache.
Jeśli LCP to tekst (np. nagłówek H1 na stronie kategorii): upewnij się że font jest preloadowany (`<link rel="preload" as="font">`) lub że strona używa system font stack jako fallback z `font-display: swap`.
TTFB wpływa na LCP — każda milisekunda opóźnienia serwera to milisekunda dodana do LCP. Dlatego serwer i cache są pierwszym krokiem.
INP (Interaction to Next Paint) — poprzednia metryka FID mierzyła tylko pierwsze kliknięcie, INP mierzy responsywność przez całą wizytę. W PrestaShop problem z INP najczęściej pochodzi z: ciężkich event listenerów w modułach AJAX (dodanie do koszyka, zmiana wariantu produktu), dużych zestawów JavaScript inicjalizowanych przy starcie (slidery, galerie), oraz długich zadań w main thread blokujących odpowiedź na interakcje użytkownika.
CLS (Cumulative Layout Shift) — nagłe przesunięcia elementów podczas ładowania strony. W PrestaShop najczęstsze przyczyny: obrazy produktów bez atrybutów width/height (przeglądarka nie zna rozmiaru przed załadowaniem i nie rezerwuje miejsca), banery reklamowe ładowane asynchronicznie które pojawiają się w połowie treści, web fonts powodujące FOUT (flash of unstyled text) z innym rozmiarem niż fallback font.
Krok 11TTFB — Time to First Byte i generowanie HTML po stronie serwera
TTFB (Time to First Byte) to czas od wysłania żądania HTTP do odebrania pierwszego bajtu odpowiedzi. Składa się z: czasu DNS, czasu połączenia TCP+TLS, oraz czasu przetwarzania przez serwer (PHP generujące HTML). Dla sklepów PrestaShop bez page cache, TTFB odzwierciedla czas generowania strony przez PHP — od kilkudziesięciu milisekund na dobrym serwerze do 3–5 sekund na słabym shared hostingu z dużym katalogiem.
Jak analizować TTFB:
Chrome DevTools → Network → kliknij na główny dokument HTML → zakładka Timing. Czas „Waiting (TTFB)” — wszystko powyżej 600 ms wymaga zbadania.
Przetestuj TTFB dla zalogowanego i niezalogowanego użytkownika osobno — zalogowany użytkownik ma aktywną sesję i nie może korzystać z page cache.
Porównaj TTFB z cache i bez cache (dodaj ?nocache=1 lub tymczasowo wyłącz cache w BO) — różnica pokaże ile cache faktycznie pomaga.
Przetestuj TTFB z bliska (Polska) i zdalnie (WebPageTest z Frankfurtu) — różnica to RTT sieci, nie czas serwera.
MySQL slow queries: włącz slow_query_log i zbierz przez 24h na produkcji. Często jedno zapytanie z modułu blokującego całe PHP to TTFB 1–2 s.
PHP-FPM pool config: zbyt małe pm.max_children blokuje kolejne żądania gdy wszystkie procesy są zajęte. Objawy: TTFB nagle skacze przy wyższym ruchu.
Jeśli TTFB > 600 ms bez cache, mimo dobrego serwera — użyj Blackfire.io lub Tideways do profilowania PHP. Znajdziesz dokładną funkcję i linię kodu która spowalnia generowanie strony.
Krok 12Monitoring i pomiary po wdrożeniu
Optymalizacja bez monitoringu to akcja jednorazowa. Po wdrożeniu zmian ustaw system który będzie alertować gdy wydajność spadnie — nowa wersja modułu, aktualizacja PrestaShop, flash sprzedaż z dużym ruchem, czy po prostu rosnący katalog produktów mogą cofnąć postępy.
Zestaw narzędzi monitoringu:
Google Search Console → Core Web Vitals: sprawdzaj cotygodniowo. Alert gdy strony przechodzą do „Needs Improvement” lub „Poor”.
PageSpeed Insights API: możesz automatycznie odpytywać API (bezpłatne) i śledzić trendy LCP/CLS/INP dla kluczowych URL-i. Dodaj do dashboardu lub Grafana.
Uptime monitoring: UptimeRobot (bezpłatny) lub Better Uptime — alert gdy strona zwraca błąd lub TTFB przekracza próg.
New Relic APM lub Datadog APM: pełny monitoring aplikacji PHP — czasy odpowiedzi, wolne transakcje, błędy, anomalie. Sensowne przy sklepach z wyższym ruchem (10k+ wizyt dziennie).
Sentry: monitorowanie błędów JavaScript i PHP. Jeśli po optymalizacji JavaScript pojawią się błędy w produkcji (np. przez minifikację CCC), Sentry je natychmiast wychwytuje.
Wiele problemów wydajnościowych wynika z używania przestarzałych wersji PrestaShop. PHP 7.4 z PS 1.7.x to technologia kilka lat za aktualnym standardem — brak JIT, wolniejszy GC, brak nowych optymalizacji w samym frameworku. Jeśli nie jesteś jeszcze na PS 8.x — przeczytaj nasz artykuł o aktualizacji PrestaShop 1.7 do 9, który omawia ryzyko i kroki migracji. Aktualizacja i optymalizacja to często jedno zadanie realizowane razem w ramach naszego serwisu technicznego PrestaShop.
Wydajność a SEO — połączone naczynia
Core Web Vitals to jeden z sygnałów rankingowych Google, ale wydajność wpływa na SEO szerzej — przez czas ładowania podczas crawlowania (Googlebot ma limitowany crawl budget), liczbę stron indeksowanych podczas sesji crawla, oraz pośrednio przez współczynnik odrzuceń i głębokość sesji. Po optymalizacji technicznej, naturalnym kolejnym krokiem jest domknięcie SEO PrestaShop — metadane, dane strukturalne, kanonikalizacja filtrów kategorii, mapy witryn i linkowanie wewnętrzne. Jeśli chcesz kompleksowego podejścia — oferujemy je w ramach SXO i optymalizacji konwersji, gdzie łączymy wydajność techniczną z UX i konwersją.
Kiedy samodzielna optymalizacja nie wystarczy
Istnieje klasa problemów wydajnościowych, które właściciel sklepu może naprawić samodzielnie: włączenie cache w panelu, wyłączenie nieużywanych modułów, zmiana hostingu, konwersja obrazów do WebP. Ale jest też klasa problemów, które wymagają developera PrestaShop: niestandardowy moduł z nieefektywnymi zapytaniami SQL, szablon z render-blocking JavaScript zakodowanym na stałe, integracja ERP generująca martwy kod SQL przy każdym żądaniu, multistore z błędną konfiguracją cache.
Jeśli TTFB pozostaje wysoki po zmianie hostingu i konfiguracji PHP — problem leży w kodzie i wymaga profilowania developerskiego. Dokładną diagnozę przeprowadzamy w ramach naszego audytu technicznego sklepu. Wynikiem jest pisemny raport z priorytetyzowaną listą problemów i szacunkami czasu naprawy, na podstawie którego możesz działać sam lub zlecić nam implementację. Zakres i koszt każdego projektu opisujemy wstępnie na stronie cennika lub po krótkim briefingu — skontaktuj się z nami.
Podsumowanie: kolejność działań przy optymalizacji PrestaShop
Zmierz: PSI, TTFB, Waterfall, Search Console Core Web Vitals. Zapisz wyniki bazowe.
Hosting i PHP: wersja PHP 8.2+, OPcache, SSD NVMe, HTTP/2, odpowiednia pamięć RAM. Jeśli TTFB > 600 ms — to tu jest problem.
Audit i cięcie modułów: wyłącz zbędne, sprawdź liczbę zapytań SQL, oddeferuj skrypty zewnętrzne.
Cache: Smarty cache, CCC (Combine/Compress), Redis/Memcached backend jeśli dostępny. Na LiteSpeed — moduł LiteSpeed Cache.
Obrazy: WebP, właściwe rozmiary miniaturek, lazy loading poza LCP, fetchpriority dla LCP.
Baza danych: wyczyść logi i statystyki, OPTIMIZE TABLE, sprawdź slow queries.
Zmierz po każdej grupie zmian — nie wdrażaj wszystkiego na raz bez testowania.
optymalizacja prestashop
przyspieszenie sklepu
core web vitals
pagespeed prestashop
ttfb
wydajność e-commerce
cache prestashop
FAQ
Najczęściej zadawane pytania
Zakres i koszt zależy od stanu sklepu i problemów do naprawienia. Proste prace (konfiguracja cache, konwersja obrazów, audit modułów) to kilka godzin pracy. Pełny audyt techniczny z raportem — od kilkuset złotych. Wdrożenie zmian wymagających ingerencji w kod (moduły, szablon, integracje) to od kilku do kilkunastu dni roboczych. Wstępną wycenę podajemy po krótkim briefingu — zawsze po zapoznaniu się z konkretnym sklepem, nie z cennika szufladkowego.
Nie zawsze. Moduł cache (np. LiteSpeed Cache, PrestaShop Cache Block) skraca czas generowania HTML przez PHP — ale nie zastąpi słabego hostingu (gdzie TTFB jest wysoki z powodów sieciowych lub niedoboru RAM), ciężkich niezoptymalizowanych obrazów, czy nadmiarowych skryptów zewnętrznych blokujących render. Cache to jedno z narzędzi, nie rozwiązanie wszystkich problemów.
Wyniki PageSpeed Insights i TTFB widać natychmiast po wdrożeniu zmian. Na Core Web Vitals w Field Data (dane realne) efekt widać po 28 dniach — tyle wynosi okno danych CrUX. Na pozycje w wyszukiwarce efekt widać po kilku tygodniach, jeśli CWV były w stanie „Poor” i poprawiłeś je do „Good”. Sam techniczny CWV to jeden z wielu sygnałów rankingowych — bez dobrej treści i linków nie zdziała cudów.
Tak, ogromne. PHP 8.0 jest około 2× szybszy od PHP 7.0 w benchmarkach OPcache. PHP 8.1 i 8.2 dalej optymalizują Fibers, JIT i wewnętrzne struktury. Dla sklepu PrestaShop z kilkoma tysiącami produktów i kilkudziesięcioma modułami, aktualizacja PHP 7.4 → 8.2 może obniżyć TTFB o 30–50% bez żadnych innych zmian.
Jeśli TTFB na pustej stronie PrestaShop (z cache) przekracza 300–400 ms, a na zimno (bez cache) przekracza 1,5 s, hosting jest wąskim gardłem. Tani shared hosting z setkami klientów na serwerze często nie spełnia wymagań PrestaShop przy kilkuset produktach i kilkudziesięciu modułach. VPS z 2 GB RAM lub dobry hosting zarządzany pod PHP to realna poprawa. Zanim zmienisz hosting — zmierz TTFB z i bez cache, żeby wiedzieć czy problem jest w generowaniu HTML czy w sieci.
Najdokładniejsza metoda to profilowanie PHP przez Blackfire.io lub Tideways — widać dokładnie czas wykonania każdej funkcji i zapytania SQL. Prostsze podejście: włącz tryb deweloperski PrestaShop i Symfony Profiler, który pokazuje listę zapytań SQL i ich czas dla każdego żądania. Możesz też metodą bisekcji wyłączać moduły partiami i mierzyć TTFB przed i po — wolne, ale nie wymaga narzędzi zewnętrznych.
Zależy od diagnozy. Jeśli problem to TTFB (generowanie PHP) — szablon nie jest przyczyną i zmiany w szablonie nic nie dadzą. Jeśli problem to render-blocking JavaScript lub nieoptymalne ładowanie fontów w szablonie — tak, potrzebne są zmiany. Jeśli CLS wynika z braku atrybutów width/height na obrazach — tak, zmiany w szablonie są potrzebne. Dlatego zaczynamy od pomiaru, nie od założeń.
Każda aktualizacja modułu to ryzyko regresji wydajnościowej — nowa wersja może dodawać nowe zapytania SQL, nowe JS, nowe requesty HTTP. Wdrożenia przeprowadzamy na środowisku staging z pomiarem PSI przed i po. Na produkcję moduł idzie tylko po potwierdzeniu braku regresji wydajnościowej i funkcjonalnej. To wymaga środowiska staging i kultury testowania zmian przed wdrożeniem.
TTFB (Time to First Byte) to czas od wysłania żądania HTTP do odebrania pierwszego bajtu odpowiedzi od serwera. Odzwierciedla czas generowania strony przez PHP (zapytania SQL, logika aplikacji, cache) plus opóźnienie sieciowe. Wysoki TTFB podnosi LCP i wszystkie inne metryki wydajności — nic nie pomoże jeśli serwer potrzebuje 2 sekund na wygenerowanie HTML. Google zaleca TTFB < 800 ms, my dążymy do < 400 ms przy włączonym cache.
Nie jest konieczny do dobrego wyniku PSI, ale znacznie ułatwia uzyskanie niskich czasów ładowania dla użytkowników z całej Polski (i Europy). Cloudflare w bezpłatnym planie daje CDN, HTTP/3, Brotli i podstawową ochronę DDoS — i jest praktycznie bezpłatny przy wdrożeniu NS. Dla sklepu z ruchem powyżej 10k wizyt miesięcznie CDN to inwestycja która się zwraca przy pierwszej fali ruchu z kampanii reklamowej.
Bezpłatna konsultacja
Porozmawiajmy o Twoim projekcie
Opisz, czego potrzebujesz — zaproponujemy zakres, technologię i realny harmonogram. Bez zobowiązań.
24–48 hCzas odpowiedzi
100%Wycena indywidualna
0 złBez zobowiązań
kontakt
Masz projekt lub pytanie? Napisz do nas
Opisz, czego potrzebujesz — strony, sklepu, integracji czy wsparcia technicznego. Odpowiemy z konkretnymi propozycjami i orientacyjną wyceną, zwykle w ciągu jednego dnia roboczego.
