Cache PrestaShop: moduły cache pełnych stron. Zalety, wady i jak naprawdę działają

Tworzymy Performance Revolution, więc mamy w tym temacie własny interes, ale i tak powiemy uczciwie. Moduł cache pełnych stron potrafi w jedno popołudnie zmienić PrestaShop ładujący się 3 sekundy w sklep odpowiadający w 200 ms. W przypadku większości sklepów, które audytujemy, to dobry ruch pierwszego dnia. To, czy nadal będzie dobrym ruchem dziewięćdziesiątego dnia, zależy od tego, co naprawdę powoduje spowolnienie i czy w ogóle planujesz to naprawić.

Zweryfikowano dla PrestaShop 1.6, 1.7, 8.x i 9.x. Opisane niżej kompromisy dotyczące hydracji i unieważniania cache są takie same we wszystkich tych wersjach; PS8/9 dodają warstwę cache Symfony, której pomaga cache obiektów (Redis), o czym piszemy dalej.

Czym jest Full Page Cache?

Domyślnie każde żądanie strony w PrestaShop uruchamia PHP, ładuje framework, wykonuje od 40 do 400 zapytań SQL, kompiluje szablony Smarty i dopiero na końcu zwraca HTML. Na sklepach deweloperskich, które prowadzimy, trwa to 200–400 ms. Na przeciętnym PrestaShop na hostingu współdzielonym, do którego wzywa się nas na ratunek, to 2–5 sekund.

Moduł full page cache (FPC) pomija cały ten proces. Pierwszy odwiedzający daną stronę renderuje ją normalnie; moduł przechwytuje gotowy HTML i zapisuje go. Każdy kolejny odwiedzający dostaje zapisaną kopię, bez uruchamiania PHP, bez bazy danych, bez Smarty. Tylko bajty z dysku, Redis albo Varnish.

TTFB spada z sekund do dziesiątek milisekund. Nie ma szybszego sposobu, by powolny PrestaShop zaczął sprawiać wrażenie szybkiego bez przepisywania wolnych fragmentów.

Jak działają moduły FPC dla PrestaShop

Schemat jest taki sam we wszystkich modułach FPC, które analizowaliśmy, naszym również:

1. Pierwsza wizyta, strona renderuje się normalnie przez PrestaShop, moduł przechwytuje HTML po drodze, zapisuje go w magazynie (plik, Redis, Memcached albo serwer brzegowy CDN).
2. Kolejne wizyty, moduł przechwytuje żądanie przed startem PrestaShop, sprawdza, czy istnieje kopia w cache, serwuje ją i kończy działanie. PrestaShop w ogóle się nie ładuje.
3. HTML bez sesji. Strona w cache nie może zawierać tekstów typu „Witaj ponownie, Janie” ani „3 produkty w koszyku”, bo została zapisana bez sesji. Z definicji jest generyczna.
4. Hydracja przez JavaScript, po załadowaniu statycznego HTML AJAX pobiera elementy zależne od użytkownika: liczbę produktów w koszyku, stan logowania, walutę, ostatnio oglądane produkty. Przeglądarka podmienia je na stronie.

Ten ostatni krok to cały kompromis w jednym zdaniu. Serwer robi się szybki; przeglądarka ma więcej pracy później.

I narzuca to najważniejszą zasadę cache pełnych stron w PrestaShop, tę, którą własne konfiguracje psują jako pierwszą: zapisuj w pamięci cache front sklepu dla anonimowych odwiedzających, ale nigdy nie zapisuj w pamięci cache koszyka, realizacji zamówienia ani stron logowania/zalogowanego klienta. Te ścieżki różnią się dla każdego odwiedzającego i każdej sesji, jeśli podasz wersję z cache, możesz pokazać klientowi cudzy koszyk, adres albo niedokończone zamówienie. Każdy poważny moduł FPC domyślnie wyklucza te ścieżki i dokleja elementy na żywo (licznik koszyka, stan logowania) do powłoki zapisanej w cache. Jeśli budujesz własne cache na poziomie nginx albo Varnish, lista wykluczeń dla URL-i koszyka/realizacji zamówienia/logowania nie jest opcjonalna; to różnica między zyskiem wydajnościowym a incydentem.

Zalety, i są realne

Natychmiastowy Time to First Byte

1–5 sekund spada do 20–100 ms. Nic innego, co możesz zainstalować w PrestaShop, nie przesunie wyniku tak mocno. Core Web Vitals Google biorą to bezpośrednio pod uwagę, a Twój współczynnik odrzuceń również. Jeśli wąskim gardłem jest hosting, baza danych albo zestaw modułów, FPC obchodzi problem zamiast go rozwiązywać, i dla wielu sklepów takie obejście jest w porządku.

Prawdziwe koło ratunkowe dla sklepów w trudnym stanie

Przejmowaliśmy sklepy z 47 aktywnymi modułami, bazą danych 14 GB i bez programisty w abonamencie. Właściciel potrzebuje szybkiej strony przed Black Friday. Weekend profilowania i refaktoryzacji nie wchodzi w grę. Wdrażasz FPC i w poniedziałek sklep znowu jest konkurencyjny. To nie jest kompromis, to właściwa decyzja dla tego sklepu i tego terminu.

FPC tak naprawdę maskuje wszystko, co pod spodem jest wolne. Jeśli teraz nie możesz pozwolić sobie na naprawę źródła problemu, maskowanie jest dokładnie tym narzędziem, którego potrzebujesz.

Zmniejsza obciążenie serwera

Na hostingu współdzielonym, gdzie masz 2 workery PHP i limit CPU, każde żądanie obsłużone prosto z cache to żądanie, które nie dotyka PHP. Widzieliśmy ten sam sklep, który przed FPC załamywał się przy 30 równoczesnych użytkownikach, a po włączeniu FPC obsługiwał 300 bez zadyszki, na identycznym sprzęcie.

Lepsze pozycje w Google, ale przeczytaj następną sekcję

Szybkość strony jest potwierdzonym czynnikiem rankingowym, a sklep odpowiadający w 200 ms wyprzedzi taki, który ładuje się 4 sekundy. FPC daje ten efekt minimalnym nakładem pracy. Pamiętaj tylko, że „szybszy TTFB” i „lepsze Core Web Vitals” to nie to samo, czytaj dalej.

Wady, na co uważać

Problem hydracji sesji

To widoczna cena każdego modułu FPC na rynku.

Strona z cache renderuje się bez sesji. Ikona koszyka pokazuje 0. Nagłówek mówi „Zaloguj się”, nawet gdy użytkownik jest zalogowany. Ostatnio oglądane są puste. Waluta to domyślna waluta sklepu, a nie wybór odwiedzającego. Ułamek sekundy później przychodzi żądanie AJAX i JS poprawia stronę: pojawia się licznik koszyka, wstawia się imię, zmienia się waluta.

Na szybkim połączeniu i szybkim urządzeniu ten moment jest prawie niezauważalny. Na średniej klasy Androidzie przez 4G (czyli przy dużej części realnego ruchu) to widoczne mignięcie. Oglądaliśmy nagrania sesji w Microsoft Clarity, w których użytkownicy klikali ikonę koszyka, gdy nadal pokazywała 0, trafiali na pusty koszyk i wychodzili. Strony z cache potrafią to zrobić.

CLS (Cumulative Layout Shift)

Te poprawki po hydracji przesuwają elementy. Link „Zaloguj się” jest węższy niż „Witaj, Jonathan Stevens”. Licznik koszyka 0 to jeden znak; po hydracji 3 może być trzema znakami z plakietką. Każda podmiana przesuwa sąsiednie elementy.

Na FPC możesz wygrać LCP i przegrać CLS dokładnie o tę samą różnicę. Widzieliśmy sklepy na Performance Revolution z wynikami Lighthouse w okolicach 90 dla LCP i 60 dla CLS wyłącznie przez przesunięcia po hydracji. Zarezerwuj miejsce na dynamiczne elementy w HTML zapisanym w cache (liczniki koszyka o stałej szerokości, szkieletowe placeholdery na imię klienta), inaczej zobaczysz, jak zyski znikają w raporcie Vitals.

Ryzyko nieaktualnej treści

Strona w cache to zamrożona fotografia. Zmienisz cenę, przełączysz stan magazynowy, włączysz promocję błyskawiczną, zmienisz opis kategorii, kopia w cache nadal pokazuje wczorajszą rzeczywistość, dopóki cache nie zostanie unieważnione.

Tu moduły FPC naprawdę różnią się między sobą i warto rozumieć dostępne podejścia:

• Unieważnianie na hookach (tak działa Performance Revolution i większość poważnych modułów), nasłuchuje actionProductUpdate, actionObjectCartRuleUpdateAfter, actionUpdateQuantity oraz kilkunastu innych zdarzeń i czyści tylko dotknięte strony. Szybkie, precyzyjne i przez większość czasu poprawne.
• Unieważnianie wyłącznie przez TTL, każdy wpis cache wygasa po N minutach. Proste, głupie, przewidywalne. Błędne nawet przez N minut po każdej zmianie. Dobre dla sklepów treściowych, ryzykowne przy stanach magazynowych.
• Ręczne czyszczenie, administrator klika „wyczyść cache” po zmianach. Nie wypuszczaj takiego rozwiązania; sprzedawcy zapominają.

Nawet unieważnianie oparte na hookach ma luki. Importy ERP zapisujące bezpośrednio do bazy danych omijają każdy hook wywoływany przez PrestaShop, cache nigdy nie dowiaduje się, że zmienił się stan magazynowy. Reguły koszyka ze złożonymi warunkami dotykają produktów, których się nie spodziewasz. Moduły firm trzecich trzymające własny stan łamią założenia. Widzimy to w zgłoszeniach supportowych wystarczająco często, by ostrożnie podchodzić do deklaracji o „idealnym unieważnianiu”.

Debugowanie robi się dziwniejsze

Pierwsze pytanie przy każdym sklepie działającym z cache brzmi: „czy to cache?”. Zaczniesz odruchowo czyścić cache na początku każdego dochodzenia błędu i boleśnie nauczysz się, że endpointy AJAX zachowują się inaczej niż strony HTML z cache, a narzędzia do „podglądu wylogowanego użytkownika” kłamią, gdy w grę wchodzi hydracja. Warto to robić, ale warto wiedzieć o tym wcześniej.

Gdzie potyka się każdy backend przechowywania

Krótka, uczciwa opinia po używaniu wszystkich trzech w realnych warunkach:

• Cache plików, najprostsze, bez infrastruktury, wystarczające dla sklepu na jednym serwerze. Wykłada się przy równoczesnych zapisach. Podczas intensywnej aktualizacji produktów w trakcie importu możesz sam doprowadzić do zakleszczenia.
• Redis, nasz domyślny wybór w Performance Revolution. Szybki, bez blokowania plików, działa z wieloma workerami PHP. Wymaga instancji Redis (u nas współdzielone ps-redis obsługuje ponad 20 sklepów bez problemu). Twardy limit pamięci; dostrój maxmemory-policy.
• Varnish / FPC przez reverse proxy, najszybsze rozwiązanie, bo żądanie w ogóle nie dociera do PHP. Jednocześnie najtrudniejsze do czystego unieważniania (ESI dla dynamicznych fragmentów ma własną krzywą uczenia), a nie każdy hosting pozwala je uruchomić. Jeśli Twój hosting już ma to skonfigurowane, użyj tego. W przeciwnym razie moduły FPC na poziomie PHP dadzą 90% zysku przy 10% bólu operacyjnego.

Warto opowiedzieć jedną historię z pola walki, bo to tryb awarii, przed którym prawie nikt nie ostrzega: sama maszyneria cache potrafi stać się tym wolnym elementem. Na mypresta.rocks ścigaliśmy kiedyś renderowanie trwające około 2,2 sekundy, które wcale nie wynikało z bazy danych, nasz własny pipeline assetów liczył hash sha1 dla 670 połączonych paczek CSS/JS przy każdym wyświetleniu strony tylko po to, by zdecydować, którą podać. Kod „wydajnościowy” był hotspotem. Naprawiliśmy to, połączyliśmy inline critical CSS z cache warmerem dla 6625 URL-i frontu sklepu i tak strona ma dziś PSI 93 na mobile. Wniosek dla FPC jest konkretny: jeśli po włączeniu cache strona nadal jest wolna, sprofiluj warstwę cache, zanim obwinisz cokolwiek niżej, cache, które zbyt dużo hashuje, blokuje albo serializuje na gorącej ścieżce, oddaje dokładnie to, co miało zaoszczędzić.

Głębiej: naprawa przyczyn źródłowych

Wszystko powyżej to rzeczy, które FPC maskuje. Jeśli masz budżet i czas, naprawienie źródła spowolnień daje tę samą szybkość bez skoków hydracji, bez obaw o nieaktualną treść i bez podatku od debugowania.

To nie musi być jeden wielki projekt. Widzieliśmy sklepy, które przez sześć miesięcy drobnych poprawek, po jednej rzeczy tygodniowo, zeszły z 4-sekundowego TTFB do 300 ms. Traktuj to jak backlog, nie sprint.

Jedno prawdziwe ostrzeżenie: nie kończ projektu optymalizacyjnego w połowie. Działający sklep z popsutym CCC, na wpół dostrojonym MySQL i instancją Redis, która pada w każdą niedzielę, jest gorszy niż ten sam sklep z dobrze skonfigurowanym FPC i niczym więcej. Zrobione jest lepsze niż idealne.

1. Zidentyfikuj wolne moduły

To zdecydowanie najczęstsza przyczyna, którą widzimy. Jeden moduł wykonujący niezindeksowane zapytanie w displayHeader dodaje 500 ms do każdej strony. Moduł statystyk zapisujący synchronicznie każde wyświetlenie do bazy danych dodaje 200 ms. Trzy takie elementy w stosie i sklep ma 3 sekundy, zanim w ogóle zacznie się renderowanie.

Jak je znaleźć:

• Włącz profiler debugowania PrestaShop (_PS_DEBUG_PROFILING_ w config/defines.inc.php). Na dole strony wypisuje czas spędzony w każdym hooku i module. Przeczytaj go.
• W PrestaShop 8+ pasek narzędzi Symfony pokazuje liczbę zapytań i czasy dla każdego żądania. Ponad 100 zapytań SQL na stronie produktu to podejrzany wynik.
• Wyłączaj moduły pojedynczo, odpytywanie strony zrób przez curl i mierz TTFB. Różnica przed/po to dokładnie koszt danego modułu.

Powtarzający się winowajcy: moduły kanałów społecznościowych pobierające dane na żywo z API, liczniki wyświetleń robiące INSERT przy każdym żądaniu, moduły „produkty powiązane” liczące podobieństwo cosinusowe w PHP, moduły SEO regenerujące metadane przy każdym ładowaniu strony zamiast zapisywać je w cache.

2. Napraw kompilację szablonów Smarty

Smarty kompiluje pliki .tpl do PHP. Na produkcji powinno stać się to raz dla każdego szablonu i nigdy więcej.

• force_compile = off. Jeśli jest włączone, każdy szablon kompiluje się ponownie przy każdym żądaniu, to 200–500 ms zmarnowanego CPU na stronę.
• caching = on.
• Po wdrożeniach wyczyść cache kompilacji raz. Nie zostawiaj force_compile włączonego jako „tymczasowego” obejścia.

Liczba sklepów, które przejęliśmy z force_compile zostawionym pół roku wcześniej po sesji debugowania, jest przygnębiająco wysoka. Sprawdź swój.

3. Konfiguracja MySQL

Domyślna konfiguracja MySQL jest dla ogólnego serwera, nie dla Twojego PrestaShop. Ustawienia, które mają znaczenie:

• innodb_buffer_pool_size, to naprawdę najważniejsze. 50–70% dostępnej pamięci RAM. Baza 2 GB z pulą bufora 128 MB stale uderza w dysk.
• innodb_log_file_size, co najmniej 256 MB w sklepach z dużą liczbą zapisów.
• slow_query_log = 1 z long_query_time = 1. Włącz na tydzień, przeczytaj log, znajdziesz zapytania, które trzeba usunąć albo naprawić.
• Wyczyść ps_connections, ps_log, ps_mail. W długo działających sklepach rosną do milionów wierszy i spowalniają każdy SELECT, który je łączy.
• Dodaj brakujące indeksy na tabelach własnych modułów. Prawdopodobnie ich tam brakuje.

4. Użyj Redis dla cache i sesji

Domyślne cache plikowe PrestaShop korzysta pod spodem z blokad systemu plików, co serializuje równoczesne żądania. Przełącz się na Redis, a trzy rzeczy trafiają do RAM:

• Cache Smarty, wynik szablonów przechodzi z odczytów z dysku na odczyty z pamięci.
• Cache Symfony (PrestaShop 8+), trasy, kontenery, adnotacje.
• Sesje PHP, znika problem blokowania plików, który pod obciążeniem ustawia żądania w kolejce.

Jedna instancja Redis 256 MB obsługuje wszystkie trzy obszary w większości sklepów. Poprawa jest największa pod równoczesnym obciążeniem, najmniejsza na sklepie deweloperskim z jednym odwiedzającym. Mierz tam, gdzie ma to znaczenie.

5. Strojenie PHP i OPcache

• PHP 8.1+, 20–40% szybciej niż 7.4. Jeśli nadal jesteś na 7.4, to najtańszy zysk wydajnościowy, jaki kiedykolwiek kupisz.
• OPcache, musi być włączone. Ustaw opcache.validate_timestamps=0 na produkcji i resetuj je ręcznie po wdrożeniach. Reset zdalny w stylu cPanel potrafimy pomylić wystarczająco często, żeby to sobie spisać, zobacz nasze notatki o OPcache i typowych pułapkach.
• Cache realpath, podnieś realpath_cache_size do 4096K. PrestaShop otwiera setki plików przy każdym żądaniu, a bez tego za każdym razem płaci koszt stat().

6. Optymalizacja front-endu

• CCC (Combine, Compress, Cache), łączy CSS i JS w pakiety, zmniejsza liczbę żądań HTTP. Wbudowane w PrestaShop. Włącz, ale obserwuj moduły, które dostarczają zepsuty CSS psujący połączoną paczkę.
• Critical CSS, wstaw style nad linią załamania inline, resztę odłóż. Eliminuje CSS blokujący renderowanie. Automatyzujemy to w Performance Revolution za pomocą Critters, bo ręczne robienie tego per szablon to koszmar.
• Odroczenie JavaScriptu, analityka, widgety czatu, osadzenia społecznościowe trafiają za defer albo requestIdleCallback. Nie muszą blokować LCP.
• Optymalizacja obrazów, WebP/AVIF (25–50% mniejsze niż JPEG), responsywne srcset, jawne width/height na każdym <img>, żeby zapobiegać CLS.
• CDN, buforuj statyczne zasoby na brzegu sieci. To uzupełnienie cache po stronie serwera, nie jego zamiennik.

Efekt łączny

Te elementy się sumują. Usunięcie wolnych modułów oszczędza 500 ms, 2 s. Strojenie MySQL oszczędza 100–300 ms. Redis oszczędza 50–200 ms. PHP 8 + OPcache oszczędza 100–300 ms. Critical CSS przesuwa postrzegane ładowanie o 500 ms, 1 s. Sklep ładujący się 4 sekundy może realnie zejść poniżej 200 ms, renderując świeżo przy każdym żądaniu, świeży stan magazynowy, świeży koszyk, bez hydracji, bez nieaktualnej treści.

To wymaga czasu i wiedzy. Jeśli teraz nie masz ani jednego, ani drugiego, lepszą odpowiedzią jest prawidłowo skonfigurowany moduł FPC.

Podsumowanie

Moduły cache pełnych stron działają. Serwują statyczny HTML i doklejają elementy sesji JavaScriptem, co kosztuje widoczne skoki hydracji, trochę CLS i nieco trudniejsze debugowanie. W zamian dostajesz największy pojedynczy zysk wydajnościowy dostępny w PrestaShop bez ruszania czegokolwiek innego.

Dla sklepów, które potrzebują szybkości dziś i nie mogą pozwolić sobie na głęboki projekt optymalizacyjny, ten kompromis jest właściwy. Dla sklepów, które mają zasoby, by naprawić wolne moduły, dostroić bazę danych, zainstalować Redis i wdrożyć critical CSS, FPC nie robi niczego, czego nie da się przebić zdrowszym stosem pod spodem.

Pragmatyczna ścieżka, którą wybiera większość naszych klientów: zainstalować dobry moduł FPC teraz, zostawić głębsze prace na roadmapie i zdejmować z niej kolejne pozycje, gdy czas pozwala. Ostatecznie możesz wyłączyć cache, albo zostawić je jako drugą linię zabezpieczenia. Tak czy inaczej sklep kończy jako szybki, a Ty dochodzisz tam bez psucia go po drodze.

Najczęściej zadawane pytania

Czy full page cache zepsuje mój koszyk albo realizację zamówienia?

Nie, jeśli jest zbudowane poprawnie, i to jest granica oddzielająca prawdziwy moduł FPC od niebezpiecznego. Koszyk, realizacja zamówienia oraz strony logowania/zalogowanego klienta muszą być całkowicie wyłączone z cache i renderowane na żywo dla każdego odwiedzającego; do cache trafiają tylko anonimowe strony frontu sklepu (strona główna, kategoria, produkt, CMS). Poprawnie skonfigurowany moduł robi to domyślnie. Ryzyko pojawia się w ręcznie pisanych regułach nginx/Varnish, które zapominają wykluczyć te ścieżki, tak kupujący kończy z widokiem koszyka innego klienta.

Dlaczego mój koszyk przez sekundę po załadowaniu strony pokazuje 0?

To etap hydracji i jest nieodłączny dla każdego modułu FPC, a nie błędem jednego z nich. HTML z cache jest bezsesyjny, więc pojawia się z domyślnym stanem sklepu, pusty koszyk, „Zaloguj się”, a kolejne żądanie AJAX dokleja prawdziwą liczbę produktów w koszyku, imię i walutę. Na szybkich urządzeniach jest to niezauważalne; na średniej klasy Androidzie przez 4G widać mignięcie. Zarezerwuj stałą szerokość na plakietkę koszyka i nazwę klienta w kodzie HTML zapisanym w cache, żeby sama podmiana nie kosztowała Cię jeszcze Cumulative Layout Shift.

Zmieniłem cenę, ale nadal widać starą. Czy cache jest zepsute?

Zwykle to opóźnienie unieważniania, nie awaria. Moduły oparte na hookach nasłuchują zdarzeń takich jak actionProductUpdate i czyszczą dotknięte strony, ale część zmian całkowicie omija hooki, na przykład importy ERP zapisujące prosto do bazy danych nie wywołują żadnego hooka, więc cache nigdy nie dowiaduje się, że cena się zmieniła. Jeśli edytujesz w panelu administracyjnym, cache powinno się wyczyścić; jeśli importujesz albo zapisujesz SQL bezpośrednio, wyczyść cache ręcznie albo uruchom ponowne rozgrzanie. Żadne „idealne unieważnianie” nie przetrwa bezpośredniego zapisu do bazy.

Czy użyć cache plików, Redis czy Varnish?

Cache plików wystarcza dla sklepu na jednym serwerze z niewielką równoczesnością, ale blokuje się przy równoczesnych zapisach podczas importów. Redis to nasz domyślny wybór. Bez blokowania plików, działa z workerami PHP, jedna instancja około 256 MB wystarcza, trzeba tylko dostroić maxmemory-policy. Varnish jest najszybszy, bo żądanie nigdy nie dociera do PHP, ale najtrudniej go czysto unieważniać i nie każdy hosting na niego pozwala. Jeśli Twój hosting już uruchamia Varnish, użyj go; w przeciwnym razie moduł na poziomie PHP oparty o Redis da większość zysku przy dużo mniejszym koszcie operacyjnym.

Jeśli naprawię źródłowe spowolnienia, czy mogę usunąć cache?

Tak, to uczciwy cel końcowy. Gdy wolne moduły są naprawione, baza danych dostrojona, Redis obsługuje sesje i cache, a critical CSS jest wdrożony, sklep może renderować świeże strony w niskich setkach milisekund bez skoków hydracji i bez ryzyka nieaktualnej treści. Wtedy FPC jest opcjonalne; wielu zostawia je jako drugą linię zabezpieczenia na skoki ruchu. FPC szybko maskuje problem dziś; naprawa przyczyn źródłowych pozwala przestać maskować.

Powiązane materiały

• Performance Revolution, nasze podejście do FPC w PrestaShop plus critical CSS, CCC i optymalizacja obrazów w jednym module
• Redis Cache Manager & Monitor, gotowa konfiguracja Redis dla cache i sesji PrestaShop
• Strojenie wydajności zapytań do bazy danych PrestaShop, co naprawić, gdy zdecydujesz się wejść głębiej niż FPC