Unabhängiger Vergleich · keine bezahlten Platzierungen
Startseite / Blog / Technik / Dynamisches Seiten-Caching: Entscheiden, was tatsächlich zwischengespeichert werden kann

Dynamisches Seiten-Caching: Entscheiden, was tatsächlich zwischengespeichert werden kann

Das Zwischenspeichern der „Homepage“ scheint einfach zu sein – bis ein verbundenes Banner, ein Warenkorb und A/B-Tests jeden Besuch einzigartig machen.

Redaktion Hébergeurs.eu 4 Min. Aktualisiert 19 Juli 2026

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?

InhaltVollständiger Seitencache?Alternative
Artikel veröffentlicht statischJa (TTL + Spülung)CDN langer Cache
Startseite RedaktionslisteJa kurze TTLZum Veröffentlichen löschen
SuchergebnisseSelten (Abfragezeichenfolge)Standardisierter Schlüsselcache
Konto-/AdministratorseiteNeinCache umgehen
Warenkorb / KasseNeinkein Laden
Echtzeit-AktienkursNein auf ShellAJAX-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.

Europäische Hoster vergleichen

Filtern nach Compliance, Standort und Einsatzzweck — dann die Datenblätter öffnen, um den echten Umfang zu prüfen.

Verzeichnis durchsuchen
Blog

Weiterlesen

Alle Artikel →