Das Team aktiviert den Ganzseiten-Cache. Die TTFB sinkt von 800 ms auf 40 ms – Sieg. Abgesehen davon, dass das „Hallo Admin“-Banner anonymen Besuchern angezeigt wird, der Warenkorbzähler für alle 0 anzeigt und der A/B-Test sechs Stunden lang Variante B für 100 % der Benutzer bereitstellt.
Der dynamische Seitencache ist kein Schalter. Es handelt sich um einen Variabilitätsvertrag: Welche Teile der HTML-Antwort sind für welche Benutzersegmente und für wie lange gleich. Schlecht definiert, beschleunigt es die Website, indem es stille Bugs erzeugt – schlimmer als ehrliche Langsamkeit.
Matrix: zwischenspeicherbar oder nicht?
| Inhalt | Vollständiger Seitencache? | Alternative |
|---|---|---|
| Artikel veröffentlicht statisch | Ja (TTL + Spülung) | CDN langer Cache |
| Startseite Redaktionsliste | Ja kurze TTL | Zum Veröffentlichen löschen |
| Suchergebnisse | Selten (Abfragezeichenfolge) | Standardisierter Schlüsselcache |
| Konto-/Administratorseite | Nein | Cache umgehen |
| Warenkorb / Kasse | Nein | kein Laden |
| Echtzeit-Aktienkurs | Nein auf Shell | AJAX-Fragment |
Goldene Regel: Wenn Set-Cookie oder Vary: Cookie erforderlich ist, ist der Seitenrand-Cache verdächtig.
Cache-Schlüssel: Was unterscheidet die Antworten?
Für einen Blog reicht ein naiver „URL“-Schlüssel. Kombinieren Sie für eine dynamische Site URL, Sprache, Geräteklasse, A/B-Bucket-Test und Authentifizierungssegment – nicht die Benutzer-ID im vollständigen Seitenschlüssel (zu viele Variationen). Whitelist der Abfrageparameter. Cache umgehen, wenn Sitzungscookie vorhanden ist.
Strategien pro Stapel
WordPress: Objekt-Cache plus Seiten-Cache, „/wp-admin“-Ausschluss, WooCommerce-Warenkorb-Cookies.
Symfony / Laravel: HTTP-Kernel-Cache, Redis-Tag-Ungültigmachung, ESI für Benutzerblöcke.
Headless: CDN auf öffentlichem JSON; niemals auf schlüssellos authentifizierten Endpunkten.
nginx fastcgi_cache: „fastcgi_cache_bypass“ und „fastcgi_no_cache“ bei Sitzungscookie.
Invalidierung: Panik vermeiden „Alles spülen“
TTL nur für unkritische Inhalte. URL bei Änderung löschen. Tags/Ersatzschlüssel zum CMS-Beitrag. Verbotsmuster bei der Neugestaltung des Themas – mit Vorsicht beim Originalbild. Löschen Sie bei der Veröffentlichung die Startseite sowie die Taxonomien und den Artikel.
Siehe HTTP-Cache-Header und Varnish: verbundene Benutzer.
CDN plus Ursprung: zwei Ebenen
Edge-Cache entlastet den Ursprung. Konsistenter Ursprung → Rand der „Cache-Control“-Header. „s-maxage“ für CDN, „max-age“ für Browser. Antworten nicht mit „Set-Cookie“ ausblenden, es sei denn, Edge wurde explizit konfiguriert.
Die Spitze: Cache beschleunigt oder lügt – selten beides ohne Design
Messen Sie die Trefferquote und die funktionale Fehlerrate nach dem Cache.
Entscheide dich und gehe ohne blinden Fleck voran
Klassifizieren Sie URLs zunächst als zwischenspeicherbar, nicht zwischenspeicherbar oder fragmentiert. Schlüssel festlegen und mit und ohne Sitzung testen. Verknüpfen Sie die Ungültigmachung mit der CMS-Veröffentlichung. Überprüfen Sie die Ursprungs- und CDN-Header (curl -I). Überwachen Sie HIT/MISS sowie veraltete Warnungen über die Geschäfts-TTL hinaus. Vergleichen Sie Surrogate-Key-kompatible Hosts über das Verzeichnis.
Häufig gestellte Fragen
Können wir eine Seite mit einem angemeldeten Benutzer ausblenden?
Selten wird eine ganze Seite zwischengespeichert. Trennen Sie eine öffentliche, zwischenspeicherbare Shell und in AJAX oder ESI geladene private Blöcke oder definieren Sie strenge Schlüssel pro Rolle – ohne jemals eine Mitgliederseite einem anonymen Besucher bereitzustellen.
Welche TTL-Dauer für eine Nachrichtenseite?
Warten Sie für Startseiten und Listen 60 bis 300 Sekunden mit der Löschung bei der Veröffentlichung. Veröffentlichte Inhalte können länger gültig sein. Der Warenkorb und die Kasse dürfen niemals einen Ganzseiten-Cache durchlaufen.
Wie entwerte ich richtig?
Steuern Sie die Löschung nach Ereignis: URL-Schlüssel, Tag oder Ersatzschlüssel bei jeder CMS-Sicherung. Reservieren Sie die globale Spülung für Vorfälle, bei denen Sie eine Lastspitze am Ursprung akzeptieren.
Redis oder Dateien für den Seitencache?
Dateien (Varnish, fastcgi_cache nginx) zeichnen sich durch ihren Rohdurchsatz aus. Redis eignet sich für feinkörnige Invalidierungen nach Tags. Die gängigste Architektur kombiniert CDN am Edge und Ursprungscache.
Dynamisches Caching beginnt mit der Auflistung dessen, was falsch bleiben soll – und nicht, was schnell gehen kann.
