Strategia cache w PrestaShop 2026: Redis, Memcached i Varnish, czyli jaki stack do jakiego sklepu

W niezoptymalizowanym sklepie PrestaShop 8 albo 9 TTFB (Time To First Byte) regularnie przekracza 800 ms na hostingu współdzielonym i utrzymuje się w okolicach 400 ms na VPS ze średniej półki. Wpływ jest bezpośredni: na LCP (zły wynik Core Web Vitals), na budżet crawlu Googlebota i na współczynnik odrzuceń. A wszystko to w 2026 roku, gdy punktem odniesienia Google jest 200 ms TTFB i 2,5 s LCP.

Cache nie jest tematem niszowym ani zarezerwowanym dla dużych wolumenów. To optymalizacja o najwyższym zwrocie w PrestaShop i zarazem ta, którą robi się najgorzej: mylenie cache PHP, cache obiektowego, cache HTTP i reverse proxy, mało wydajne konfiguracje domyślne oraz stosy modułów wchodzących sobie w drogę. Ten artykuł porządkuje cztery warstwy czystego stacku i podaje regułę decyzyjną Redis kontra Memcached kontra Varnish zależnie od profilu sklepu.

Cztery warstwy cache w sklepie PrestaShop

Sklep serwuje każdą stronę, nakładając na siebie kilka warstw cache. Znajomość tych warstw pozwala nie nakładać ich więcej, niż trzeba, bo każda dokłada złożoności i punktów unieważniania do opanowania.

1. Cache opcode PHP

OPcache trzyma w pamięci bytecode interpretowanych plików PHP. Niezbędny, bo bez niego każde żądanie PrestaShop na nowo interpretuje tysiące plików. Typowy zysk: od 30 do 50 % TTFB. Jest darmowy, natywny dla PHP i to pierwszy odruch do sprawdzenia na produkcji poleceniem php -i | grep opcache. Wymiarowanie: minimum 256 MB dla PrestaShop 8 i 9, opcache.validate_timestamps=0 na produkcji z ręcznym przeładowaniem przy wdrożeniu.

2. Cache obiektowy (in-memory key-value)

PrestaShop cache’uje część wyników aplikacyjnych: sesje użytkowników, metadane Smarty (ścieżki szablonów, konfiguracja hooków), wyniki powtarzalnych zapytań. Domyślnie te dane idą przez system plików, co jest wolne. W poważnej produkcji przenosimy je do bazy in-memory: Redis albo Memcached.

3. Cache HTTP i reverse proxy

Nad PrestaShop reverse proxy (Varnish, cache NGINX albo edge cache CDN) przechwytuje żądania HTTP i serwuje wstępnie wyrenderowane odpowiedzi bez angażowania PHP. To optymalizacja o największej dźwigni, z typowym zyskiem 90 % czasu serwera na stronach anonimowych przy trafieniu w cache.

4. Cache przeglądarki i CDN

Zasoby statyczne (obrazy, CSS, JS, fonty) muszą nieść nagłówki Cache-Control: public, max-age=31536000, immutable i być serwowane przez CDN. Oczywistość w 2026 roku, a jednak źle zrobiona w 40 % audytowanych sklepów: za krótki max-age, niewersjonowane zasoby, źle skonfigurowane wariacje cache.

Redis kontra Memcached: decyzja w praktyce

W cache obiektowym dominują dwa wybory. Debata „który jest szybszy” jest przestarzała, bo oba z zapasem pokrywają potrzeby sklepu PrestaShop. Prawdziwa różnica leży gdzie indziej.

Memcached

• Prostszy, mniej funkcji, mniejsza powierzchnia ataku i mniej pułapek konfiguracyjnych.
• Świetny do czysto ulotnego cache key-value.
• Brak trwałości na dysku: restart czyści wszystko, co daje przejściowy szturm na PHP-FPM.
• Brak struktur zaawansowanych (listy, sorted sets, pub-sub), więc zastosowanie ogranicza się do samego cache.

Redis

• Bogatszy: struktury danych, pub-sub, skrypty Lua.
• Opcjonalna trwałość (RDB albo AOF), więc przeżywa restarty.
• Używany daleko poza cache PrestaShop: sesje na wielu serwerach, kolejka Symfony Messenger, ograniczanie tempa żądań.
• Wymaga pilnowania pamięci (maxmemory, polityka wypierania), bo inaczej zużywa więcej, niż zakładano.

Reguła praktyczna na 2026 rok: Redis jest wyborem domyślnym. Memcached pozostaje zasadny, jeśli sklep jest świadomie minimalistyczny, a jedyną potrzebą jest czysty cache obiektowy. Każdy sklep, który przewiduje z czasem kolejkę zadań, ograniczanie tempa żądań do API albo sesje współdzielone między serwerami, zyskuje, startując od razu z Redisa.

Kiedy Varnish ma sens, a kiedy nie

Varnish (albo pełnostronicowy cache NGINX) to optymalizacja o największej dźwigni w PrestaShop, bo serwuje strony anonimowe w kilka milisekund zamiast w 400 do 800 ms. Ale nie w każdej konfiguracji zmienia zasady gry.

Przypadki, w których Varnish zmienia wszystko

• Ruch w większości anonimowy: odwiedzający niezalogowani, brak cen personalizowanych per klient, brak testów A/B rozstrzyganych po stronie serwera. Katalog B2C dla szerokiej publiczności.
• Wysoki wolumen skupiony na niewielu adresach: strona główna, 50 kategorii i 500 kart produktów odpowiada za 80 % ruchu. Cache wykonuje wtedy większość pracy.
• Przewidywalny szczyt sezonowy: Black Friday, wyprzedaże. Varnish przyjmuje ruch bez zapychania PHP-FPM.

Przypadki, w których Varnish jest pułapką

• Sklep B2B z obowiązkowym logowaniem: każda strona jest personalizowana (ceny grupy klienta, wielu użytkowników, oferty w toku). Varnish obsługuje tylko rzadkie strony publiczne, a złożoność przewyższa zysk.
• Personalizacja po stronie serwera: rekomendacje AI per użytkownik, testy A/B serwerowe, ceny dynamiczne. Pełnostronicowy cache unieważnia całą personalizację.
• Ruch anonimowy rozproszony po tysiącach adresów z długiego ogona: jeśli każdy adres odwiedzany jest raz dziennie, współczynnik trafień pozostaje niski, a Varnish nic nie wnosi.

Alternatywa: edge cache po stronie CDN

W 2026 roku Cloudflare Cache Rules, BunnyCDN Permacache, Fastly i podobne rozwiązania wykonują pracę Varnisha na poziomie CDN, bez dodatkowego serwera. Zaleta: brak kolejnej warstwy do utrzymania, dystrybucja geograficzna, natywna integracja z WAF. Wada: precyzyjne unieważnianie jest mniej elastyczne niż w Varnishu, a koszt potrafi rosnąć przy dużych wolumenach. Dla 80 % sklepów ze średniej półki edge cache stał się rozwiązaniem lepszym niż samodzielnie hostowany Varnish.

Realny koszt i zwrot z czystego stacku cache

Koszt

• OPcache: 0 zł. Wystarczy włączyć i dobrze wymiarować.
• Redis: 0 zł lokalnie (ten sam serwer co PHP-FPM) albo od kilkudziesięciu do stu kilkudziesięciu złotych miesięcznie na osobnym VPS lub w wersji zarządzanej.
• Varnish: 0 zł licencji, ale od 1 do 3 dni instalacji i strojenia przez kompetentnego administratora. Do zabudżetowania w czasie, nie w licencji.
• Edge cache CDN: od kilkudziesięciu do kilkuset złotych miesięcznie zależnie od dostawcy i wolumenu transferu.
• Wdrożenie początkowe: od 2 do 5 dni pracy deweloperskiej dla standardowego sklepu (konfiguracja, testy, automatyczne unieważnianie na webhookach PrestaShop).

Zmierzony zwrot

Z audytów sklepów PrestaShop 8 ze średniej półki po wdrożeniu czystego stacku cache:

• TTFB spada z 600 do 800 ms na 80 do 150 ms przy trafieniu w cache.
• LCP schodzi z 3,2 s na 1,4 s na anonimowej karcie produktu.
• Mobilny współczynnik odrzuceń spada średnio o 12 do 18 %.
• Konwersja mobilna rośnie o 6 do 12 %.
• Budżet crawlu Google się podwaja, co po 4 do 8 tygodniach przekłada się na około 15 % więcej zaindeksowanych adresów.

Koszt zaniechania czystego cache często przekracza 1 % rocznego obrotu. Sklep z obrotem 4 mln zł rocznie traci typowo od 40 do 80 tys. zł rocznie na pogorszonej wydajności.

Pułapki, których należy unikać

1. Nakładanie modułów cache bez spójności

Wiele sklepów gromadzi: oficjalny moduł cache PrestaShop, zewnętrzny moduł Redis, osobny moduł Varnish, wtyczkę CDN. Bez czytelnej hierarchii cache źle się wzajemnie unieważniają, a część trafień znosi pozostałe. Potrzebna jest jedna udokumentowana polityka cache, z jasnym schematem kaskadowego unieważniania.

2. Złe unieważnianie na zdarzeniach

Gdy zmienia się cena, aktualizuje stan magazynowy albo modyfikuje atrybut produktu, odpowiednia strona musi zostać unieważniona. PrestaShop nie ma jednego ujednoliconego hooka, więc trzeba podpiąć actionProductUpdate, actionObjectStockMvtAddAfter, actionObjectCategoryUpdateAfter i wyzwolić właściwe czyszczenie (PURGE w Varnishu, DEL w Redisie, API CDN). Bez tego odwiedzający widzi nieaktualną cenę, co może naruszać wymogi dyrektywy Omnibus.

3. Cache’owanie stron personalizowanych

Koszyk, konto klienta, checkout i każda strona z danymi użytkownika nigdy nie mogą trafiać do cache pełnostronicowego. Reguła Varnisha albo CDN musi jawnie wykluczać te ścieżki. Częsty błąd: sklep cache’ujący wszystko domyślnie pokazuje koszyk jednego klienta drugiemu. Incydent poważny i trudny do zdiagnozowania po fakcie.

4. Brak testów pod obciążeniem

Czysty cache waliduje się pod obciążeniem. Narzędzie takie jak k6 albo Locust pozwala zasymulować od 500 do 1000 jednoczesnych odwiedzających i zmierzyć współczynnik trafień, TTFB pod obciążeniem i stabilność PHP-FPM. Bez tego testu problemy odkrywasz na produkcji w dniu szczytu, czyli w najgorszym możliwym momencie.

5. Pominięcie multisklepu i wielu walut

Zbyt agresywny cache w multisklepie potrafi podać ten sam HTML wszystkim sklepom albo pokazać cenę w złotych odwiedzającemu rozliczającemu się w euro. Klucz cache musi zawierać co najmniej id_shop, id_lang i id_currency. Zweryfikuj wprost generowany klucz, bo to najbardziej kosztowny cichy błąd w tym obszarze.

Stack zalecany domyślnie w 2026 roku

Dla 80 % sklepów PrestaShop 8 i 9 ze średniej półki:

1. OPcache włączony z 256 MB i opcache.validate_timestamps=0 na produkcji.
2. Redis jako backend cache obiektowego PrestaShop (sesje, Smarty, metadane). W większości przypadków wystarczy jedna instancja.
3. Edge cache CDN na stronach katalogu i publicznych stronach CMS, z jawnym wykluczeniem ścieżek użytkownika.
4. Agresywny cache przeglądarki na zasobach statycznych (rok), wersjonowanych hashem przez system zasobów PrestaShop.
5. Bez Varnisha, poza szczególnym przypadkiem dużego jednorodnego ruchu, gdzie strojenie i utrzymanie się uzasadniają.

Ten stack wdraża się w 2 do 5 dni, kosztuje kilkadziesiąt do kilkuset złotych miesięcznie i daje zysk wydajnościowy znacznie większy niż to, co da się osiągnąć optymalizacją kodu aplikacyjnego. Przed jakąkolwiek optymalizacją po stronie zaplecza (przebudowa modułów, zapytania SQL) przejrzenie tych pięciu punktów pozostaje pierwszym opłacalnym krokiem.

Przeczytaj także: Core Web Vitals 2026 i optymalizacja PrestaShop oraz techniczną listę kontrolną LCP, INP i CLS.

Aby przejść do działania: nasz wybór modułów przyspieszających sklep PrestaShop.