Smarty Cache vs OPcache vs Cache przeglądarki w PrestaShop

Zrozumienie trzech warstw cachowania w PrestaShop

PrestaShop wykorzystuje wiele mechanizmów cachowania do szybkiego dostarczania stron. Każda warstwa działa na innym poziomie stosu, a zrozumienie tego, co każda z nich robi, kiedy się aktywuje i kiedy trzeba ją wyczyścić, jest niezbędne zarówno do optymalizacji wydajności, jak i rozwiązywania problemów. Trzy najważniejsze warstwy cachowania to cache szablonów Smarty, PHP OPcache i cache przeglądarki. Współpracują ze sobą, ale rozwiązują różne problemy i wymagają różnych podejść do zarządzania.

Gdy klient odwiedza Twój sklep, zapytanie przechodzi przez wszystkie trzy warstwy w odwrotnej kolejności. Przeglądarka najpierw sprawdza swoją lokalną pamięć podręczną. Jeśli ma świeżą kopię zasobu, w ogóle nie kontaktuje się z serwerem. Jeśli przeglądarka wyśle zapytanie, przetwarza je PHP. OPcache zapewnia, że pliki PHP są kompilowane raz i ponownie używane z pamięci, a nie parsowane od nowa przy każdym zapytaniu. Wreszcie cache Smarty zapewnia, że renderowanie szablonów, które obejmuje parsowanie składni szablonów i wykonywanie logiki szablonów, zachodzi tylko wtedy, gdy to konieczne, a nie przy każdym załadowaniu strony.

Problemy powstają, gdy te warstwy serwują nieaktualne treści. Zmieniasz plik szablonu, ale strona wygląda tak samo. Aktualizujesz plik PHP, ale stare zachowanie nie ustępuje. Modyfikujesz CSS, ale przeglądarka nadal pokazuje stare style. Każdy z tych symptomów wskazuje na inną warstwę cachowania, a czyszczenie niewłaściwej marnuje czas bez rozwiązania problemu.

Cache szablonów Smarty: Jak działa

Smarty to silnik szablonów, którego PrestaShop używa do renderowania HTML. Każdy plik .tpl w Twoim motywie i modułach przechodzi przez Smarty, zanim stanie się kodem HTML wysyłanym do przeglądarki. Cachowanie Smarty działa w dwóch odrębnych fazach: kompilacja i cachowanie wyjścia.

Kompilacja szablonów

Gdy Smarty napotyka plik .tpl po raz pierwszy, kompiluje go do pliku PHP. Ten skompilowany plik jest przechowywany w katalogu /var/cache/prod/smarty/compile/ (lub /var/cache/dev/smarty/compile/ w trybie debugowania). Skompilowany plik zawiera logikę szablonu przetłumaczoną na czysty PHP, który wykonuje się znacznie szybciej niż parsowanie składni Smarty przy każdym zapytaniu.

Smarty sprawdza, czy skompilowana wersja jest aktualna, porównując znaczniki czasu. Jeśli źródłowy plik .tpl jest nowszy niż wersja skompilowana, Smarty automatycznie go rekompiluje. Jest to kontrolowane przez ustawienie compile_check. W produkcji możesz wyłączyć sprawdzanie kompilacji dla maksymalnej wydajności, co oznacza, że Smarty zakłada, iż skompilowane szablony są zawsze aktualne i nigdy nie sprawdza plików źródłowych.

Cachowanie wyjścia szablonów

Poza kompilacją, Smarty może również cachować wyrenderowane wyjście szablonów. Gdy cachowanie wyjścia jest włączone, Smarty przechowuje końcowy wynik HTML szablonu i serwuje go bezpośrednio przy kolejnych zapytaniach bez wykonywania jakiejkolwiek logiki szablonu. Jest to bardziej agresywne niż cachowanie kompilacji, ponieważ pomija nie tylko krok parsowania, ale również przetwarzanie danych i wykonywanie logiki w szablonie.

Cachowanie wyjścia w PrestaShop jest zarządzane per hook modułu. Każdy moduł może zadeklarować, czy jego wyjście hooka jest cachowalne, a PrestaShop przypisuje klucze cache na podstawie czynników takich jak aktualny język, sklep, waluta i grupa klientów. Oznacza to, że klient francuski i klient angielski otrzymują oddzielne cachowane wersje.

Ustawienia cache Smarty w PrestaShop

Konfigurujesz cachowanie Smarty w back office w sekcji Zaawansowane parametry > Wydajność. Istotne ustawienia to:

Kompilacja szablonów: To kontroluje, jak Smarty obsługuje kompilację szablonów. Opcje to zazwyczaj "Nigdy nie rekompiluj" (najszybsze, zawsze używa wersji skompilowanej), "Rekompiluj jeśli zmieniono" (sprawdza znaczniki czasu plików, dobry balans) i "Wymuszaj kompilację" (rekompiluje przy każdym zapytaniu, tylko do celów deweloperskich). W produkcji używaj "Rekompiluj jeśli zmieniono", chyba że masz pewność, że Twoje szablony nigdy nie zmieniają się pomiędzy wdrożeniami.

Cache: To przełącza cachowanie wyjścia Smarty. Po włączeniu Smarty przechowuje wyrenderowany wynik HTML i serwuje go bez ponownego wykonywania logiki szablonu. Zapewnia to znaczące korzyści wydajnościowe dla sklepów ze złożonymi szablonami lub wieloma hookami modułów.

Optymalizacje multi-front: Włącza cachowanie między wieloma serwerami frontendowymi. Istotne tylko dla konfiguracji klastrowych.

Czyszczenie cache: Opcje obejmują "Nigdy nie czyść plików cache", "Wyczyść cache za każdym razem, gdy coś zostanie zmodyfikowane" oraz konkretne strategie czyszczenia. Dla większości sklepów czyszczenie przy modyfikacji jest właściwym wyborem.

Czyszczenie cache Smarty

Aby wyczyścić cache Smarty ręcznie, możesz użyć przycisku "Wyczyść cache" na stronie Wydajność w back office. Usuwa to skompilowane szablony i cachowane wyjście z katalogu /var/cache/. Możesz również wyczyścić go, usuwając pliki bezpośrednio z serwera.

Musisz wyczyścić cache Smarty, gdy modyfikujesz pliki szablonów .tpl (jeśli sprawdzanie kompilacji jest wyłączone), gdy instalujesz lub aktualizujesz moduł zmieniający szablony, gdy zmieniasz motywy lub gdy modyfikujesz konfigurację związaną z szablonami. Jeśli zmienisz plik .tpl i zmiana nie pojawia się na froncie, cache kompilacji Smarty jest prawie zawsze przyczyną.

PHP OPcache: Jak działa

PHP OPcache to cache bytecodu wbudowany w PHP. Gdy PHP wykonuje skrypt, przechodzi przez trzy etapy: leksing (rozbijanie kodu źródłowego na tokeny), parsowanie (budowanie abstrakcyjnego drzewa składniowego) i kompilacja (generowanie bytecodu, który wykonuje silnik PHP). OPcache przechowuje skompilowany bytecod we współdzielonej pamięci, dzięki czemu kolejne zapytania o ten sam skrypt pomijają te etapy.

To różni się od cache Smarty. Smarty cachuje wyjście renderowania szablonów (HTML). OPcache cachuje wyjście kompilacji PHP (bytecod). Działają na zupełnie różnych poziomach. Szablon Smarty, który został skompilowany do pliku PHP przez Smarty, nadal korzysta z OPcache, ponieważ ten skompilowany plik PHP sam jest cachowany jako bytecod przez OPcache.

Konfiguracja OPcache dla PrestaShop

OPcache jest konfigurowany w pliku php.ini. Najważniejsze ustawienia dla PrestaShop to:

opcache.enable=1 włącza OPcache. To powinno być zawsze włączone w produkcji. Różnica wydajnościowa jest dramatyczna: wykonywanie PHP staje się 2 do 5 razy szybsze z włączonym OPcache.

opcache.memory_consumption=256 ustawia ilość współdzielonej pamięci (w megabajtach) dostępnej do przechowywania skompilowanego bytecodu. PrestaShop z kilkoma modułami może łatwo zużyć 128 MB lub więcej. Ustaw to na 256 MB lub więcej dla sklepów z wieloma modułami.

opcache.max_accelerated_files=20000 ustawia maksymalną liczbę plików PHP, które mogą być cachowane. Rdzeń PrestaShop plus moduły mogą łatwo mieć 10 000 lub więcej plików PHP.

opcache.validate_timestamps=1 nakazuje OPcache sprawdzać, czy pliki źródłowe się zmieniły. W produkcji możesz ustawić to na 0 dla maksymalnej wydajności, ale wtedy musisz restartować PHP-FPM przy każdym wdrożeniu.

opcache.revalidate_freq=60 definiuje, jak często (w sekundach) OPcache sprawdza zmiany plików. Dla produkcji 60 to dobry balans.

opcache.interned_strings_buffer=16 przydziela pamięć na internowane łańcuchy znaków. Ustaw to na 16 MB lub więcej.

opcache.save_comments=1 musi być włączone dla PrestaShop. PrestaShop używa adnotacji PHP DocBlock odczytywanych w czasie wykonania.

OPcache a rozdzielenie CLI i Web

Ważny szczegół dotyczący OPcache polega na tym, że środowiska CLI (wiersz poleceń) i web (PHP-FPM lub mod_php) utrzymują oddzielne pule OPcache. Czyszczenie OPcache z wiersza poleceń nie czyści webowego OPcache. Aby wyczyścić webowy OPcache, musisz albo restartować usługę PHP-FPM, albo wykonać opcache_reset() przez zapytanie webowe.

Ta różnica ma znaczenie w procesach wdrożeniowych. Jeśli wdrożysz nowy kod i wyczyścisz OPcache poleceniem CLI, Twoja witryna nadal serwuje stary bytecod, aż webowy OPcache również zostanie wyczyszczony.

Kiedy czyścić OPcache

Musisz wyczyścić OPcache za każdym razem, gdy modyfikujesz, przesyłasz lub zastępujesz pliki PHP na serwerze. Dotyczy to wdrażania nowej wersji PrestaShop, instalowania lub aktualizowania modułów, edycji plików PHP bezpośrednio na serwerze i aktualizacji zależności Composera. Restart PHP-FPM jest najbardziej niezawodnym sposobem na wyczyszczenie go.

Cache przeglądarki: Jak działa

Cachowanie przeglądarki jest ostatnią warstwą i działa wyłącznie po stronie klienta. Gdy przeglądarka pobiera zasób (plik CSS, JavaScript, obraz, czcionkę lub nawet stronę HTML), może przechować lokalną kopię i użyć jej ponownie przy kolejnych zapytaniach. Całkowicie eliminuje to podróże sieciowe dla cachowanych zasobów, co jest największą możliwą poprawą wydajności.

Cachowanie przeglądarki jest kontrolowane przez nagłówki odpowiedzi HTTP. Najważniejsze nagłówki to Cache-Control, Expires, ETag i Last-Modified.

Nagłówek Cache-Control

max-age=31536000 informuje przeglądarkę, aby cachowała zasób przez do jednego roku. no-cache oznacza, że przeglądarka może cachować zasób, ale musi zwalidować go z serwerem przed użyciem. no-store faktycznie zapobiega cachowaniu. public wskazuje, że odpowiedź może być cachowana przez dowolny cache, w tym CDN-y. private wskazuje, że odpowiedź jest specyficzna dla pojedynczego użytkownika.

Nagłówki ETag i Last-Modified

ETag to unikalny identyfikator konkretnej wersji zasobu. Serwer generuje go i wysyła z odpowiedzią. Przeglądarka odsyła go do walidacji. Last-Modified działa podobnie, ale używa znaczników czasu zamiast hashy.

Konfiguracja cache przeglądarki dla PrestaShop

Zasoby statyczne PrestaShop powinny być agresywnie cachowane przez przeglądarki. Dla Apache używasz modułów mod_expires i mod_headers. Dla Nginx dodajesz dyrektywy expires w blokach location dla plików statycznych.

Cache busting w PrestaShop

Z włączonym CCC, PrestaShop łączy pliki CSS i JavaScript w pakiety i generuje nazwy plików zawierające hash treści. Gdy treść się zmienia, zmienia się nazwa pliku. Bez CCC, niektóre motywy dodają query string z wersją do URL-ów.

Jak trzy warstwy współdziałają

Zrozumienie interakcji tych trzech warstw cachowania jest kluczowe dla efektywnego rozwiązywania problemów. Klient odwiedza stronę produktu. Przeglądarka sprawdza swój cache pod kątem HTML tej strony. Ponieważ HTML jest zazwyczaj serwowany z no-cache, przeglądarka wysyła zapytanie do serwera.

Serwer WWW otrzymuje zapytanie i przekazuje je do PHP. OPcache PHP-FPM ma bytecod plików PrestaShop cachowany we współdzielonej pamięci. PHP wykonuje bytecod bez rekompilacji plików źródłowych.

Kontroler PrestaShop wywołuje Smarty do wyrenderowania szablonu. Smarty sprawdza swój cache. Jeśli istnieje prawidłowy cachowany wynik, Smarty zwraca cachowany HTML bezpośrednio. Jeśli nie, wykonuje skompilowany szablon, generuje HTML i przechowuje go w cache wyjścia.

PHP wysyła odpowiedź HTML do przeglądarki, wraz z nagłówkami HTTP kontrolującymi cachowanie. Przeglądarka renderuje HTML i żąda plików CSS, JavaScript i obrazów. Dla każdego z tych zasobów przeglądarka sprawdza swój lokalny cache.

Rozwiązywanie problemów z nieaktualnymi treściami

Krok 1: Sprawdź przeglądarkę

Otwórz stronę w oknie incognito lub prywatnym, albo wykonaj twarde odświeżenie (Ctrl+Shift+R). Jeśli zmiana pojawia się w trybie incognito, ale nie w normalnym oknie, cache przeglądarki jest przyczyną.

Krok 2: Sprawdź cache Smarty

Jeśli zmiana nie pojawia się nawet w trybie incognito, problem jest po stronie serwera. Dla zmian w szablonach wyczyść cache Smarty z back office lub usuń zawartość var/cache/prod/smarty/.

Krok 3: Sprawdź OPcache

Jeśli wyczyszczenie cache Smarty nie pomaga i zmiana dotyczy pliku PHP, OPcache prawdopodobnie serwuje stary bytecod. Restartuj PHP-FPM lub wywołaj opcache_reset() przez zapytanie webowe.

Krok 4: Sprawdź inne cache

PrestaShop ma dodatkowe mechanizmy cachowania. Cache Symfony przechowuje skompilowane kontenery usług i definicje tras. Jeśli używasz reverse proxy jak Varnish lub CDN jak Cloudflare, te dodają kolejną warstwę cachowania.

Optymalna konfiguracja dla produkcji

Smarty: Ustaw kompilację szablonów na "Rekompiluj jeśli zmieniono". Włącz cachowanie wyjścia. Ustaw czyszczenie cache na "Wyczyść przy modyfikacji".

OPcache: Włącz z co najmniej 256 MB pamięci, 20000 max accelerated files, validate_timestamps włączone z revalidate_freq 60 sekund.

Cache przeglądarki: Ustaw Cache-Control z długimi wartościami max-age dla zasobów statycznych. Używaj no-cache dla odpowiedzi HTML. Włącz CCC w PrestaShop, aby uzyskać automatyczny cache busting.

Z tą konfiguracją Twój sklep korzysta ze wszystkich trzech warstw cachowania współpracujących razem. Zasoby statyczne są serwowane z cache przeglądarki bez kontaktu z serwerem. Pliki PHP są wykonywane z cachowanego bytecodu bez rekompilacji. A renderowanie szablonów jest cachowane, więc logika Smarty uruchamia się tylko, gdy treść się zmienia.

Kiedy czyścić każdą warstwę cache

Wyczyść cache Smarty gdy edytujesz pliki .tpl, zmieniasz pozycje lub hooki modułów, instalujesz lub aktualizujesz moduły zmieniające szablony, lub zmieniasz ustawienia związane z motywem.

Wyczyść OPcache gdy edytujesz pliki PHP, instalujesz lub aktualizujesz moduły, aktualizujesz rdzeń PrestaShop lub uruchamiasz Composer do aktualizacji zależności.

Wyczyść cache przeglądarki gdy musisz natychmiast zobaczyć zmiany CSS, JavaScript lub obrazów podczas rozwoju. Dla produkcji polegaj na cache busting zamiast prosić użytkowników o czyszczenie ich cache.

Kompleksowa sekwencja czyszczenia cache po dużym wdrożeniu: wyczyść katalogi kompilacji i cache Smarty, restartuj PHP-FPM aby wyczyścić OPcache, oczyść cache CDN lub reverse proxy jeśli dotyczy, i zweryfikuj w oknie incognito przeglądarki. Dla drobnych zmian wystarczy wyczyścić tylko odpowiednią warstwę.