Varnish Cache dla PrestaShop: Kiedy moduły Full Page Cache nie wystarczają

Czym jest Varnish i dlaczego ma znaczenie dla PrestaShop

Varnish Cache to odwrotne proxy HTTP (reverse proxy), które znajduje się pomiędzy serwerem www a internetem i serwuje zbuforowane kopie stron bez jakiegokolwiek kontaktu z PHP czy MySQL. Gdy odwiedzający żąda strony, którą Varnish ma w cache, odpowiedź pochodzi bezpośrednio z pamięci operacyjnej w ciągu mikrosekund. PHP nie jest uruchamiane. MySQL nie otrzymuje żadnego zapytania. Serwer WWW praktycznie nie zauważa, że żądanie miało miejsce.

To podejście jest zasadniczo różne od tego, jak działają moduły pełnego buforowania stron (FPC) oparte na PHP w PrestaShop. Moduł FPC nadal działa w ramach PHP. Żądanie trafia do Apache lub Nginx, PHP się uruchamia, PrestaShop inicjalizuje się (ładuje konfigurację, nawiązuje połączenia z bazą danych, parsuje trasy), a następnie moduł FPC przechwytuje żądanie zanim pełna logika kontrolera zostanie uruchomiona, serwując buforowany plik HTML. Choć jest to znacznie szybsze niż renderowanie strony od zera, nadal wymaga uruchomienia PHP i załadowania frameworka PrestaShop. Ten narzut, wynoszący zazwyczaj 50-200 milisekund nawet przy trafieniu w cache, kumuluje się pod obciążeniem.

Varnish całkowicie eliminuje ten narzut. Trafienie w cache Varnish jest serwowane w 1-5 milisekund. Przy dużym ruchu różnica jest dramatyczna. Sklep PrestaShop, który z trudem obsługuje 100 jednoczesnych użytkowników z modułem FPC, może obsłużyć tysiące jednoczesnych użytkowników z Varnishem, ponieważ zdecydowana większość żądań nigdy nie dociera do backendu PHP.

Kiedy moduły PHP Full Page Cache są wystarczające

Zanim zainwestujesz w Varnish, warto zrozumieć, kiedy moduł FPC oparty na PHP jest wystarczająco dobry. Dla wielu sklepów PrestaShop tak właśnie jest.

Jeśli Twój sklep generuje mniej niż 50 000 dziennych wyświetleń stron, dobrze skonfigurowany moduł FPC poradzi sobie z obciążeniem bez problemów. Dodatkowa złożoność Varnisha nie jest uzasadniona, gdy serwer dysponuje rezerwą mocy obliczeniowej. Jeśli czasy odpowiedzi serwera z FPC są konsekwentnie poniżej 200 milisekund, Twoi odwiedzający już otrzymują szybkie ładowanie stron. Wąskim gardłem w tym momencie jest prawdopodobnie renderowanie po stronie frontendu (CSS, JavaScript, obrazy), a nie czas odpowiedzi serwera.

Moduły FPC radzą sobie z niektórymi scenariuszami specyficznymi dla PrestaShop bardziej elegancko niż Varnish, ponieważ działają wewnątrz aplikacji. Mogą sprawdzić, czy użytkownik jest zalogowany, czy koszyk zawiera produkty i czy pewna dynamiczna treść wymaga personalizacji — wszystko w ramach tego samego procesu PHP. W przypadku Varnisha te sprawdzenia muszą być obsługiwane przez inspekcję ciasteczek i reguły wariacji cache, co dodaje złożoności konfiguracyjnej.

Rozważ Varnish, gdy Twój sklep regularnie obsługuje skoki ruchu (wyprzedaże błyskawiczne, kampanie marketingowe, szczyty sezonowe), które przeciążają moce PHP, gdy potrzebujesz czasów odpowiedzi poniżej 10 ms ze względu na SEO lub doświadczenie użytkownika, gdy budżet na hosting jest ograniczony i musisz obsłużyć większy ruch na tym samym sprzęcie, lub gdy sklep obsługuje wysoki stosunek anonimowego przeglądania (strony kategorii, strony produktów) w stosunku do aktywności koszyka i kasy.

Jak działa Varnish: Przepływ żądań

Zrozumienie przepływu żądań przez Varnish jest kluczowe dla prawidłowej konfiguracji z PrestaShop.

Przychodzące żądanie

Gdy odwiedzający żąda strony, żądanie trafia najpierw do Varnisha (Varnish nasłuchuje na porcie 80 lub 443, jeśli zakończenie SSL jest obsługiwane przez proxy frontendowe). Varnish analizuje żądanie: URL, metodę HTTP, ciasteczka i nagłówki.

Wyszukiwanie w cache

Varnish sprawdza swój cache pod kątem zapisanej odpowiedzi pasującej do tego żądania. Klucz cache jest zwykle oparty na URL i wybranych nagłówkach. Jeśli pasująca odpowiedź istnieje i nie wygasła, Varnish serwuje ją bezpośrednio. To jest trafienie w cache (cache hit). Odpowiedź jest wysyłana do odwiedzającego, a serwer backendowy nie jest w ogóle kontaktowany.

Pudło cache

Jeśli brak pasującej zbuforowanej odpowiedzi, Varnish przekazuje żądanie do serwera backendowego (Apache lub Nginx z PrestaShop). PrestaShop przetwarza żądanie normalnie, generuje odpowiedź HTML i odsyła ją do Varnisha. Varnish zapisuje odpowiedź w swoim cache (jeśli odpowiedź nadaje się do buforowania) i przekazuje ją odwiedzającemu. Kolejne żądania tej samej strony będą serwowane z cache.

Inwalidacja cache

Gdy dane produktu się zmienią, ceny zostaną zaktualizowane lub treść zostanie zmodyfikowana, wersja w cache staje się nieaktualna. Varnish musi zostać poinformowany o konieczności odrzucenia starej wersji z cache, aby pobrał świeżą z backendu. To jest inwalidacja cache, i jest to najtrudniejsza część każdego systemu buforowania do prawidłowego wdrożenia.

Konfiguracja VCL dla PrestaShop

Varnish Configuration Language (VCL) to język specyficzny dla domeny, który kontroluje sposób obsługi żądań przez Varnish. Prawidłowa konfiguracja VCL dla PrestaShop musi obsługiwać kilka zachowań specyficznych dla PrestaShop.

Definicja backendu

Definicja backendu informuje Varnish, dokąd przekazywać pudła cache. Dla typowej konfiguracji PrestaShop, gdzie Apache lub Nginx działa na tym samym serwerze na porcie 8080:

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .connect_timeout = 5s;
  .first_byte_timeout = 60s;
  .between_bytes_timeout = 10s;
}

Timeouty są ważne. Strony PrestaShop mogą potrzebować kilku sekund na wygenerowanie przy zimnym cache, szczególnie strony kategorii z wieloma produktami. Ustawienie first_byte_timeout zbyt nisko powoduje, że Varnish zwraca błąd 503 zanim PrestaShop zdąży wygenerować stronę.

Obsługa ciasteczek i sesji

Ciasteczka są największym wyzwaniem przy buforowaniu PrestaShop z Varnishem. PrestaShop ustawia domyślnie kilka ciasteczek, a Varnish traktuje każde żądanie z ciasteczkami jako niebuforowalne, chyba że poinstruujemy go inaczej. Jeśli nie obsłużysz ciasteczek w swoim VCL, Varnish nie będzie buforował praktycznie niczego.

PrestaShop ustawia te ciasteczka przy większości żądań: ciasteczko sesji (zwykle o nazwie PrestaShop-xxxx), ciasteczka związane z koszykiem, ciasteczka Google Analytics (_ga, _gid, _gat) oraz różne ciasteczka śledzące od narzędzi marketingowych. Spośród nich tylko ciasteczko sesji PrestaShop ma znaczenie dla zachowania cache. Ciasteczka analityczne i śledzące powinny być usuwane z żądania przed wyszukiwaniem w cache, aby nie uniemożliwiały buforowania.

W podprocedurze VCL vcl_recv usuń nieistotne ciasteczka:

sub vcl_recv {
  # Usuń ciasteczka Google Analytics i inne śledzące
  set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_ga|_gid|_gat|__utm[a-z]+|_fbp|_gcl_[a-z]+)=[^;]*", "");
  # Usuń pusty nagłówek ciasteczka
  if (req.http.Cookie ~ "^\s*$") {
    unset req.http.Cookie;
  }
}

Decydowanie, co buforować

Nie każda strona PrestaShop powinna być buforowana. VCL musi rozróżniać między żądaniami buforowalnymi i niebuforowalnymi.

Zawsze buforuj: Strony produktów dla anonimowych odwiedzających, strony z listą kategorii, strony CMS (o nas, regulamin, kontakt), stronę główną, strony producentów i dostawców, strony mapy witryny.

Nigdy nie buforuj: Strony koszyka, strony kasy (wszystkie kroki), obszaru konta klienta (zamówienia, adresy, dane osobowe), stron logowania i rejestracji, żadnej strony dla zalogowanego klienta, żądań POST, żądań AJAX modyfikujących stan (dodaj do koszyka, aktualizuj ilość).

Logika VCL do tego celu zwykle sprawdza ścieżkę URL i obecność ciasteczek sesji:

sub vcl_recv {
  # Nie buforuj żądań POST
  if (req.method == "POST") {
    return (pass);
  }
  # Nie buforuj panelu administracyjnego
  if (req.url ~ "^/admin") {
    return (pass);
  }
  # Nie buforuj kasy i koszyka
  if (req.url ~ "(cart|order|login|my-account|module/)" ) {
    return (pass);
  }
  # Nie buforuj, jeśli klient ma produkty w koszyku
  if (req.http.Cookie ~ "PrestaShop-") {
    return (pass);
  }
  return (hash);
}

Ustawianie czasu życia cache

W podprocedurze vcl_backend_response kontrolujesz, jak długo Varnish buforuje każdą odpowiedź. PrestaShop wysyła nagłówki Cache-Control, które zwykle mówią no-cache lub private, ponieważ zakłada, że każda odpowiedź może zawierać spersonalizowaną treść. Musisz je nadpisać dla stron, o których wiesz, że są bezpieczne do buforowania:

sub vcl_backend_response {
  # Buforuj strony produktów i kategorii przez 1 godzinę
  if (bereq.url ~ "^/([0-9]+-|[a-z]+-[0-9]+)") {
    set beresp.ttl = 1h;
    unset beresp.http.Set-Cookie;
  }
  # Buforuj zasoby statyczne przez 1 dzień
  if (bereq.url ~ "\.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf)$") {
    set beresp.ttl = 1d;
    unset beresp.http.Set-Cookie;
  }
}

Usuwanie Set-Cookie z buforowanych odpowiedzi jest krytyczne. Jeśli buforowana odpowiedź zawiera nagłówek Set-Cookie, Varnish domyślnie jej nie zbuforuje, a nawet jeśli zostanie zmuszony do buforowania, ustawi to samo ciasteczko sesji dla każdego odwiedzającego, powodując przechwycenie sesji (session hijacking).

Inwalidacja cache za pomocą żądań PURGE

Gdy cena produktu się zmienia, nowy produkt jest dodawany lub treść jest aktualizowana, buforowana wersja musi zostać unieważniona. Varnish obsługuje żądania PURGE: specjalną metodę HTTP, która informuje Varnish o konieczności usunięcia konkretnego URL z cache.

Konfiguracja obsługi PURGE

Dodaj obsługę PURGE do swojego VCL:

acl purge {
  "127.0.0.1";
  "localhost";
}

sub vcl_recv {
  if (req.method == "PURGE") {
    if (!client.ip ~ purge) {
      return (synth(405, "Not allowed."));
    }
    return (purge);
  }
}

ACL ogranicza żądania PURGE do localhost, uniemożliwiając zewnętrznym użytkownikom czyszczenie Twojego cache.

Wyzwalanie operacji purge z PrestaShop

PrestaShop natywnie nie wysyła żądań PURGE. Potrzebujesz modułu lub niestandardowego hooka, który wykrywa zmiany w treści nadającej się do buforowania i wysyła żądanie PURGE do Varnisha. Moduł podpina się pod zdarzenia PrestaShop takie jak actionProductUpdate, actionCategoryUpdate i actionCMSPageUpdate. Gdy te zdarzenia są wywoływane, moduł wysyła żądanie HTTP PURGE na odpowiedni URL serwera Varnish.

Przy aktualizacji produktu moduł powinien wyczyścić URL produktu, URL kategorii, do których produkt należy (ponieważ strony z listą kategorii wyświetlają ceny i dostępność produktów) oraz potencjalnie stronę główną, jeśli wyświetla polecane produkty. Ta kaskada operacji purge jest konieczna, aby zapobiec wyświetlaniu nieaktualnych danych w dowolnym miejscu witryny.

Inwalidacja oparta na BAN

W scenariuszach, gdy wiele URL-i wymaga jednoczesnego wyczyszczenia (aktualizacja cen w całej witrynie, zmiana designu, nowy baner promocyjny), indywidualne żądania PURGE są niepraktyczne. Varnish obsługuje bany, czyli reguły inwalidacji oparte na wzorcach. Ban informuje Varnish o konieczności odrzucenia każdego zbuforowanego obiektu pasującego do wzorca:

sub vcl_recv {
  if (req.method == "BAN") {
    if (!client.ip ~ purge) {
      return (synth(405, "Not allowed."));
    }
    ban("req.url ~ " + req.http.X-Ban-Pattern);
    return (synth(200, "Banned."));
  }
}

Wysłanie żądania BAN z nagłówkiem X-Ban-Pattern: /category/ unieważni wszystkie zbuforowane strony kategorii w jednej operacji.

Edge Side Includes (ESI) dla bloków dynamicznych

Wiele stron PrestaShop zawiera mieszankę treści statycznej i dynamicznej. Lista produktów na stronie kategorii jest taka sama dla każdego odwiedzającego, ale nagłówek pokazujący liczbę produktów w koszyku jest spersonalizowany. Bez ESI nie można buforować strony w ogóle, ponieważ dynamiczny nagłówek sprawia, że cała odpowiedź jest specyficzna dla odwiedzającego.

Edge Side Includes rozwiązują to, pozwalając na oznaczenie sekcji strony jako osobno pobieranych fragmentów. Varnish składa finalną stronę z fragmentów buforowanych i niebuforowanych.

Jak działa ESI

W szablonie Smarty, zamiast renderować widget koszyka bezpośrednio, umieszczasz tag ESI:

<esi:include src="/module/cartwidget/ajax" />

Gdy Varnish przetwarza buforowaną stronę, napotyka tag ESI i wysyła osobne żądanie do backendu po ten fragment. Główne ciało strony jest serwowane z cache, podczas gdy widget koszyka jest pobierany świeżo z PrestaShop. Złożona odpowiedź zawiera zarówno buforowane ciało, jak i świeży widget koszyka.

Włącz przetwarzanie ESI w swoim VCL:

sub vcl_backend_response {
  set beresp.do_esi = true;
}

Aspekty ESI dla PrestaShop

Wdrożenie ESI wymaga modyfikacji szablonów PrestaShop w celu oddzielenia dynamicznej treści na fragmenty kompatybilne z ESI. Każdy fragment potrzebuje własnego endpointu URL, który zwraca tylko HTML dla tego bloku. Fragmenty, które są zwykle dynamiczne i wymagają obsługi ESI, to: widget podsumowania koszyka (liczba produktów, suma), powitanie klienta ("Cześć, Jan"), wszelkie spersonalizowane rekomendacje produktów, link logowania/wylogowania oraz ostatnio przeglądane produkty.

Nakład pracy wymagany do prawidłowego wdrożenia ESI jest znaczny. Każdy dynamiczny fragment potrzebuje dedykowanego kontrolera, szablony wymagają restrukturyzacji, a reguły buforowania dla każdego fragmentu wymagają indywidualnego dostrojenia. To jeden z powodów, dla których Varnish jest uważany za zaawansowaną optymalizację — działa najlepiej, gdy aplikacja jest projektowana z myślą o nim.

Kontrole zdrowia backendu

Varnish może monitorować stan serwera backendowego i podejmować działania, gdy staje się niedostępny. Konfiguruje się to w definicji backendu:

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .probe = {
    .url = "/ping.php";
    .timeout = 2s;
    .interval = 5s;
    .window = 5;
    .threshold = 3;
  }
}

Varnish wysyła żądanie do /ping.php co 5 sekund. Jeśli 3 z ostatnich 5 sprawdzeń zakończy się niepowodzeniem, Varnish oznacza backend jako chory. Gdy backend jest chory, Varnish może serwować nieaktualną treść z cache (tryb grace) zamiast zwracać błędy odwiedzającym. Oznacza to, że Twój sklep pozostaje częściowo dostępny nawet gdy backend PHP ulega awarii lub jest restartowany.

Konfiguracja trybu grace określa, jak długo Varnish będzie serwował nieaktualną treść:

sub vcl_backend_response {
  set beresp.grace = 6h;
}

Z 6-godzinnym grace, jeśli Twój backend padnie, odwiedzający zobaczą buforowane strony (nawet jeśli mają do 6 godzin) zamiast stron błędów. Ceny produktów mogą być nieznacznie nieaktualne, ale sklep pozostaje funkcjonalny, dopóki naprawiasz problem z backendem.

Benchmarki wydajności

Różnica wydajności między brakiem cache, PHP FPC i Varnishem jest znaczna i mierzalna.

Bez cache (czysty PrestaShop): Typowa strona produktu PrestaShop generuje się w 200-800 milisekund, w zależności od sprzętu serwera, liczby załadowanych modułów i liczby zapytań do bazy danych. Pod obciążeniem czasy odpowiedzi rosną, ponieważ workery PHP są nasycone. Pojedynczy serwer może obsłużyć 20-50 jednoczesnych użytkowników, zanim czasy odpowiedzi staną się nie do zaakceptowania.

Moduł PHP FPC: Trafienia w cache serwowane są w 30-100 milisekund, ponieważ PHP nadal się uruchamia, a framework częściowo inicjalizuje. Pod obciążeniem wydajność jest znacznie lepsza, ponieważ buforowane odpowiedzi wymagają minimalnego czasu przetwarzania PHP. Pojedynczy serwer może obsłużyć 200-500 jednoczesnych użytkowników w zależności od konfiguracji. Pudła cache nadal trwają pełny czas renderowania.

Varnish: Trafienia w cache serwowane są w 1-5 milisekund. Pod obciążeniem sam Varnish może obsłużyć tysiące jednoczesnych połączeń, ponieważ jest napisany w C i zaprojektowany specjalnie do tego obciążenia. Serwer backendowy obsługuje tylko pudła cache, które stanowią niewielki ułamek całkowitego ruchu w prawidłowo skonfigurowanym systemie. Ten sam sprzęt, który z trudem obsługuje 50 jednoczesnych użytkowników bez buforowania, może obsłużyć 5000 lub więcej z Varnishem.

Te liczby ilustrują, dlaczego Varnish jest wart złożoności konfiguracyjnej dla sklepów o dużym ruchu. Poprawa wydajności nie jest przyrostowa — jest o rząd wielkości.

Wymagania hostingowe

Varnish ma specyficzne wymagania hostingowe, których nie każde środowisko hostingowe PrestaShop może spełnić.

Dostęp do serwera

Potrzebujesz dostępu root, aby zainstalować i skonfigurować Varnish. Plany hostingu współdzielonego nie obsługują Varnisha, ponieważ wymaga on własnego procesu nasłuchującego na porcie i przechwytującego cały ruch HTTP. Potrzebujesz VPS, serwera dedykowanego lub instancji chmurowej, gdzie kontrolujesz pełny stos serwerowy.

Pamięć operacyjna

Varnish przechowuje swój cache w RAM. Ilość potrzebnej pamięci RAM zależy od liczby unikalnych stron w Twoim katalogu i rozmiaru każdej buforowanej odpowiedzi. Przybliżony wzór: liczba stron nadających się do buforowania pomnożona przez średni rozmiar strony daje minimalny rozmiar cache. Sklep z 5000 produktami, 200 kategoriami i średnim rozmiarem strony 50 KB potrzebuje około 260 MB pamięci cache. Dodaj narzut na sam Varnish i powinieneś przydzielić co najmniej 512 MB. Dla większych katalogów typowe jest 1-2 GB.

Konfiguracja portów

W standardowej konfiguracji Varnish nasłuchuje na porcie 80 (domyślny port HTTP) i przekazuje pudła cache do serwera www na innym porcie (zwykle 8080). Oznacza to, że musisz przekonfigurować Apache lub Nginx, aby nasłuchiwał na porcie 8080 zamiast 80. Jeśli używasz HTTPS (a powinieneś), zazwyczaj umieszczasz Nginx przed Varnishem do obsługi zakończenia SSL: Nginx na porcie 443 kończy SSL i przekazuje do Varnisha na porcie 80, który przekazuje pudła cache do Apache lub PHP-FPM na porcie 8080.

Przykład konfiguracji Docker

Uruchomienie Varnisha w Dockerze obok kontenera PrestaShop to czysty sposób na dodanie Varnisha do istniejącej konfiguracji bez modyfikowania systemu hosta.

Konfiguracja Docker Compose

Podstawowa konfiguracja Docker Compose z Varnishem, Nginx do SSL i PrestaShop:

services:
  varnish:
    image: varnish:7.4
    ports:
      - "80:80"
    volumes:
      - ./varnish/default.vcl:/etc/varnish/default.vcl:ro
    environment:
      - VARNISH_SIZE=512m
    depends_on:
      - prestashop
  prestashop:
    image: prestashop/prestashop:8
    expose:
      - "80"
    environment:
      - DB_SERVER=db
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=secretpassword
      - MYSQL_DATABASE=prestashop

W tej konfiguracji Varnish jest punktem wejściowym na porcie 80. Kontener PrestaShop nie eksponuje swojego portu na hosta, tylko na sieć Dockera. Hostem backendu VCL byłby prestashop (nazwa usługi Docker) na porcie 80.

VCL dla Dockera

Definicja backendu VCL dla Dockera używa nazwy usługi zamiast localhost:

backend default {
  .host = "prestashop";
  .port = "80";
}

Wewnętrzne DNS Dockera rozwiązuje nazwę usługi na IP kontenera. Reszta konfiguracji VCL pozostaje taka sama jak w konfiguracji bez Dockera.

Przechowywanie cache w Dockerze

Domyślnie obraz Docker Varnish używa przechowywania w pamięci (malloc), co jest idealne dla wydajności. Zmienna środowiskowa VARNISH_SIZE kontroluje, ile pamięci Varnish przydziela na swój cache. Ustaw tę wartość na taką, która mieści się w limitach pamięci kontenera, pozostawiając miejsce na sam proces Varnish.

Dla trwałego cache, który przetrwa restarty kontenera, możesz użyć przechowywania plikowego montując wolumen, ale jest to rzadko konieczne. Cache rozgrzewa się szybko (w ciągu minut od otrzymania ruchu), a przechowywanie plikowe jest wolniejsze niż przechowywanie w pamięci.

Monitorowanie wydajności Varnisha

Varnish zapewnia wbudowane narzędzia do monitorowania wydajności cache.

Polecenie varnishstat pokazuje statystyki w czasie rzeczywistym, w tym współczynnik trafień cache, połączenia z backendem i wykorzystanie pamięci. Najważniejszą metryką jest współczynnik trafień, który powinien wynosić 85% lub więcej dla dobrze skonfigurowanego systemu. Jeśli współczynnik trafień jest poniżej 70%, przejrzyj reguły VCL, ponieważ zbyt wiele żądań przechodzi do backendu.

Polecenie varnishlog pokazuje szczegółowe logi per żądanie, które są nieocenione przy debugowaniu, dlaczego konkretne żądania nie są buforowane. Możesz filtrować po wzorcu URL, kodzie odpowiedzi lub statusie trafienia/pudła cache.

Polecenie varnishtop pokazuje rankingową listę najczęstszych wpisów w logach, pomagając identyfikować wzorce w pudłach cache lub błędach.

Typowe pułapki

Zapominanie o usuwaniu ciasteczek

Najczęstszą błędną konfiguracją Varnisha z PrestaShop jest nieusuwanie ciasteczek analitycznych i śledzących. Te ciasteczka są obecne w praktycznie każdym żądaniu i sprawiają, że każde żądanie jest unikalne z perspektywy Varnisha, co skutkuje 0% współczynnikiem trafień. Zawsze usuwaj ciasteczka, których nie potrzebujesz do wariacji cache.

Buforowanie spersonalizowanej treści

Jeśli Twój VCL jest zbyt agresywny, będzie buforować strony zawierające spersonalizowaną treść (powitanie zalogowanego użytkownika, zawartość koszyka) i serwować je innym odwiedzającym. Powoduje to poważne problemy z użytecznością i potencjalne problemy z prywatnością. Zawsze przekazuj żądania zawierające ciasteczka sesji do backendu.

Brak inwalidacji przy zmianach treści

Bez odpowiedniego mechanizmu czyszczenia cache zmiany treści w panelu administracyjnym nie będą widoczne, dopóki buforowane strony nie wygasną naturalnie. Dla sklepu z aktywnymi zmianami stanów magazynowych oznacza to, że odwiedzający mogą widzieć produkty niedostępne, błędne ceny lub nieaktualne opisy. Wdróż obsługę PURGE lub BAN i zintegruj ją z hookami aktualizacji PrestaShop.

Ignorowanie HTTPS

Varnish natywnie nie obsługuje SSL. Musisz umieścić proxy kończące SSL (Nginx, HAProxy lub chmurowy load balancer) przed Varnishem. Brak zaplanowania tego w architekturze prowadzi do problemów z mieszaną treścią (mixed content), pętli przekierowań lub niemożności serwowania ruchu HTTPS w ogóle.

Czy Varnish jest odpowiedni dla Twojego sklepu

Varnish to potężne narzędzie, ale nie jest właściwym wyborem dla każdego sklepu PrestaShop. Dodaje złożoność operacyjną: kolejną usługę do monitorowania, kolejny język konfiguracyjny do nauki, kolejną warstwę w procesie debugowania. Korzyści są jasne i mierzalne dla sklepów, które ich potrzebują, ale wiążą się z kosztem w postaci czasu konfiguracji, konserwacji i trudności w rozwiązywaniu problemów.

Jeśli Twój sklep obsługuje mniej niż 50 000 wyświetleń stron dziennie, a serwer radzi sobie z obciążeniem komfortowo z modułem FPC, Varnish to niepotrzebna złożoność. Jeśli Twój sklep regularnie mierzy się ze skokami ruchu, które przeciążają serwer, obsługuje dużą ilość anonimowego ruchu przeglądania lub potrzebuje najszybszych możliwych czasów odpowiedzi dla SEO czy doświadczenia użytkownika, Varnish zapewnia poziom wydajności, którego żadne rozwiązanie buforowania oparte na PHP nie jest w stanie dorównać.

Zacznij od właściwej optymalizacji PrestaShop (optymalizacja zapytań, audyt modułów, PHP OPcache, optymalizacja obrazów) i modułu FPC. Jeśli te optymalizacje nie wystarczą, Varnish jest kolejnym krokiem na drabinie skalowania wydajności.