Varnish Cache für PrestaShop: Wenn Full Page Cache Module nicht mehr ausreichen

Was Varnish ist und warum es für PrestaShop wichtig ist

Varnish Cache ist ein HTTP-Reverse-Proxy, der zwischen Ihrem Webserver und dem Internet sitzt und gecachte Kopien von Seiten ausliefert, ohne jemals PHP oder MySQL zu berühren. Wenn ein Besucher eine Seite anfordert, die Varnish zwischengespeichert hat, kommt die Antwort direkt aus dem Arbeitsspeicher – in Mikrosekunden. PHP wird nicht ausgeführt. MySQL erhält keine Abfrage. Der Webserver bemerkt die Anfrage kaum.

Dies unterscheidet sich grundlegend von der Funktionsweise PHP-basierter Full Page Cache (FPC) Module in PrestaShop. Ein FPC-Modul läuft weiterhin innerhalb von PHP. Die Anfrage trifft auf Apache oder Nginx, PHP startet, PrestaShop initialisiert sich (Konfiguration laden, Datenbankverbindungen aufbauen, Routen parsen), und dann fängt das FPC-Modul die Anfrage ab, bevor die vollständige Controller-Logik ausgeführt wird, und liefert eine gecachte HTML-Datei. Dies ist zwar deutlich schneller als die Seite von Grund auf zu rendern, beinhaltet aber immer noch den Start von PHP und das Laden des PrestaShop-Frameworks. Dieser Overhead von typischerweise 50–200 Millisekunden selbst bei einem Cache-Hit summiert sich unter Last.

Varnish eliminiert diesen Overhead vollständig. Ein Varnish-Cache-Hit wird in 1–5 Millisekunden ausgeliefert. Bei hohem Traffic ist der Unterschied dramatisch. Ein PrestaShop-Shop, der mit einem FPC-Modul Schwierigkeiten hat, 100 gleichzeitige Benutzer zu bedienen, kann mit Varnish Tausende von gleichzeitigen Benutzern versorgen, da die überwiegende Mehrheit der Anfragen das PHP-Backend überhaupt nicht erreicht.

Wann PHP Full Page Cache Module ausreichend sind

Bevor Sie in Varnish investieren, lohnt es sich zu verstehen, wann ein PHP-basiertes FPC-Modul ausreicht. Für viele PrestaShop-Shops ist das der Fall.

Wenn Ihr Shop weniger als 50.000 tägliche Seitenaufrufe verzeichnet, wird ein gut konfiguriertes FPC-Modul die Last problemlos bewältigen. Die zusätzliche Komplexität von Varnish ist nicht gerechtfertigt, wenn Ihr Server über Reservekapazität verfügt. Wenn Ihre Server-Antwortzeiten mit FPC konstant unter 200 Millisekunden liegen, erhalten Ihre Besucher bereits schnelle Seitenladezeiten. Der Engpass liegt an diesem Punkt wahrscheinlich beim Frontend-Rendering (CSS, JavaScript, Bilder) und nicht bei der Serverantwortzeit.

FPC-Module handhaben einige PrestaShop-spezifische Szenarien auch eleganter als Varnish, da sie innerhalb der Anwendung laufen. Sie können prüfen, ob ein Benutzer eingeloggt ist, ob der Warenkorb Artikel enthält und ob bestimmte dynamische Inhalte personalisiert werden müssen – alles innerhalb desselben PHP-Prozesses. Bei Varnish müssen diese Prüfungen über Cookie-Inspektion und Cache-Variationsregeln gehandhabt werden, was die Konfigurationskomplexität erhöht.

Ziehen Sie Varnish in Betracht, wenn Ihr Shop regelmäßig mit Traffic-Spitzen konfrontiert ist (Flash-Sales, Marketingkampagnen, saisonale Spitzen), die Ihre PHP-Kapazität überlasten, wenn Sie aus SEO- oder User-Experience-Gründen Antwortzeiten unter 10 ms benötigen, wenn Ihr Hosting-Budget begrenzt ist und Sie mehr Traffic mit derselben Hardware bedienen müssen, oder wenn Ihr Shop einen hohen Anteil an anonymem Browsing-Traffic (Kategorieseiten, Produktseiten) im Verhältnis zur Warenkorb- und Checkout-Aktivität aufweist.

Wie Varnish funktioniert: Der Request-Flow

Das Verständnis des Anfrage-Flows durch Varnish ist wesentlich für die korrekte Konfiguration mit PrestaShop.

Anfrage kommt an

Wenn ein Besucher eine Seite anfordert, trifft die Anfrage zuerst auf Varnish (Varnish lauscht auf Port 80 oder 443, wenn es durch einen Frontend-Proxy terminiert wird). Varnish untersucht die Anfrage: die URL, die HTTP-Methode, die Cookies und die Header.

Cache-Lookup

Varnish prüft seinen Cache auf eine gespeicherte Antwort, die zu dieser Anfrage passt. Der Cache-Schlüssel basiert typischerweise auf der URL und ausgewählten Headern. Wenn eine passende Antwort existiert und nicht abgelaufen ist, liefert Varnish sie direkt aus. Dies ist ein Cache-Hit. Die Antwort wird an den Besucher gesendet, und der Backend-Server wird niemals kontaktiert.

Cache-Miss

Wenn keine passende gecachte Antwort existiert, leitet Varnish die Anfrage an den Backend-Server weiter (Apache oder Nginx, auf dem PrestaShop läuft). PrestaShop verarbeitet die Anfrage normal, generiert die HTML-Antwort und sendet sie an Varnish zurück. Varnish speichert die Antwort in seinem Cache (wenn die Antwort cache-fähig ist) und leitet sie an den Besucher weiter. Nachfolgende Anfragen für dieselbe Seite werden aus dem Cache bedient.

Cache-Invalidierung

Wenn sich Produktdaten ändern, Preise aktualisiert werden oder Inhalte modifiziert werden, wird die gecachte Version veraltet. Varnish muss angewiesen werden, die alte gecachte Version zu verwerfen, damit es eine frische vom Backend holt. Das ist die Cache-Invalidierung, und sie ist der schwierigste Teil jedes Caching-Systems, um ihn richtig hinzubekommen.

VCL-Konfiguration für PrestaShop

Varnish Configuration Language (VCL) ist eine domänenspezifische Sprache, die steuert, wie Varnish Anfragen behandelt. Eine ordnungsgemäße VCL-Konfiguration für PrestaShop muss mehrere PrestaShop-spezifische Verhaltensweisen berücksichtigen.

Backend-Definition

Die Backend-Definition teilt Varnish mit, wohin Cache-Misses weitergeleitet werden sollen. Für ein typisches PrestaShop-Setup, bei dem Apache oder Nginx auf demselben Server auf Port 8080 läuft:

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

Die Timeouts sind wichtig. PrestaShop-Seiten können bei einem kalten Cache mehrere Sekunden zur Generierung benötigen, insbesondere Kategorieseiten mit vielen Produkten. Ein zu niedriger first_byte_timeout-Wert führt dazu, dass Varnish einen 503-Fehler zurückgibt, bevor PrestaShop die Seitengenerierung abgeschlossen hat.

Umgang mit Cookies und Sitzungen

Cookies sind die größte Herausforderung beim Caching von PrestaShop mit Varnish. PrestaShop setzt standardmäßig mehrere Cookies, und Varnish behandelt jede Anfrage mit Cookies als nicht cache-fähig, sofern nicht anders angewiesen. Wenn Sie Cookies in Ihrer VCL nicht behandeln, wird Varnish fast nichts cachen.

PrestaShop setzt bei den meisten Anfragen folgende Cookies: das Sitzungs-Cookie (typischerweise PrestaShop-xxxx genannt), die warenkorbebezogenen Cookies, Google Analytics Cookies (_ga, _gid, _gat) und verschiedene Tracking-Cookies von Marketing-Tools. Von diesen ist nur das PrestaShop-Sitzungs-Cookie für das Cache-Verhalten relevant. Analytics- und Tracking-Cookies sollten vor dem Cache-Lookup aus der Anfrage entfernt werden, damit sie das Caching nicht verhindern.

In Ihrer VCL-Subroutine vcl_recv entfernen Sie nicht-essentielle Cookies:

sub vcl_recv {
  # Google Analytics und andere Tracking-Cookies entfernen
  set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_ga|_gid|_gat|__utm[a-z]+|_fbp|_gcl_[a-z]+)=[^;]*", "");
  # Leeren Cookie-Header entfernen
  if (req.http.Cookie ~ "^\s*$") {
    unset req.http.Cookie;
  }
}

Entscheidung, was gecacht werden soll

Nicht jede PrestaShop-Seite sollte gecacht werden. Die VCL muss zwischen cache-fähigen und nicht cache-fähigen Anfragen unterscheiden.

Immer cachen: Produktseiten für anonyme Besucher, Kategorielistenseiten, CMS-Seiten (Über uns, AGB, Kontakt), die Startseite, Hersteller- und Lieferantenseiten, Sitemap-Seiten.

Niemals cachen: Die Warenkorbseite, Checkout-Seiten (alle Schritte), den Kundenkontobereich (Bestellungen, Adressen, persönliche Informationen), die Login- und Registrierungsseiten, jede Seite für einen eingeloggten Kunden, POST-Anfragen, AJAX-Anfragen, die den Zustand verändern (zum Warenkorb hinzufügen, Menge aktualisieren).

Die VCL-Logik hierfür prüft typischerweise den URL-Pfad und das Vorhandensein von Sitzungs-Cookies:

sub vcl_recv {
  # POST-Anfragen nicht cachen
  if (req.method == "POST") {
    return (pass);
  }
  # Admin-Bereich nicht cachen
  if (req.url ~ "^/admin") {
    return (pass);
  }
  # Checkout und Warenkorb nicht cachen
  if (req.url ~ "(cart|order|login|my-account|module/)" ) {
    return (pass);
  }
  # Nicht cachen, wenn der Kunde Artikel im Warenkorb hat
  if (req.http.Cookie ~ "PrestaShop-") {
    return (pass);
  }
  return (hash);
}

Cache-Dauer festlegen

In der Subroutine vcl_backend_response steuern Sie, wie lange Varnish jede Antwort cachet. PrestaShop sendet Cache-Control-Header, die typischerweise no-cache oder private lauten, da es davon ausgeht, dass jede Antwort personalisierten Inhalt enthalten könnte. Sie müssen diese für Seiten überschreiben, von denen Sie wissen, dass sie sicher gecacht werden können:

sub vcl_backend_response {
  # Produkt- und Kategorieseiten für 1 Stunde cachen
  if (bereq.url ~ "^/([0-9]+-|[a-z]+-[0-9]+)") {
    set beresp.ttl = 1h;
    unset beresp.http.Set-Cookie;
  }
  # Statische Assets für 1 Tag cachen
  if (bereq.url ~ "\.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf)$") {
    set beresp.ttl = 1d;
    unset beresp.http.Set-Cookie;
  }
}

Das Entfernen von Set-Cookie aus gecachten Antworten ist kritisch. Wenn eine gecachte Antwort einen Set-Cookie-Header enthält, wird Varnish sie standardmäßig nicht cachen, und selbst wenn es zum Cachen gezwungen wird, würde es dasselbe Sitzungs-Cookie für jeden Besucher setzen, was zu Session-Hijacking führt.

Cache-Invalidierung mit PURGE-Anfragen

Wenn sich ein Produktpreis ändert, ein neues Produkt hinzugefügt wird oder Inhalte aktualisiert werden, muss die gecachte Version invalidiert werden. Varnish unterstützt PURGE-Anfragen: eine spezielle HTTP-Methode, die Varnish anweist, eine bestimmte URL aus seinem Cache zu entfernen.

PURGE-Unterstützung konfigurieren

Fügen Sie die PURGE-Behandlung Ihrer VCL hinzu:

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

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

Die ACL beschränkt PURGE-Anfragen auf localhost und verhindert, dass externe Benutzer Ihren Cache leeren.

Purges von PrestaShop aus auslösen

PrestaShop sendet von Haus aus keine PURGE-Anfragen. Sie benötigen ein Modul oder einen benutzerdefinierten Hook, der erkennt, wann sich cache-fähiger Inhalt ändert, und eine PURGE-Anfrage an Varnish sendet. Das Modul hängt sich in PrestaShop-Ereignisse wie actionProductUpdate, actionCategoryUpdate und actionCMSPageUpdate ein. Wenn diese Ereignisse ausgelöst werden, sendet das Modul eine HTTP-PURGE-Anfrage an die entsprechende URL auf dem Varnish-Server.

Bei einem Produktupdate würde das Modul die Produkt-URL, die Kategorie-URLs, zu denen das Produkt gehört (da Kategorielistenseiten Produktpreise und Verfügbarkeit anzeigen), und möglicherweise die Startseite purgen, wenn sie empfohlene Produkte anzeigt. Diese Kaskade von Purges ist notwendig, um zu verhindern, dass veraltete Daten irgendwo auf der Website erscheinen.

Ban-basierte Invalidierung

Für Szenarien, in denen viele URLs auf einmal gepurgt werden müssen (eine seitenweite Preisaktualisierung, eine Designänderung, ein neues Werbebanner), sind einzelne PURGE-Anfragen unpraktisch. Varnish unterstützt Bans, die musterbasierte Invalidierungsregeln sind. Ein Ban weist Varnish an, jedes gecachte Objekt zu verwerfen, das einem Muster entspricht:

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

Das Senden einer BAN-Anfrage mit dem Header X-Ban-Pattern: /category/ würde alle gecachten Kategorieseiten in einer einzigen Operation invalidieren.

Edge Side Includes (ESI) für dynamische Blöcke

Viele PrestaShop-Seiten enthalten eine Mischung aus statischem und dynamischem Inhalt. Die Produktliste auf einer Kategorieseite ist für jeden Besucher gleich, aber die Kopfzeile mit der Warenkorbanzahl ist personalisiert. Ohne ESI können Sie die Seite überhaupt nicht cachen, da der dynamische Header die gesamte Antwort besucherspezifisch macht.

Edge Side Includes lösen dieses Problem, indem sie es ermöglichen, Abschnitte der Seite als separate Fragmente zu markieren, die einzeln abgerufen werden. Varnish setzt die endgültige Seite aus gecachten und ungecachten Fragmenten zusammen.

Wie ESI funktioniert

In Ihrem Smarty-Template fügen Sie statt des direkten Renderns des Warenkorb-Widgets ein ESI-Tag ein:

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

Wenn Varnish die gecachte Seite verarbeitet, trifft es auf das ESI-Tag und stellt eine separate Backend-Anfrage für dieses Fragment. Der Hauptseitenkörper wird aus dem Cache geliefert, während das Warenkorb-Widget frisch von PrestaShop geholt wird. Die zusammengesetzte Antwort enthält sowohl den gecachten Body als auch das frische Warenkorb-Widget.

Aktivieren Sie die ESI-Verarbeitung in Ihrer VCL:

sub vcl_backend_response {
  set beresp.do_esi = true;
}

ESI-Überlegungen für PrestaShop

Die Implementierung von ESI erfordert die Modifikation Ihrer PrestaShop-Templates, um dynamische Inhalte in ESI-kompatible Fragmente zu trennen. Jedes Fragment benötigt seinen eigenen URL-Endpunkt, der nur das HTML für diesen Block zurückgibt. Die Fragmente, die typischerweise dynamisch sind und eine ESI-Behandlung benötigen, umfassen das Warenkorb-Zusammenfassungs-Widget (Artikelanzahl, Gesamtbetrag), die Kundenbegrüßung ("Hallo, Max"), personalisierte Produktempfehlungen, den Login-/Logout-Link und kürzlich angesehene Produkte.

Der Aufwand für eine ordnungsgemäße ESI-Implementierung ist erheblich. Jedes dynamische Fragment benötigt einen eigenen Controller, die Templates müssen umstrukturiert werden, und die Caching-Regeln für jedes Fragment müssen individuell angepasst werden. Dies ist einer der Gründe, warum Varnish als fortgeschrittene Optimierung gilt – es funktioniert am besten, wenn die Anwendung damit im Hinterkopf entwickelt wurde.

Backend Health Checks

Varnish kann den Zustand Ihres Backend-Servers überwachen und Maßnahmen ergreifen, wenn dieser nicht mehr verfügbar ist. Dies wird in der Backend-Definition konfiguriert:

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

Varnish sendet alle 5 Sekunden eine Anfrage an /ping.php. Wenn 3 von den letzten 5 Prüfungen fehlschlagen, markiert Varnish das Backend als krank. Solange das Backend krank ist, kann Varnish veralteten gecachten Inhalt ausliefern (Grace-Modus), anstatt Fehler an die Besucher zurückzugeben. Das bedeutet, dass Ihr Shop teilweise verfügbar bleibt, selbst wenn das PHP-Backend abstürzt oder neu gestartet wird.

Die Grace-Modus-Konfiguration bestimmt, wie lange Varnish veralteten Inhalt ausliefert:

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

Mit einer 6-stündigen Grace-Periode, wenn Ihr Backend ausfällt, sehen Besucher gecachte Seiten (auch wenn sie bis zu 6 Stunden alt sind) statt Fehlerseiten. Produktpreise könnten leicht veraltet sein, aber der Shop bleibt funktionsfähig, während Sie das Backend-Problem beheben.

Performance-Benchmarks

Der Leistungsunterschied zwischen keinem Cache, PHP-FPC und Varnish ist erheblich und messbar.

Ohne Cache (pures PrestaShop): Eine typische PrestaShop-Produktseite benötigt 200–800 Millisekunden zur Generierung, abhängig von der Server-Hardware, der Anzahl geladener Module und der Datenbankabfragenanzahl. Unter Last steigen die Antwortzeiten, da PHP-Worker ausgelastet sind. Ein einzelner Server kann 20–50 gleichzeitige Benutzer bedienen, bevor die Antwortzeiten inakzeptabel werden.

PHP-FPC-Modul: Cache-Hits werden in 30–100 Millisekunden bedient, da PHP immer noch startet und das Framework teilweise initialisiert wird. Unter Last ist die Leistung deutlich besser, da gecachte Antworten minimale PHP-Verarbeitungszeit erfordern. Ein einzelner Server kann 200–500 gleichzeitige Benutzer bedienen, abhängig von der Konfiguration. Cache-Misses benötigen weiterhin die volle Renderzeit.

Varnish: Cache-Hits werden in 1–5 Millisekunden bedient. Unter Last kann Varnish selbst Tausende von gleichzeitigen Verbindungen verarbeiten, da es in C geschrieben und speziell für diese Aufgabe konzipiert ist. Der Backend-Server verarbeitet nur Cache-Misses, die bei einem richtig konfigurierten System einen kleinen Bruchteil des gesamten Traffics ausmachen. Dieselbe Hardware, die ohne Caching mit 50 gleichzeitigen Benutzern kämpft, kann mit Varnish 5.000 oder mehr bedienen.

Diese Zahlen verdeutlichen, warum Varnish die Konfigurationskomplexität für hochfrequentierte Shops wert ist. Die Leistungsverbesserung ist nicht inkrementell – sie ist eine Größenordnung.

Hosting-Anforderungen

Varnish hat spezifische Hosting-Anforderungen, die nicht jede PrestaShop-Hosting-Umgebung erfüllen kann.

Serverzugriff

Sie benötigen Root-Zugriff, um Varnish zu installieren und zu konfigurieren. Shared-Hosting-Pläne unterstützen Varnish nicht, da es einen eigenen Prozess erfordert, der auf einem Port lauscht und den gesamten HTTP-Traffic abfängt. Sie benötigen einen VPS, einen dedizierten Server oder eine Cloud-Instanz, bei der Sie den gesamten Server-Stack kontrollieren.

Arbeitsspeicher

Varnish speichert seinen Cache im RAM. Die Menge an RAM, die Sie benötigen, hängt von der Anzahl der einzigartigen Seiten in Ihrem Katalog und der Größe jeder gecachten Antwort ab. Eine grobe Formel: Anzahl der cache-fähigen Seiten multipliziert mit der durchschnittlichen Seitengröße ergibt die minimale Cache-Größe. Ein Shop mit 5.000 Produkten, 200 Kategorien und einer durchschnittlichen Seitengröße von 50 KB benötigt ungefähr 260 MB Cache-RAM. Fügen Sie Overhead für Varnish selbst hinzu, und Sie sollten mindestens 512 MB zuweisen. Für größere Kataloge sind 1–2 GB üblich.

Port-Konfiguration

In einem Standard-Setup lauscht Varnish auf Port 80 (dem Standard-HTTP-Port) und leitet Cache-Misses an den Webserver auf einem anderen Port weiter (üblicherweise 8080). Das bedeutet, dass Sie Apache oder Nginx so umkonfigurieren müssen, dass es auf Port 8080 statt auf 80 lauscht. Wenn Sie HTTPS verwenden (und das sollten Sie), setzen Sie typischerweise Nginx vor Varnish, um die SSL-Terminierung zu handhaben: Nginx auf Port 443 terminiert SSL und leitet an Varnish auf Port 80 weiter, das Cache-Misses an Apache oder PHP-FPM auf Port 8080 weiterleitet.

Docker-Setup-Beispiel

Varnish in Docker neben einem PrestaShop-Container auszuführen, ist eine saubere Methode, Varnish zu einem bestehenden Setup hinzuzufügen, ohne das Hostsystem zu modifizieren.

Docker Compose Konfiguration

Ein grundlegendes Docker Compose Setup mit Varnish, Nginx für SSL und 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

In diesem Setup ist Varnish der Eintrittspunkt auf Port 80. Der PrestaShop-Container exponiert seinen Port nicht an den Host, sondern nur ans Docker-Netzwerk. Der VCL-Backend-Host wäre prestashop (der Docker-Servicename) auf Port 80.

VCL für Docker

Die VCL-Backend-Definition für Docker verwendet den Servicenamen statt localhost:

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

Dockers internes DNS löst den Servicenamen zur Container-IP auf. Der Rest der VCL-Konfiguration bleibt identisch zu einem Nicht-Docker-Setup.

Cache-Speicher in Docker

Standardmäßig verwendet das Varnish Docker Image In-Memory-Speicher (malloc), was ideal für die Leistung ist. Die Umgebungsvariable VARNISH_SIZE steuert, wie viel Speicher Varnish für seinen Cache reserviert. Setzen Sie diesen Wert auf einen Wert, der in die Speicherlimits Ihres Containers passt, wobei Platz für den Varnish-Prozess selbst übrig bleiben sollte.

Für persistenten Cache, der Container-Neustarts übersteht, können Sie dateibasierten Speicher verwenden, indem Sie ein Volume mounten, aber das ist selten notwendig. Der Cache wärmt sich schnell auf (innerhalb von Minuten nach Empfang von Traffic), und dateibasierter Speicher ist langsamer als speicherbasierter Speicher.

Überwachung der Varnish-Performance

Varnish bietet integrierte Werkzeuge zur Überwachung der Cache-Performance.

Der Befehl varnishstat zeigt Echtzeit-Statistiken an, einschließlich Cache-Trefferquote, Backend-Verbindungen und Speichernutzung. Die wichtigste Metrik ist die Trefferquote, die bei einem gut konfigurierten Setup 85 % oder höher sein sollte. Wenn Ihre Trefferquote unter 70 % liegt, überprüfen Sie Ihre VCL-Regeln, da zu viele Anfragen zum Backend durchgeleitet werden.

Der Befehl varnishlog zeigt detaillierte Logs pro Anfrage, die unschätzbar wertvoll für das Debugging sind, warum bestimmte Anfragen nicht gecacht werden. Sie können nach URL-Muster, Antwortcode oder Cache-Hit/Miss-Status filtern.

Der Befehl varnishtop zeigt eine Rangliste der häufigsten Log-Einträge und hilft Ihnen, Muster bei Cache-Misses oder Fehlern zu identifizieren.

Häufige Fallstricke

Vergessen, Cookies zu entfernen

Die häufigste Varnish-Fehlkonfiguration mit PrestaShop ist das Nicht-Entfernen von Analytics- und Tracking-Cookies. Diese Cookies sind bei praktisch jeder Anfrage vorhanden und machen jede Anfrage aus Varnish' Perspektive einzigartig, was zu einer Trefferquote von 0 % führt. Entfernen Sie immer Cookies, die Sie nicht für die Cache-Variation benötigen.

Personalisierte Inhalte cachen

Wenn Ihre VCL zu aggressiv ist, wird sie Seiten cachen, die personalisierte Inhalte enthalten (Begrüßung des eingeloggten Benutzers, Warenkorbinhalte) und diese anderen Besuchern ausliefern. Dies verursacht schwerwiegende Usability-Probleme und potenzielle Datenschutzprobleme. Leiten Sie Anfragen mit Sitzungs-Cookies immer an das Backend weiter.

Keine Invalidierung bei Inhaltsänderungen

Ohne einen ordnungsgemäßen Purging-Mechanismus werden Inhaltsänderungen im Back Office nicht sichtbar, bis gecachte Seiten natürlich ablaufen. Für einen Shop mit aktivem Bestandsmanagement bedeutet dies, dass Besucher möglicherweise vergriffene Produkte, falsche Preise oder veraltete Beschreibungen sehen. Implementieren Sie PURGE- oder BAN-Unterstützung und integrieren Sie sie mit den Update-Hooks von PrestaShop.

HTTPS ignorieren

Varnish unterstützt SSL nicht nativ. Sie müssen einen SSL-terminierenden Proxy (Nginx, HAProxy oder einen Cloud Load Balancer) vor Varnish setzen. Wenn Sie dies in Ihrer Architektur nicht einplanen, führt dies zu Mixed-Content-Problemen, Weiterleitungsschleifen oder der Unfähigkeit, HTTPS-Traffic überhaupt zu bedienen.

Ist Varnish das Richtige für Ihren Shop

Varnish ist ein leistungsstarkes Werkzeug, aber nicht die richtige Wahl für jeden PrestaShop-Shop. Es fügt betriebliche Komplexität hinzu: einen weiteren Dienst zum Überwachen, eine weitere Konfigurationssprache zum Erlernen, eine weitere Schicht in Ihrem Debugging-Prozess. Die Vorteile sind klar und messbar für Shops, die sie benötigen, aber sie kommen auf Kosten von Einrichtungszeit, Wartung und Schwierigkeit bei der Fehlerbehebung.

Wenn Ihr Shop weniger als 50.000 Seitenaufrufe pro Tag verzeichnet und Ihr Server die Last mit einem FPC-Modul komfortabel bewältigt, ist Varnish unnötige Komplexität. Wenn Ihr Shop regelmäßig Traffic-Spitzen erlebt, die Ihren Server überlasten, ein hohes Volumen an anonymem Browsing-Traffic bedient oder die schnellstmöglichen Antwortzeiten für SEO oder Benutzererfahrung benötigt, bietet Varnish ein Leistungsniveau, das keine PHP-basierte Caching-Lösung erreichen kann.

Beginnen Sie mit einer ordnungsgemäßen PrestaShop-Optimierung (Abfrageoptimierung, Modul-Audit, PHP OPcache, Bildoptimierung) und einem FPC-Modul. Wenn diese Optimierungen nicht ausreichen, ist Varnish der nächste Schritt auf der Performance-Skalierungsleiter.