Varnish-Caching auf LWS erzwingen

Procédure

In dieser Dokumentation erklären wir Ihnen Schritt für Schritt, wie Sie Varnish und Browser dazu bringen können, Ihre Ressourcen im Cache zu behalten, selbst wenn diese die Anfragen Pragma: no-cache oder Cache-Control: no-cache senden.

1. Hintergrund und LWS-Architektur

Die LWS Shared Hosting und cPanel/VPS Managed Hosting Pakete basieren auf dem :

Browser ⇄ NGINX (SSL + HTTP/2) ⇄ Varnish Cache ⇄ Apache/PHP-FPM.

• NGINX verwaltet TLS und komprimiert die Inhalte.
• Varnish (Fastest Cache) ist als Reverse-Proxy positioniert, um die HTTP-Antworten zu speichern.
• Apache oder PHP-FPM generieren die endgültige Antwort, wenn Varnish kein HIT hat.

Wenn alles richtig konfiguriert ist, kann Varnish bis zu 1000 Mal schneller liefern als ein direkter Zugriff auf PHP, während die CPU des Servers entlastet wird.

2. Erinnerung: Wie entscheidet Varnish über das Caching?

3. Kontrolle der Lebensdauer über .htaccess

Aktivieren Sie das Modul mod_headers (bei LWS ist dies standardmäßig der Fall) und platzieren Sie dann das folgende Snippet, wo immer Sie wollen :

  Header set Cache-Control "public, max-age=3600, s-maxage=3600, stale-while-revalidate=60, stale-if-error=86400" Header set Expires "Thu, 31 Dec 2037 23:55:55 GMT".

• max-age: Dauer (in Sekunden) im Browser.
• s-maxage: Zeitdauer speziell für gemeinsam genutzte Caches (Varnish/CDN).
• stale-while-revalidate: Erlaubt Varnish, veralteten Inhalt zu servieren, während er ihn im Hintergrund auffrischt.
• stale-if-error: Serviert die veraltete Version, wenn das Backend mit einem Fehler antwortet (fail-safe).

3.1 Targeting nach Ordner

Die gleiche .htaccess-Datei in den Ordner "/images/" zu legen, wendet die Regel nur auf den Ordner "images" an.

3.2 Targeting nach Erweiterung

  
    Header set Cache-Control "public, max-age=2592000, s-maxage=2592000, immutable".  

immutable: teilt dem Browser mit, dass keine erneute Validierung erforderlich ist, solange das Objekt noch nicht abgelaufen ist; ideal für versionierte Dateien (style.483bf.css).

3.3 Kurzer Cache für HTML

  Header set Cache-Control "public, max-age=300, s-maxage=600, must-revalidate".

Läuft nach 5 min auf Client-Seite und 10 min auf Varnish-Seite ab, danach ist eine Revalidierung erforderlich.

4. Konkrete Szenarien für die Nutzung

5. Den Cache leeren oder ungültig machen

1. Vom LWS Panel aus: Optimierung & Leistung > LWS Cache > Cache leeren.
2. HTTP PURGE (falls aktiviert):

   curl -X PURGE -H "Host: example.com" https://exemple.com/chemin/ressource.jpg

3. Verbannen nach Ausdruck (erweiterte VCL):

   ban req.http.host == "beispiel.com" && req.url ~ "/images/"

6. Testen und debuggen

curl -I https://exemple.com/style.css

Sehen Sie sich das an:

• Age: 356 → Varnish servierte eine 356 s alte Antwort.
• Cache-Control: public, max-age=2592000, s-maxage=2592000, unveränderlich.
• X-Cache: HIT (oder MISS).

Bei Chrome/Edge: DevTools > Network > Disable cache kann einen ersten Besucher simulieren.

7. Häufige Fallen

1. Unnötige Cookies: Viele WordPress-Themes setzen selbst für öffentliche Seiten ein Cookie. Löschen Sie sie oder deaktivieren Sie sie über functions.php.
2. Query-Strings: Standardmäßig erstellt ?v=123 einen neuen Eintrag im Cache. Versionieren Sie stattdessen im Dateinamen.
3. Sensible Inhalte: Formulare, Kundenbereichsseiten ➡ no-store, private, max-age=0.
4. Brotli/Gzip-Komprimierung: Aktivieren Sie sie vor der Varnish-Schicht, um doppeltes Caching zu vermeiden.

8. Zusammenfassende bewährte Praktiken

• Verwenden Sie s-maxage ⩾ max-age, um einen Proxy-Cache länger als den des Browsers zu halten.
• Setzen Sie immutable auf jede Datei, deren Name einen Hash enthält.
• Vermischen Sie nicht Expires obsolete mit max-age, außer bei älteren Browsern.
• Dokumentieren Sie Ihre TTLs in einer Datei CACHE_POLICY.md für das Team.

9. Nützliche Ressourcen

• LWS: Beschleunigen Sie die Geschwindigkeit Ihrer Website mit Fastest Cache.
• LWS-Blog: Wie Sie mit Varnish Cache eine schnellere Website haben.

✅ Ihr Varnish-Cache ist jetzt unter Kontrolle!