Varnish Cache: Was ist das und wie installieren Sie es?

Was ist Varnish Cache?

Varnish Cache ist ein quelloffener HTTP Reverse Proxy mit Zwischenspeicher, der vor Ihrem Webserver sitzt. Er hält fertige Seitenantworten im Arbeitsspeicher und liefert sie bei wiederholten Anfragen direkt aus, ohne Anwendung, PHP oder Datenbank zu belasten. Somit sinkt die Serverlast, die Antwortzeit wird kürzer und Ihre Seite hält Lastspitzen besser stand.

Wir haben diesen Leitfaden für Website und Shop Betreiber, Entwickler und alle geschrieben, die einen eigenen VPS verwalten. Wir sind also ein Team für digitales Marketing und Web, kein Hosting Anbieter. Deshalb stützen wir jede Erklärung auf die offizielle Varnish Dokumentation und auf HTTP Standards. Vergleichen Sie jeden Befehl mit der Dokumentation Ihrer Distribution, bevor Sie ihn auf einem Live System ausführen.

Welches Problem löst Varnish Cache für Ihre Website?

Eine dynamische Seite führt bei jedem Besuch Anwendungscode aus, fragt die Datenbank ab und baut das HTML neu auf. Wenn tausend Personen dieselbe Seite aufrufen, erledigen Sie dieselbe Arbeit tausendmal. Varnish beendet also diese Wiederholung. Es leitet die erste Anfrage an das Backend weiter, speichert die Antwort und beantwortet spätere Anfragen aus dem eigenen Speicher.

Das bringt drei konkrete Vorteile. Erstens verbessert sich die Antwortzeit, denn eine Antwort aus dem Speicher wartet nicht auf die Anwendung. Zweitens steigt die Belastbarkeit, weil das Backend während einer Kampagne deutlich weniger gleichzeitige Anfragen sieht. Drittens skalieren Sie weiter, da Sie mehr aus dem vorhandenen Server holen, bevor Sie einen größeren kaufen.

Die Suchmaschinen Seite der Geschwindigkeit haben wir in unserem Beitrag Bilder für die Website optimieren behandelt. In dieser Kette verbessert Varnish nur die Antwortzeit des Servers. Schwere Bilder, JavaScript und Schriften löst es allerdings nicht.

Wie funktioniert Varnish, und welchen Weg nimmt eine Anfrage?

Die Anfrage des Besuchers erreicht zuerst Varnish. Dann macht es daraus einen Suchschlüssel, der standardmäßig aus Hostname und URL besteht. Liegt der Schlüssel im Speicher, spricht man von einem Treffer (Hit), und die Antwort kommt sofort zurück. Fehlt er, handelt es sich um einen Fehlgriff (Miss), und Varnish reicht die Anfrage an den Backend Server weiter.

Sobald das Backend antwortet, behält Varnish die Antwort für eine bestimmte Zeit. Diese Zeit legt meistens das Backend über den Header Cache-Control fest. Die Standarddefinition der HTTP Cache Regeln finden Sie in RFC 9111.

1. Der Besucher ruft eine Seite auf, und die Anfrage erreicht Varnish.
2. Danach sucht Varnish im Zwischenspeicher nach einem passenden Objekt.
3. Findet es eines, liefert es die Antwort sofort aus (Hit).
4. Findet es keines, dann schickt es die Anfrage an das Backend (Miss).
5. Das Backend antwortet, Varnish speichert die Antwort und liefert sie dann an den Besucher.

In der Praxis steuert eine Konfigurationssprache namens VCL diesen Ablauf. Sie entscheidet, welche Anfragen in den Speicher gelangen, welche ihn umgehen und wie lange Objekte bleiben.

Merken Sie sich einen Punkt: Eine gespeicherte Antwort bleibt gleich, bis sie abläuft oder Sie sie löschen. Wenn Sie Inhalte aktualisieren, sehen Besucher die alte Seite daher eine Weile weiter. Das ist normal, und wir steuern es im Abschnitt über das Löschen.

Was ist der Unterschied zwischen Varnish, Redis und OPcache?

Alle drei nennt man "Cache", doch sie arbeiten auf verschiedenen Ebenen und ersetzen einander nicht. Erstens speichert Varnish die vollständige HTTP Antwort. Zweitens hält Redis Daten, die Ihre Anwendung erzeugt hat. Außerdem bewahrt OPcache kompilierten PHP Code im Speicher auf. Auf vielen Seiten laufen alle drei zusammen.

Den Unterschied zwischen Redis und Memcached erklären wir ausführlich in Caching erklärt, deshalb wiederholen wir ihn hier nicht. Die Tabelle zeigt schon den Kern: Varnish arbeitet außerhalb der Anwendung, auf der äußersten Ebene.

Wann hilft Varnish Cache, und wann nicht?

Varnish glänzt auf Seiten, auf denen die meisten Besucher denselben Inhalt sehen. Nachrichtenseiten, Blogs, Unternehmensseiten und Produktlisten sind typische Beispiele. Wenn sich eine Seite nicht pro Person ändert, steigt die Trefferquote, und der Gewinn ist klar.

Andererseits gewinnen Seiten, die für jeden Besucher eigene Inhalte bauen, deutlich weniger. Ein Kundenkonto nach dem Login, ein Warenkorb und der Checkout sind gute Beispiele. Wie Sie diese Seiten umgehen, zeigen wir weiter unten.

• Gut geeignet: Seiten, die oft gelesen werden, sich selten ändern und für alle gleich aussehen.
• Begrenzter Nutzen: Seiten mit wenig Verkehr, denn eine zusätzliche Ebene vor einer ohnehin schnellen Seite bringt kaum etwas.
• Schlecht geeignet: Personalisierte, sitzungsbezogene oder ständig wechselnde Inhalte.
• Beachten Sie: Eine langsame erste Anfrage (Miss) wird durch Varnish nicht schneller.

Was sollten Sie vor der Installation von Varnish vorbereiten?

Vor der Installation müssen Sie Ihren aktuellen Aufbau kennen. Ist Ihr Webserver Nginx oder Apache, auf welchem Port läuft er, und wo endet HTTPS? Diese drei Antworten bestimmen den Rest der Einrichtung.

• Eine Testumgebung: Bauen Sie denselben Aufbau auf einer Staging Seite nach, bevor Sie die Live Seite anfassen.
• Zugriff: Sie brauchen einen VPS mit Root oder sudo Rechten, auf Shared Hosting können Sie Varnish nicht selbst installieren.
• Ein Backup: Halten Sie eine aktuelle Sicherung Ihrer Konfigurationsdateien und der Website bereit.
• Einen Rückfallplan: Notieren Sie die alten Port Einstellungen Ihres Webservers.

Wenn Sie bei Backups unsicher sind, beginnen Sie mit unserer Website Backup Strategie. Außerdem können Sie mit unserer DNS Abfrage prüfen, wohin Ihre Domain zeigt.

Wie installieren Sie Varnish Cache?

Auf Debian und Ubuntu stammt Varnish aus dem Paketarchiv der Distribution. Die Paketversion kann etwas hinter der aktuellen stabilen Version zurückliegen. Brauchen Sie eine neuere, folgen Sie den Archiv Hinweisen auf der offiziellen Varnish Seite.

sudo apt update
sudo apt install varnish
varnishd -V

Der letzte Befehl zeigt die installierte Version. Auf Systemen der RHEL Familie heißt das Paket ebenfalls varnish, und Sie installieren es mit dnf. Danach steht der systemd Dienst bereit, aber Port und Speichergröße müssen Sie für Ihren Server noch anpassen.

Wie das Paket Varnish startet, sehen Sie in der Unit Datei. Die Zeile ExecStart enthält die Lauschadresse (-a), die VCL Datei (-f) und den Speicher (-s). Die Details unterscheiden sich je nach Distribution, lesen Sie die folgende Zeile also nur als Beispiel.

sudo systemctl edit --full varnish

# Beispielzeile für ExecStart (Werte sind Beispiele):
ExecStart=/usr/sbin/varnishd -a :6081 -f /etc/varnish/default.vcl -s malloc,256m

Wie stellen Sie Varnish vor Nginx oder Apache?

Das Prinzip ist einfach: Varnish spricht mit dem Besucher, und Nginx oder Apache wird zum Backend. Konkret verschieben Sie den Webserver von seinem öffentlichen Port auf einen lokalen. Varnish übernimmt dann den öffentlichen Port. Deshalb macht ein Test Port den Wechsel sicher.

Zunächst starten Sie Varnish auf einem Port wie 6081 und testen ihn. Dann tauschen Sie die Ports, aber erst wenn Sie mit dem Ergebnis zufrieden sind. Geht etwas schief, dann machen Sie eine einzige Einstellung rückgängig und sind zurück im alten Zustand. Die Portnummern in der Tabelle sind Beispiele, Ihr Aufbau kann andere Werte nutzen.

Zum Beispiel ändern Sie bei Apache die Zeilen Listen und VirtualHost auf 8080. Bei Nginx ändern Sie die Zeile listen im jeweiligen Server Block. Danach legen Sie auf der Varnish Seite die Backend Adresse fest, und das erledigen wir im VCL Abschnitt.

Funktioniert Varnish mit HTTPS, und warum brauchen Sie TLS Terminierung?

Das klassische Varnish Cache sprach kein TLS, daher mussten Sie eine eigene Komponente davorsetzen, die den HTTPS Verkehr entschlüsselt. Die aktuelle Varnish Projektseite und die Dokumentation von Varnish Software erwähnen inzwischen allerdings auch eingebaute TLS Unterstützung. Prüfen Sie deshalb die Dokumentation Ihrer eigenen Version.

In der Praxis sieht das häufigste Setup so aus: Nginx nimmt die HTTPS Verbindung auf Port 443 an und reicht die Anfrage an Varnish weiter, und Varnish geht dann zum Backend. Ein spezieller TLS Terminator wie Hitch kann dieselbe Aufgabe übernehmen. Die Dokumentation von Varnish Software beschreibt, dass beide Teile über das PROXY Protokoll sprechen können. Details finden Sie in der TLS Dokumentation.

Wenn Zertifikate für Sie neu sind, ist unser Beitrag Was ist ein SSL Zertifikat ein guter Einstieg. Danach prüfen Sie Ihr Zertifikat mit unserem SSL Check.

Wie richten Sie TLS Terminierung in Nginx ein und verbinden sie mit Varnish?

Das folgende Beispiel zeigt den Aufbau, bei dem Nginx HTTPS annimmt und an Varnish weiterleitet. Der Name example.com ist eine Beispiel Domain, und die Zertifikatspfade folgen dem üblichen Verzeichnisaufbau von Let's Encrypt. Nutzen Sie daher Ihre eigenen Pfade.

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:6081;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Der Header X-Forwarded-Proto ist wichtig. Die Anwendung im Backend erfährt daran, dass die Anfrage tatsächlich per HTTPS kam. Fehlt er, dann geraten Anwendungen wie WordPress leicht in eine Umleitungsschleife. Die Einzelheiten zu proxy_pass und proxy_set_header finden Sie in der Dokumentation des Nginx Proxy Moduls.

Was ist VCL, und wie ist eine Konfiguration aufgebaut?

VCL steht für Varnish Configuration Language. Damit schreiben Sie ein kleines Programm, das Varnish sagt, wie es jede Anfrage behandelt. Eine Datei enthält einen Backend Block, der den Ursprungsserver beschreibt, und Unterprogramme, die an Stellen des Anfrage Ablaufs andocken.

• vcl_recv: Läuft, wenn eine Anfrage eintrifft. Hier entscheiden Sie, ob die Anfrage in den Speicher darf.
• vcl_backend_response: Läuft, wenn das Backend antwortet. Dort legen Sie die Speicherdauer fest.
• vcl_deliver: Läuft, wenn die Antwort hinausgeht. Hier fügen Sie gut Test Header hinzu.
• vcl_hash: Bestimmt, woraus der Schlüssel besteht.

Nach Ihrem Code führt Varnish außerdem den eigenen eingebauten VCL Code aus. Laut Dokumentation liefert dieser Code sinnvolle Standardwerte für einen HTTP Cache. Eine Kopie geben Sie mit dem Befehl varnishd -x builtin aus, und die Seite Built in VCL erklärt die Idee.

Wie schreiben Sie Ihre erste VCL Datei?

Die folgende Datei ist das kleinste funktionierende Beispiel. Sie verbindet das Backend mit dem Webserver auf Port 8080, fügt einen Test Header hinzu und überlässt alles Übrige den eingebauten Regeln. Sie können sie als /etc/varnish/default.vcl speichern.

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

Prüfen Sie die Syntax, bevor Sie laden. Bei einem Fehler warnt Sie der Befehl, deshalb bleibt Ihre laufende Konfiguration unberührt. Danach laden Sie die neue Datei in das laufende Varnish und aktivieren sie.

varnishd -C -f /etc/varnish/default.vcl
sudo varnishadm vcl.load neu /etc/varnish/default.vcl
sudo varnishadm vcl.use neu

Warum umgeht Varnish den Speicher, wenn Cookies im Spiel sind?

Die Varnish Dokumentation hält fest, dass der eingebaute Code in vcl_recv das Speichern verhindert, sobald eine Anfrage ein Cookie trägt. Die Begründung leuchtet ein. Denn ein Cookie steht oft für persönliche Inhalte, und die Seite einer Person bei einer anderen anzuzeigen, wäre ein ernster Datenschutzfehler.

Das Problem: Die meisten Seiten setzen auch bei anonymen Besuchern Cookies. Konkret wirken Analyse, Werbung und Theme Cookies für Varnish alle persönlich. Somit bleibt Ihre Trefferquote weit unter der Erwartung, und Sie sehen den Gewinn nie.

Die Lösung besteht darin, Cookies in zwei Gruppen zu teilen. Erstens behalten Sie die, die Sitzungen und Warenkörbe tragen. Zweitens entfernen Sie reine Analyse Cookies, bevor die Anfrage die Speicherlogik erreicht. Die Dokumentation erwähnt auch, dass Sie dieses Verhalten abschalten können, wenn Sie Ihrem Backend vertrauen: Das Unterprogramm vcl_req_cookie kehrt dann sofort zurück.

Auf der Antwortseite gilt eine ähnliche Regel: Der eingebaute Code speichert keine Antworten mit einem Set-Cookie Header. Wenn also ein Plugin unnötige Cookies erzeugt, prüfen Sie zuerst das Plugin.

Welche Regeln zum Umgehen des Caches braucht eine WordPress Seite?

Bei WordPress darf zunächst der Admin und Login Bereich nie in den Speicher. Danach folgen angemeldete Nutzer und Besucher, die kommentiert haben. Schließlich kommen die Warenkorb Cookies eines Shop Plugins. Das Beispiel zeigt diese Logik, und die Cookie Namen Ihrer eigenen Plugins bestätigen Sie in den Entwicklertools des Browsers.

sub vcl_recv {
    if (req.url ~ "^/(wp-admin|wp-login\.php)") {
        return (pass);
    }
    if (req.http.Cookie ~ "wordpress_logged_in_|comment_author_") {
        return (pass);
    }
    unset req.http.Cookie;
}

Die letzte Zeile entfernt alle übrigen Cookies. Diese Methode ist verbreitet, aber riskant, weil Sie damit Funktionen unbemerkt brechen, die im Theme oder Plugin an einem Cookie hängen. Testen Sie daher Formulare, Suche und Login Abläufe auf einer Staging Seite, bevor Sie live gehen.

Auch Ihre Plattformwahl prägt den Cache Plan. Für diese Entscheidung lesen Sie WordPress oder individuelle Website.

Wie schützen Sie Warenkorb und Checkout im Online Shop?

Im Online Shop ist die Fehlertoleranz also winzig. Wenn Sie den Warenkorb eines Kunden einem anderen zeigen, zerstören Sie Vertrauen und Umsatz zugleich. Deshalb müssen Warenkorb, Checkout und Kundenkonto den Speicher in jedem Fall umgehen. Produktlisten und Kategorieseiten dürfen dagegen für anonyme Besucher bedenkenlos hinein.

sub vcl_recv {
    if (req.url ~ "^/(cart|checkout|my-account)") {
        return (pass);
    }
    if (req.http.Cookie ~ "woocommerce_items_in_cart|wp_woocommerce_session_") {
        return (pass);
    }
}

Dieses Beispiel nutzt gängige WooCommerce Cookie Namen und englische Pfade. Hat Ihr Shop andere URL Pfade, dann passen Sie sie an. In einem Beispiel Shop kommen Produktseiten aus dem Speicher, während der Warenkorb immer vom Live Server stammt.

Die Umsatzwirkung von Tempo haben wir in Ladezeit im Onlineshop untersucht. Für einen Gesamtplan Ihres Shops gibt es unsere E Commerce Beratung.

Wie löschen Sie den Cache (Purge)?

Wenn Sie Inhalte aktualisieren, löschen Sie den Speicher, damit Besucher nicht die alte Version bekommen. Die Varnish Dokumentation beschreibt zwei Wege. Ein Purge entfernt ein Objekt samt Varianten aus dem Speicher. Ein Ban funktioniert stattdessen wie ein Filter auf bereits gespeicherte Objekte.

Damit Fremde Ihren Speicher nicht leeren, begrenzen Sie Purge Anfragen mit einer Zugriffsliste (ACL). Auch die Dokumentation betont das, denn ein offener Purge wäre ein Risiko. Das Beispiel ist eine kurze Anpassung der dokumentierten Logik, und die IP Adresse stammt aus einem Dokumentationsbereich.

acl purge {
    "localhost";
    "203.0.113.10";
}

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

Vom Server aus genügt ein Befehl, um eine einzelne URL zu löschen: curl -X PURGE http://127.0.0.1:6081/beispiel/ . Unter WordPress wählen Sie dann ein Plugin, das diese Anfrage bei jeder Inhaltsänderung sendet. Mehr dazu steht in der Varnish Dokumentation zum Purging.

Wie prüfen Sie, ob Varnish läuft, und wie überwachen Sie die Trefferquote?

Beginnen Sie nach der Einrichtung zunächst mit den Antwort Headern. Varnish ergänzt zum Beispiel Header wie Age und Via. Haben Sie den Header X-Cache von oben eingebaut, sehen Sie HIT oder MISS direkt. Zeigt die zweite Anfrage kein HIT, arbeitet der Speicher nicht.

curl -sI https://example.com/ | grep -i -E "x-cache|age|via"

Für Zahlen genügt das Werkzeug varnishstat. In einer einmaligen Ausgabe vergleichen Sie die Zähler cache_hit und cache_miss und schätzen so die Trefferquote. Eine einzelne Anfrage verfolgen Sie Schritt für Schritt mit varnishlog.

varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss
varnishlog -g request -q 'ReqURL eq "/"'

Ist die Quote niedrig, liegt die Ursache meist bei Cookies, bei Cache Headern oder bei Tracking Parametern in den URLs. Schauen Sie deshalb zuerst auf die Cookie und Header Regeln.

Zudem können Tracking Parameter aus Werbekampagnen den Speicher aufspalten. Zum Beispiel ist eine URL mit einem anderen Parameter bei jedem Klick für Varnish eine eigene Seite. Dann können Sie bekannte Tracking Parameter in VCL aus dem Schlüssel entfernen. Stellen Sie daher vorher sicher, dass die Anwendung den Parameter nicht für den Seiteninhalt nutzt.

Wie wirkt sich Varnish auf SEO und Core Web Vitals aus?

Varnish ist also für sich kein Ranking Signal. Es verkürzt allerdings die Antwortzeit des Servers, daher verbessert sich die Zeit bis zum ersten Byte, und das trägt indirekt zu den Lade Metriken bei. Versprechen Sie daher keinen echten Effekt, bevor Sie gemessen haben.

Zum Messen halten Sie zuerst den Ist Zustand fest, schalten dann Varnish ein und wiederholen denselben Test. Unser Beitrag Google Lighthouse Test eignet sich für diesen Vergleich. Die Bedeutung der Metriken lesen Sie in Core Web Vitals erklärt.

Eine fehlerhafte Cache Einrichtung kann SEO zudem schaden. Zum Beispiel wirken veraltete Inhalte, die tagelang bleiben, Umleitungsschleifen oder Fehlercodes im Speicher auch auf Crawler. Dieselben Punkte prüfen wir bei technischen Audits in unseren SEO Beratung Projekten.

Welche HTTP Header nutzt Varnish Cache für seine Entscheidung?

Varnish Cache liest die meisten Speicherentscheidungen aus den Headern, die Ihr Backend sendet. Die Werte max-age und s-maxage in Cache-Control stehen an erster Stelle. Für gemeinsam genutzte Caches können Sie s-maxage getrennt setzen, und die Standarddefinition dieser Regeln steht im bereits erwähnten RFC 9111.

Nennt das Backend keine Lebensdauer, dann greift Varnish auf eine eigene Standardzeit zurück. Dieser Wert ist ein Parameter und steht in der Dokumentation Ihrer Version, daher nennen wir hier keine Zahl. Dennoch ist es sauberer, wenn Ihre Anwendung korrekte Header sendet, als eine Lebensdauer in VCL zu erzwingen.

• Cache-Control: Gibt an, wie lange die Antwort bleibt und ob sie überhaupt gespeichert wird.
• Vary: Nennt den Anfrage Header, der die Antwort verändert, zum Beispiel Accept-Encoding.
• Set-Cookie: Kann dazu führen, dass Varnish die Antwort nicht speichert.
• Age: Zeigt, wie lange das Objekt schon im Speicher liegt.

Achten Sie vor allem auf Vary. Ein schlecht gesetzter Header erzeugt somit Dutzende Kopien derselben Seite im Speicher, und Ihre Trefferquote sinkt.

Wie gehen Sie in Varnish Cache mit statischen Dateien und Bildern um?

Bilder, CSS und JavaScript Dateien sind die besten Inhalte zum Speichern, denn sie ändern sich nicht pro Person. Allerdings kommen diese Dateien oft mit Cookies an, und Varnish Cache umgeht sie, sobald es ein Cookie sieht. Deshalb ist es sinnvoll, bei statischen Endungen die Cookies zu entfernen.

sub vcl_recv {
    if (req.url ~ "\.(css|js|png|jpg|jpeg|gif|svg|webp|woff2)$") {
        unset req.http.Cookie;
    }
}

Andererseits kann eine aktualisierte Datei weiter in alter Form ausgeliefert werden, wenn Sie Dateinamen nicht versionieren. Ändern Sie den Dateinamen bei neuem Inhalt oder nutzen Sie einen Versionsparameter, dann vermeiden Sie das Problem. Die Bildgröße zu verkleinern ist also eine eigene Aufgabe, die Varnish nicht übernimmt.

Welche Alternativen gibt es neben Varnish Cache?

Varnish ist allerdings nicht die einzige Möglichkeit. Je nach Seite, Budget und Admin Erfahrung reichen daher oft einfachere Wege. Die folgende Tabelle vergleicht gängige Optionen, und Details bestätigen Sie in der offiziellen Dokumentation des jeweiligen Werkzeugs.

Die Entscheidung sollte also zur Komplexität passen, die Sie beherrschen. Wenn niemand in Ihrem Team diese Arbeit übernehmen kann, ist eine einfachere Lösung langfristig sicherer.

Welche typischen Fehler sollten Sie bei Varnish vermeiden?

Die Fehler wiederholen sich von Setup zu Setup, und die meisten lassen sich leicht verhindern. Viele entstehen zum Beispiel bei Cookie und Header Behandlung oder durch vertauschte Ports. Die Liste unten sammelt die Punkte, die Sie vor dem Livegang prüfen.

• Alle Cookies löschen: Entfernen Sie auch Sitzungs und Warenkorb Cookies, sehen Nutzer gegenseitig ihre Inhalte.
• Das HTTPS Signal nicht weiterreichen: Ohne X-Forwarded-Proto kann die Anwendung in eine Umleitungsschleife geraten.
• Purge offen lassen: Ohne ACL kann jeder Ihren Speicher leeren.
• Speichergröße blind setzen: Ein Wert über dem RAM des Servers bremst das ganze System.
• Nur die Startseite testen: Probieren Sie auch Warenkorb, Login und Formulare.

Ein weiterer häufiger Fehler ist, Fehlerseiten zu lange zu speichern. Zum Beispiel bleibt eine kurze 503 Antwort im Speicher, und Besucher sehen den Fehler noch, nachdem Sie das Problem behoben haben. Halten Sie daher die Lebensdauer von Fehlercodes kurz, und lösen Sie beim Testen bewusst einen Fehler aus, um das Verhalten zu beobachten.

Schützen Sie in puncto Sicherheit die Webanwendung selbst, nicht nur den Speicher. Unser OWASP Top 10 Leitfaden gibt Ihnen eine solide Checkliste. Ein Cache ist also keine Firewall.

Welche Checkliste sollten Sie vor dem Livegang abarbeiten?

Betrachten Sie die Einrichtung von Varnish Cache nicht als einmalige Aufgabe. Wenn Sie die Schritte der Reihe nach gehen, senken Sie Ihr Risiko. Die Reihenfolge unten hilft, wenn Sie einen auf Staging getesteten Aufbau in den Live Betrieb übernehmen.

1. Kompilieren Sie die VCL Datei auf Staging mit varnishd -C und bestätigen Sie, dass sie fehlerfrei ist.
2. Testen Sie danach Login, Warenkorb, Checkout und Formulare mit zwei Browsern, einem anonymen und einem angemeldeten.
3. Bestätigen Sie über den Header X-Cache, dass die zweite Anfrage HIT zeigt.
4. Bestätigen Sie, dass eine Purge Anfrage nur von der erlaubten IP Adresse funktioniert.
5. Halten Sie außerdem die alten Port Einstellungen für einen Rückfall bereit.
6. Schließlich beobachten Sie in den ersten Tagen regelmäßig die Trefferquote und die Fehlerprotokolle.

Wenn Sie diese Liste abgeschlossen haben, dann steht ein solides Fundament. Zudem bleiben Sie ruhig, wenn etwas schiefgeht, denn Sie haben Backup, Überwachung und Rückfall von Anfang an geplant. Außerdem kann jeder in Ihrem Team die Kommentare in der Datei lesen und sehen, warum jede Regel existiert, somit wird die Wartung leichter.

Wann sollten Sie Varnish Cache nicht selbst installieren und Ihrem Hosting Anbieter überlassen?

Seien wir ehrlich: Varnish ist nicht für jede Seite und nicht für jedes Team das richtige Werkzeug. Auf Shared Hosting haben Sie keinen Root Zugriff, also können Sie es ohnehin nicht installieren. Dann ist es gesünder, die Cache Ebene Ihres Anbieters zu nutzen.

• Fehlen Ihnen Root Zugriff und Erfahrung auf der Kommandozeile, dann überlassen Sie die Einrichtung Ihrem Anbieter oder einem Systemadministrator.
• Machen Sie Ihren ersten Versuch nicht in einem Live Shop, sondern bauen Sie zuerst eine Staging Kopie.
• Bietet Ihr Hoster schon einen Cache an, dann fragen Sie dessen Support, bevor Sie eine zweite Ebene ergänzen.
• Liegt Ihr echtes Problem bei einer langsamen Datenbankabfrage oder schweren Bildern, dann beheben Sie zuerst das.

Auch die Anbieterwahl spielt hier also eine Rolle. Unser Beitrag Webhosting auswählen hilft Ihnen zu sehen, welcher Tarif welche Freiheit bietet. Unser Team betreibt kein Hosting, deshalb bieten wir hier nur einen Rahmen, der auf offizieller Dokumentation beruht.

Wenn Sie die technische Basis und die Leistung Ihrer Website gemeinsam planen möchten, deckt unsere Webdesign Leistung das ab.