Cache w PrestaShop: Smarty, OPcache, Redis, Varnish, CDN. Co daje ile

Cache to najtańszy sposób na szybszy sklep. Zamiast liczyć stronę od zera przy każdym wejściu, serwer oddaje gotowy wynik z pamięci. Problem w tym, że w PrestaShop cache występuje na pięciu różnych poziomach, każdy robi co innego, a źle ustawiony potrafi pokazać klientowi cudzy koszyk albo cenę sprzed podwyżki. Poniżej kolejność, w jakiej włączamy te warstwy, i co każda z nich daje.

W skrócie

Kolejność włączania: OPcache, cache Smarty, cache obiektów (Redis albo Memcached), cache HTTP (Varnish lub Nginx), CDN na pliki statyczne.
Pierwsze trzy warstwy są bezpieczne dla każdego sklepu i dają największą część zysku. Varnish i cache całych stron wymagają ostrożności przy B2B, koszyku i zalogowanych użytkownikach.
Przy cennikach zależnych od grupy klienta nie włączaj cache całych stron bez rozdzielenia na grupy. Inaczej hurtownik zobaczy cenę detaliczną albo odwrotnie.
Po każdej zmianie testuj trzy rzeczy: koszyk, logowanie i zmianę ceny produktu w panelu.

Pięć warstw i co każda robi

Żeby mądrze włączać cache, trzeba wiedzieć, gdzie w ścieżce od kliknięcia do strony znajduje się każda warstwa. Przeglądarka pyta serwer. Serwer (Nginx lub Apache) albo oddaje gotową stronę z cache HTTP, albo uruchamia PHP. PHP ładuje kod PrestaShop (tu działa OPcache), pyta bazę danych o produkty, ceny i konfigurację (tu działa cache obiektów), składa szablon z wynikami (tu działa cache Smarty) i oddaje HTML. Przeglądarka pobiera jeszcze obrazki, style i skrypty (tu działa CDN).

Warstwa	Co buforuje	Gdzie się włącza	Ryzyko	Efekt
OPcache	skompilowany kod PHP	konfiguracja PHP na serwerze	brak	duży, kilkukrotnie szybsze wykonanie PHP
Smarty	skompilowane i wyrenderowane fragmenty szablonów	panel PrestaShop, Wydajność	niskie	średni do dużego, zależnie od szablonu
Cache obiektów (Redis, Memcached)	wyniki zapytań do bazy, konfiguracja, cechy	panel PrestaShop, Wydajność, Cache	niskie przy poprawnym serwerze	średni, największy przy dużym katalogu
Cache HTTP (Varnish, Nginx)	całe strony HTML dla gości	konfiguracja serwera	wysokie przy B2B i personalizacji	bardzo duży dla ruchu niezalogowanego
CDN	obrazki, CSS, JS, czcionki	DNS i konfiguracja adresów plików	niskie	średni, największy przy klientach z daleka od serwera

Krok 1: OPcache, czyli zacznij od serwera

OPcache to rozszerzenie PHP, które trzyma w pamięci skompilowany kod zamiast kompilować go przy każdym żądaniu. PrestaShop 8 i 9 to tysiące plików PHP, więc bez OPcache serwer marnuje większość czasu na czytanie i parsowanie tego samego kodu. Na większości hostingów jest włączony, ale z ustawieniami za niskimi dla sklepu. Sprawdź w informacjach o PHP, czy opcache.enable jest włączony, czy pamięć wystarcza na cały kod sklepu, i ustaw rzadsze sprawdzanie zmian w plikach na produkcji. Po wdrożeniu nowej wersji kodu trzeba OPcache wyczyścić, inaczej serwer wykonuje stary kod.

Krok 2: cache Smarty

Smarty to silnik szablonów PrestaShop. Ma dwa poziomy: kompilację (zamiana pliku szablonu na kod PHP) i cache (zapamiętanie gotowego HTML dla fragmentu). W panelu, w zakładce Wydajność, ustaw kompilację na „nigdy nie kompiluj ponownie” na sklepie produkcyjnym (na kopii deweloperskiej „kompiluj przy zmianie”) i włącz cache. Do wyboru masz zapis cache w plikach albo w bazie. Pliki są szybsze na dobrym dysku. Włącz też opcję czyszczenia cache tylko przy zmianach, nie przy każdym zapisie w panelu.

Uwaga

Opcja „nigdy nie kompiluj ponownie” oznacza, że zmiany w plikach szablonu nie będą widoczne, dopóki nie wyczyścisz cache ręcznie w panelu. Po każdym wdrożeniu zmian w motywie wyczyść cache, a przy pracach nad szablonem przełącz na kopii na kompilację przy zmianie.

Krok 3: cache obiektów w Redis lub Memcached

PrestaShop przy każdym żądaniu pyta bazę o konfigurację, grupy, języki, waluty, cechy produktów, drzewo kategorii. Większość tych danych zmienia się rzadko. Cache obiektów trzyma je w pamięci serwera, więc baza odpowiada tylko na pytania o rzeczy zmienne: stany, ceny, zamówienia. W panelu, w zakładce Wydajność, sekcja Cache, wybierasz serwer: Memcached albo Redis (w PrestaShop 8 i 9 obsługa Redis wymaga rozszerzenia PHP i modułu lub konfiguracji przez parametry). Redis jest dziś częstszym wyborem, bo łatwiej go monitorować i bezpiecznie czyścić.

Redis musi stać na tej samej maszynie albo w sieci lokalnej, bo każde opóźnienie mnoży się przez setki odczytów na stronę. Daj mu własny limit pamięci i politykę usuwania najstarszych wpisów. Jeśli sklep stoi na współdzielonym hostingu bez Redis i Memcached, zostaje cache w plikach, który też pomaga, ale mniej.

Co z cennikami B2B przy cache obiektów

Cache obiektów jest bezpieczny dla cen zależnych od grupy, bo PrestaShop liczy ceny przy każdym żądaniu z uwzględnieniem grupy klienta, a cache trzyma tylko dane wejściowe. Pułapka pojawia się, gdy integracja z ERP zmienia ceny bezpośrednio w bazie, omijając PrestaShop. Wtedy cache nie wie o zmianie i pokazuje stare dane do czasu wygaśnięcia albo ręcznego czyszczenia. Integracja powinna czyścić cache produktu po aktualizacji albo działać przez klasy PrestaShop, które to robią same.

Krok 4: cache HTTP, czyli Varnish albo Nginx

To najmocniejsza warstwa i najbardziej niebezpieczna. Varnish albo moduł cache w Nginx trzymają gotowe strony HTML i oddają je bez uruchamiania PHP. Dla gościa, który wchodzi na kategorię, czas odpowiedzi serwera spada z kilkuset milisekund do kilku. Problem: strona w sklepie nie jest taka sama dla każdego. Zalogowany klient ma inne ceny, inny koszyk, inne powitanie. Hurtownik ma inny cennik niż detalista. Jeśli Varnish odda hurtownikowi stronę zbuforowaną dla gościa, zobaczy ceny detaliczne. Jeśli odda stronę z czyimś koszykiem, mamy wyciek danych.

Krok po kroku

Buforuj tylko dla gości. Reguła: jeśli żądanie ma ciasteczko sesji z zalogowanym klientem albo niepusty koszyk, omiń cache. Dla PrestaShop oznacza to analizę ciasteczek sklepu w konfiguracji Varnish.
Wyklucz strony dynamiczne. Koszyk, zamówienie, konto klienta, logowanie, wyszukiwarka, wszystkie żądania AJAX modułów. Te adresy nigdy nie trafiają do cache.
Oddziel treść zależną od użytkownika. Liczba produktów w koszyku i powitanie w nagłówku powinny być doładowywane osobnym żądaniem po załadowaniu strony. Inaczej musisz buforować osobną stronę dla każdego klienta, czyli wcale.
Ustaw unieważnianie. Zmiana ceny albo stanu w panelu musi usuwać z cache stronę produktu i kategorie, w których jest. Bez tego produkt wyprzedany pokazuje się jako dostępny przez cały czas życia wpisu w cache.
Przy B2B z cennikami per grupa rozdziel cache według grupy albo nie buforuj zalogowanych. Prościej: zalogowani omijają cache HTTP, a korzystają z pozostałych warstw. Dopiero gdy to za mało, dziel cache po grupie klienta w kluczu.

Z naszej praktyki

Hurtownia z czterema grupami cenowymi włączyła Varnish z gotowej konfiguracji z internetu. Przez dwa dni klienci z grupy hurtowej widzieli ceny detaliczne na kategoriach, bo cache nie rozróżniał grup, a liczył tylko to, czy ktoś jest zalogowany. Poprawiliśmy konfigurację tak, żeby zalogowani całkowicie omijali cache HTTP, a goście dostawali strony z Varnish. Ruch gości to było ponad 80 procent żądań, więc serwer i tak odetchnął, a cenniki wróciły do porządku.

Krok 5: CDN na pliki statyczne

CDN to sieć serwerów, które trzymają kopie Twoich obrazków, stylów i skryptów blisko klienta. Przy sprzedaży tylko w Polsce z serwerem w Polsce zysk jest mniejszy, ale CDN odciąża serwer z obsługi setek drobnych plików. W PrestaShop ustawiasz to w zakładce Wydajność jako serwery mediów albo przez konfigurację domeny w CDN, który działa jako warstwa przed całym sklepem. W tym drugim wariancie CDN może też pełnić rolę cache HTTP z kroku 4 i obowiązują te same zasady ostrożności.

Co zrobić z opcjami CCC

W tej samej zakładce Wydajność są opcje łączenia, kompresji i cache plików CSS i JavaScript, znane jako CCC. Łączą wiele plików w jeden i minimalizują je. Brzmi dobrze, ale w praktyce potrafią zepsuć moduły, które polegają na kolejności ładowania skryptów. Włączaj po jednej, najpierw CSS, potem JavaScript, i po każdej sprawdzaj koszyk, warianty, wyszukiwarkę i płatności. Jeśli coś przestaje działać, wyłącz i poszukaj modułu winowajcy albo zostaw tę opcję wyłączoną.

Cache nie przyspiesza sklepu. Cache sprawia, że sklep nie robi tej samej roboty dwa razy. Jeśli robota jest głupia, cache tylko ją ukrywa.

Jak sprawdzić, czy to działa

Czas odpowiedzi serwera (TTFB) dla kategorii i karty produktu przed i po każdej warstwie. Narzędzia deweloperskie przeglądarki albo PageSpeed Insights.
Współczynnik trafień w Redis i Varnish. Poniżej 80 procent trafień coś jest nie tak: za krótki czas życia, za częste czyszczenie, za mało pamięci.
Trzy testy ręczne po każdej zmianie: dodaj produkt do koszyka jako gość i po zalogowaniu, zmień cenę produktu w panelu i sprawdź, czy strona ją pokazuje, zaloguj się jako klient z innej grupy cenowej.
Dziennik błędów przez dobę po włączeniu każdej warstwy. Błędy połączenia z Redis albo pełna pamięć OPcache pojawią się tam pierwsze.

Pytania, które słyszymy najczęściej

Czy mogę włączyć wszystko naraz i mieć spokój?

Nie. Włączaj warstwa po warstwie, z testami między. Jeśli coś się zepsuje, będziesz wiedzieć co. Przy wszystkim naraz spędzisz dzień na szukaniu winnego.

Który cache daje najwięcej?

Przy słabym serwerze OPcache i Smarty. Przy dużym katalogu Redis. Przy dużym ruchu gości Varnish. Zacznij od pierwszych trzech, bo są bezpieczne, i zmierz, czy to wystarcza.

Co z cache przy aktualizacji PrestaShop albo modułów?

Przed aktualizacją wyłącz Varnish albo ustaw tryb omijania, po aktualizacji wyczyść wszystkie warstwy: OPcache, Smarty, Redis, Varnish. Inaczej część sklepu działa na starym kodzie albo starych szablonach.

Nie wiesz, które warstwy cache masz włączone i czy działają poprawnie? W audycie wydajności sprawdzamy każdą z nich i podpowiadamy kolejność zmian dla Twojego sklepu i Twojego cennika. Zobacz, co zawiera audyt.

Zamów audyt wydajności