Przyspieszenie PrestaShop zaczyna się od pomiaru, a nie od instalowania kolejnego modułu „do szybkości”. Sklep może być wolny z trzech różnych powodów: serwer długo generuje stronę, przeglądarka pobiera za dużo danych albo skrypty blokują stronę po załadowaniu. Każdy z nich naprawia się inaczej, a poniżej pokazujemy, jak je rozróżnić i co dało największy efekt w sklepach, które utrzymujemy.
W skrócie: Google ocenia szybkość przez Core Web Vitals: LCP do 2,5 s, INP do 200 ms i CLS do 0,1 dla 75% wizyt. TTFB, czyli czas odpowiedzi serwera, powinien wynosić do 0,8 s. W jednym z utrzymywanych przez nas sklepów cache brzegowy HTML obniżył TTFB z ok. 535 ms do 60–80 ms, a optymalizacja zdjęć zmniejszyła wagę strony głównej z 20,9 MB do 8,4 MB.
Jak mierzyć szybkość sklepu
Szybkość sklepu mierzy się dwoma rodzajami danych: z laboratorium (test jednego wejścia, np. PageSpeed Insights) i z terenu (prawdziwi użytkownicy w Chrome, raport CrUX). Do oceny w Google liczą się dane z terenu, a do szukania przyczyn – dane z laboratorium.
| Wskaźnik | Co mierzy | Dobry wynik |
|---|---|---|
| LCP | Czas do wyświetlenia największego elementu, np. zdjęcia | do 2,5 s |
| INP | Reakcja strony na kliknięcie lub dotyk | do 200 ms |
| CLS | Przesuwanie się elementów podczas ładowania | do 0,1 |
| TTFB | Czas do pierwszego bajtu odpowiedzi serwera | do 0,8 s |
Założenia: progi Google dla 75. percentyla wizyt; TTFB nie jest wskaźnikiem Core Web Vitals, tylko pomocniczym.
Źródło progów: web.dev, Core Web Vitals i web.dev, TTFB. TTFB nie jest oceniany bezpośrednio, ale wolny serwer praktycznie uniemożliwia dobry LCP. Zmierz osobno stronę główną, kategorię i produkt, bo każda ma inne wąskie gardło.
Serwer i TTFB – kiedy problem leży po stronie hostingu
Wysoki TTFB oznacza, że serwer długo przygotowuje stronę, zanim wyśle pierwszy bajt. W PrestaShop najczęstsze przyczyny to słaby lub współdzielony serwer, stara wersja PHP, wolne zapytania do bazy i moduły, które przy każdym wejściu łączą się z zewnętrznymi usługami.
Co sprawdzić:
- Zasoby serwera – czy sklep ma przypisany procesor i pamięć, czy dzieli je z innymi stronami.
- Wersję PHP – PrestaShop 9 działa na PHP 8.1–8.4; nowsze PHP jest szybsze.
- Wolne zapytania – log wolnych zapytań w bazie pokazuje, który moduł obciąża sklep.
- Moduły z zewnętrznymi wywołaniami – np. pobieranie kursów, opinii, stanów z hurtowni przy każdym wejściu.
W sklepach, które utrzymujemy, każdy sklep ma własną maszynę wirtualną z gwarantowanymi zasobami. Dzięki temu skok ruchu w jednym sklepie nie spowalnia innych.
Cache – największa pojedyncza zmiana
Cache to gotowa kopia strony podawana bez generowania jej od nowa. W PrestaShop działa na kilku poziomach: pamięć PHP (OPcache), cache samego PrestaShop i cache brzegowy w sieci CDN, który zwraca gotowy HTML z serwera najbliżej klienta.
Nasz pomiar z września 2026 r. w sklepie na PrestaShop 9:
| Konfiguracja | TTFB |
|---|---|
| Z cache brzegowym HTML (trafienie w cache) | 60–80 ms |
| Ten sam sklep bez cache brzegowego | ok. 535 ms |
| Inny sklep bez cache brzegowego | 650–870 ms |
Założenia: pomiar z 14.09.2026, strony publiczne bez zalogowanego klienta, serwery w UE.
Cache brzegowy wymaga ostrożności. Koszyk, konto klienta, zamówienie i ceny zależne od grupy klienta muszą go omijać, inaczej klient zobaczy cudzy koszyk albo złą cenę. Konfiguracja wyjątków to praca na kilka godzin, nie jedno kliknięcie.
Uwaga na TTFB a LCP: Szybki TTFB nie oznacza od razu dobrego LCP. Jeśli strona ładuje ciężkie zdjęcie główne i kilka skryptów, wynik dla użytkownika nadal będzie słaby. Dlatego po cache zawsze przychodzi kolej na zdjęcia i skrypty.
Zdjęcia – najczęstszy powód wolnego LCP
Największy element strony w sklepie to zwykle zdjęcie: baner na stronie głównej albo zdjęcie produktu. Za duże pliki wydłużają LCP bardziej niż cokolwiek innego, zwłaszcza na telefonie.
Co pomaga:
- Nowoczesne formaty – PrestaShop 9 obsługuje natywnie WebP i AVIF.
- Kompresja przy wgrywaniu – sklep sam zmniejsza plik, nawet gdy ktoś wgra 10-megabajtowe zdjęcie z aparatu.
- Właściwe rozmiary miniatur – telefon nie powinien pobierać zdjęcia w rozdzielczości monitora.
- Leniwe ładowanie dla zdjęć poniżej pierwszego ekranu, ale nie dla zdjęcia głównego.
W jednym z utrzymywanych sklepów włączenie optymalizacji przy wgrywaniu zmniejszyło wagę strony głównej z 20,9 MB do 8,4 MB. Zespół sklepu nadal wgrywa zdjęcia tak samo jak wcześniej.
Filtry, wyszukiwarka i moduły
W dużym katalogu wąskim gardłem bywają filtry. Natywne filtry PrestaShop przy tysiącach produktów i kombinacji potrafią mocno obciążyć bazę. Przy dużym katalogu lepiej sprawdzają się filtry na osobnym indeksie, który liczy wyniki bez przeszukiwania całej bazy za każdym razem.
Druga sprawa to liczba modułów. Każdy moduł może dokładać skrypty, style i zapytania na każdej stronie. Raz na kwartał przejrzyj listę modułów i wyłącz te, których nikt nie używa.
Kolejność działań – od czego zacząć
- Pomiar – PageSpeed Insights i dane z terenu dla strony głównej, kategorii i produktu.
- TTFB – jeśli powyżej 0,8 s, zacznij od serwera, PHP i cache.
- LCP – zdjęcie główne: format, rozmiar, brak leniwego ładowania.
- INP – skrypty: czat, widgety, piksele reklamowe, ciężkie moduły.
- CLS – zarezerwowane miejsce na zdjęcia, banery i powiadomienia o cookies.
- Kontrola po zmianach – dane z terenu aktualizują się w ciągu 28 dni, więc efekt w Google widać po kilku tygodniach.
Szybkość zależy też od wersji platformy: co zmienia przejście na nową wersję, opisaliśmy w tekście PrestaShop 9 – co się zmienia. Szybkość wpływa także na widoczność w odpowiedziach AI, bo Google ocenia stronę tak samo – więcej w poradniku jak pojawić się w ChatGPT i AI Overviews.
Wniosek: Najpierw zmierz, potem naprawiaj w kolejności: serwer i cache, zdjęcia, skrypty. Cache brzegowy HTML daje największy skok TTFB, ale wymaga starannie ustawionych wyjątków dla koszyka i konta klienta. Moduł „do przyspieszania” nie naprawi słabego serwera ani 20-megabajtowej strony.
Najczęstsze pytania
Jaki TTFB jest dobry dla sklepu na PrestaShop?
Google traktuje jako dobry TTFB do 0,8 sekundy, a powyżej 1,8 sekundy jako słaby. Sklep z dobrze ustawionym cache brzegowym może odpowiadać w kilkadziesiąt milisekund, bez cache zwykle w kilkaset. TTFB nie jest wskaźnikiem Core Web Vitals, ale wolny serwer utrudnia osiągnięcie dobrego LCP.
Czy moduł do cache wystarczy, żeby przyspieszyć PrestaShop?
Rzadko. Moduł cache pomaga, gdy problemem jest generowanie strony, ale nie naprawi ciężkich zdjęć, nadmiaru skryptów ani słabego serwera. Najpierw sprawdź, który wskaźnik jest słaby: TTFB, LCP czy INP. Dopiero wtedy wiesz, czy pomoże cache, optymalizacja zdjęć czy porządek w modułach.
Czy szybkość sklepu wpływa na pozycje w Google?
Core Web Vitals są jednym z sygnałów oceny strony w Google, ale nie zastąpią dobrej treści i trafności. Większy efekt szybkość ma na konwersję i zachowanie klientów, zwłaszcza na telefonie. Wolna strona produktu traci kupujących niezależnie od pozycji w wynikach.
Po jakim czasie zobaczę poprawę w Google Search Console?
Dane z terenu w raporcie Core Web Vitals opierają się na ostatnich 28 dniach wizyt. Pierwsze zmiany widać zwykle po 2–4 tygodniach od wdrożenia poprawek. Wyniki z PageSpeed Insights w trybie laboratoryjnym zobaczysz od razu, ale to tylko pojedynczy test.
Co dalej
Zmierz stronę główną, kategorię i produkt w PageSpeed Insights i zapisz TTFB oraz LCP. Jeśli TTFB jest wysoki, problem leży zwykle po stronie serwera – zobacz, jak działa nasz hosting dla PrestaShop.
