Der Cache ist eingerichtet, die Konfiguration wurde geprüft, die Vorschaltung läuft - und die Last auf der Anwendung bleibt, wo sie war. Dieser Fall ist häufiger als der fehlende Cache und unangenehmer, weil formal alles stimmt. Die Ursache steht selten in der Cache-Konfiguration selbst. Sie steht im Vary-Kopf der Antwort, in einem Sitzungs-Cookie, das auf jeder Antwort neu gesetzt wird, und in den Parametern, die eine Kampagne an die Adresse hängt. Jeder dieser Punkte zerlegt eine Adresse in Varianten, und jede Variante muss beim ersten Aufruf wieder durch die Anwendung. Dieser Beitrag zeigt, wie sich die Zahl der Varianten je Adresse messen lässt, welche Vary-Werte gestrichen werden können, wie Kampagnenparameter aus dem Schlüssel fallen und wann ein personalisierter Baustein besser als eigenes Fragment ausgeliefert wird.
Das Wichtigste in Kürze
- Der Schlüssel eines Caches ist nicht die Adresse allein. Trägt eine gespeicherte Antwort einen Vary-Kopf, darf der Cache sie ohne Revalidierung nur verwenden, wenn alle dort genannten Kopfzeilen mit denen des ursprünglichen Aufrufs übereinstimmen (RFC 9111). Jeder zusätzliche Name im Vary-Wert vervielfacht die Einträge.
- Ein Stern im Vary-Wert ist keine Feinheit, sondern eine Abschaltung: Eine gespeicherte Antwort, deren Vary-Wert ein Sternchen enthält, trifft nie (RFC 9111).
- Ein Set-Cookie verhindert das Ablegen nicht. Der Standard weist ausdrücklich darauf hin, dass eine cachefähige Antwort mit Set-Cookie an weitere Aufrufe ausgeliefert werden kann (RFC 9111) - deshalb verweigern verbreitete Vorschaltungen den Treffer von sich aus, sobald ein Cookie im Spiel ist (Varnish).
- Zur Größenordnung: Eine Website setzt im Median 9 Cookies (Web Almanac 2025). Steht Cookie im Vary-Wert, entsteht je Kombination dieser Werte ein eigener Eintrag - und damit praktisch je Besucher einer.
- Gemessen wird nicht die Trefferquote der ganzen Domain, sondern die Trefferquote je Vorlage. Eine Startseite, die fast immer trifft, und eine Suchergebnisseite, die nie trifft, ergeben zusammen eine Zahl, die nichts erklärt.
- Was personalisiert ist, gehört in ein eigenes Fragment mit eigener Frist: Im Beispiel der Symfony-Dokumentation bleibt der Vollseiten-Cache 600 Sekunden gültig, der Cache des dynamischen Bausteins nur 60 Sekunden (Symfony).
Warum ein fertiger Cache trotzdem nicht trifft
Eine Cache-Ebene aufzubauen ist überschaubare Arbeit: Vorschaltung davor, Fristen setzen, Ausnahmen für Warenkorb und Anmeldung. Wie diese Ebenen ineinandergreifen, steht im Beitrag zu den Cache-Strategien mit Varnish und Redis. Die Fehlersuche an einer bereits gebauten Ebene ist eine andere Arbeit, und sie beginnt an einer Stelle, an die selten jemand schaut: beim Schlüssel, unter dem eine Antwort abgelegt wird.
Der Standard beschreibt den Abgleich eindeutig. Enthält eine gespeicherte Antwort einen Vary-Kopf, darf der Cache sie ohne Revalidierung nur dann verwenden, wenn alle dort genannten Kopfzeilen des neuen Aufrufs mit denen des ursprünglichen Aufrufs übereinstimmen (RFC 9111). Fehlt eine dieser Kopfzeilen im neuen Aufruf, passt sie nur, wenn sie auch im alten fehlte. Aus einer Adresse werden damit so viele Einträge, wie es Kombinationen der genannten Werte gibt - und jeder dieser Einträge muss einmal erzeugt werden, bevor er zum ersten Mal ausgeliefert werden kann.
Am Ende dieser Skala steht ein Wert, der jede weitere Überlegung beendet: Eine gespeicherte Antwort, deren Vary-Wert ein Sternchen enthält, trifft grundsätzlich nie (RFC 9111). Wer diesen Wert in einer Antwort findet, hat keine Feinjustierung vor sich, sondern einen abgeschalteten Cache mit laufenden Kosten - die Vorschaltung fragt jedes Mal beim Ursprung nach und legt dabei weiter Einträge an, die niemand je liest.
Drei Fragen vor jeder Änderung
Vary: jede Ausnahme vervielfacht die Einträge
Die Verbreitung des Kopfes ist überschaubar: In einer Auswertung mobiler Antworten trugen 46,25 Prozent überhaupt einen Vary-Kopf (Web Almanac 2021). Unter denen, die einen tragen, dominiert ein einziger, harmloser Wert. Die Erhebung nennt Accept-Encoding mit 90,3 Prozent, danach User-Agent mit 10,9 Prozent, Origin mit 10,1 Prozent und Accept mit 4,8 Prozent (Web Almanac 2021). Die Reihenfolge ist aufschlussreich, weil der zweite Platz der teuerste Wert der ganzen Liste ist.
Accept-Encoding ist der Normalfall und kostet fast nichts: Es entstehen zwei bis drei Varianten, je nachdem, welche Kompressionsverfahren ausgeliefert werden. User-Agent ist das Gegenteil. Die Dokumentation einer verbreiteten Vorschaltung beschreibt es unmissverständlich: Allein ein einzelner Patchstand desselben Browsers erzeugt mindestens 10 verschiedene User-Agent-Kopfzeilen, nur weil die Betriebssysteme sich unterscheiden (Varnish). Ohne vorherige Normalisierung auf wenige Klassen ist dieser Wert in einem geteilten Cache nicht zu gebrauchen.
Der teuerste Wert in der Praxis steht nicht in dieser Liste, weil er in einer Breitenmessung selten auffällt: Cookie. Ein Cookie-Kopf ist keine Auswahl aus wenigen Möglichkeiten, sondern eine Zeichenkette, die sich je Besucher unterscheidet. Die Empfehlung der Browserdokumentation ist entsprechend deutlich: Wer Cookies benutzt, damit personalisierte Inhalte nicht bei anderen landen, soll Cache-Control: private setzen, statt ein Cookie im Vary-Wert zu nennen (MDN Web Docs). Der Unterschied ist grundsätzlich - private verhindert das Ablegen im geteilten Cache, Vary: Cookie erlaubt es und macht es nur nutzlos.
| Wert im Vary-Kopf | Varianten je Adresse | Einordnung |
|---|---|---|
| Accept-Encoding | zwei bis drei | notwendig, solange komprimiert ausgeliefert wird |
| Accept-Language | eine je angebotener Sprache | vertretbar, wenn die Sprache nicht schon im Pfad steht |
| User-Agent | praktisch unbegrenzt | nur nach Normalisierung auf wenige Geräteklassen |
| Cookie | eine je Wertkombination | fast immer falsch; stattdessen private setzen |
| Origin | eine je aufrufender Herkunft | an Schnittstellen sinnvoll, an Dokumenten nicht |
| Ein Sternchen | keine nutzbare | die Antwort wird abgelegt und nie wieder gefunden |
Dasselbe Muster wiederholt sich bei neueren Verhandlungsköpfen. Die Auswertung der Auslieferungsnetze für 2025 nennt die Client Hints bei 4 Prozent der Anfragen und führt die geringe Verbreitung unter anderem darauf zurück, dass der Cache-Schlüssel am Rand des Netzes explodiert, wenn die Werte ohne Einteilung in Klassen übernommen werden (Web Almanac 2025). Wer seine Auslieferung über ein Auslieferungsnetz mit Edge-Caching betreibt, zahlt jede Variante dort ein zweites Mal - einmal je Standort.
Die Gegenprobe ist einfach und wird selten gemacht: Den Vary-Wert einer Antwort ansehen und für jeden genannten Namen abschätzen, wie viele verschiedene Werte im echten Verkehr vorkommen. Das Produkt dieser Zahlen ist die Zahl der Einträge, die für eine einzige Adresse angelegt werden. Liegt sie über der Zahl der Aufrufe je Frist, kann diese Adresse rechnerisch nie eine nennenswerte Trefferquote erreichen.
Das Sitzungs-Cookie auf jeder Antwort
Der zweite Weg in die Zersplitterung ist noch stiller, weil er ohne Vary auskommt. Viele Anwendungen starten eine Sitzung bei jedem Aufruf - im Rahmenwerk voreingestellt, im Modul nachgerüstet, in einer Erweiterung mitgebracht. Auf jeder Antwort steht dann ein Set-Cookie, auch auf der Kategorieseite, die für alle Besucher gleich aussieht. Wo diese Sitzung tatsächlich gebraucht wird und was sie sonst noch kostet, zeigt der Beitrag zur Sitzungssperre im Warenkorb.
Der Standard selbst hält dabei nichts auf: Set-Cookie hemmt das Caching nicht, und eine cachefähige Antwort mit Set-Cookie kann - und wird häufig - zur Beantwortung weiterer Aufrufe verwendet (RFC 9111). Das ist nicht nur ein Tempoproblem, sondern der Grund, warum die Voreinstellung verbreiteter Vorschaltungen betont vorsichtig ist: In der Standardkonfiguration wird kein Objekt mit einem Set-Cookie aus dem Hintergrundsystem abgelegt, und sobald der Aufrufer einen Cookie-Kopf sendet, geht die Anfrage am Cache vorbei direkt an das Hintergrundsystem (Varnish). Beides zusammen genügt, damit ein sauber eingerichteter Cache im Betrieb praktisch nie antwortet.
In der Breite ist das kein Randfall. In einer Messung trugen 36,0 Prozent der cachefähigen Antworten auf Mobilgeräten ein Set-Cookie, auf stationären Geräten 35,6 Prozent; zugleich nutzten nur etwa 5 Prozent der Seiten dazu die private-Anweisung (Web Almanac 2021). Jede dieser Antworten ist entweder nicht ablegbar oder liegt mit einer fremden Sitzung im geteilten Cache.
# Vorher: die Anwendung startet auf jedem Aufruf eine Sitzung
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: SESSID=7f3c9a...; Path=/; HttpOnly; SameSite=Lax
Cache-Control: public, s-maxage=600
Vary: Cookie, Accept-Encoding
# Folge: ein Eintrag je Cookie-Wert, also praktisch je Besucher.
# Der erste Aufruf jeder Variante schlägt auf die Anwendung durch.
# Nachher: Sitzung nur auf den Wegen, die sie brauchen
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: public, s-maxage=600, stale-while-revalidate=60
Vary: Accept-Encoding
# Sind einzelne Felder wirklich persönlich, bleibt die qualifizierte Form:
# der geteilte Cache legt das genannte Feld nicht ab, den Rest schon.
Cache-Control: s-maxage=600, private="Set-Cookie"
Der Ausweg ist nicht, das Cookie zu verstecken, sondern es dort nicht entstehen zu lassen. Drei Schritte in dieser Reihenfolge: die Sitzung nur auf den Wegen starten, die sie brauchen; das Cookie beim Ablegen aus der Antwort entfernen, aber ausschließlich auf Wegen, die nachweislich für alle gleich sind; und dort, wo einzelne Felder wirklich persönlich sind, die qualifizierte Form nutzen. Der Standard erlaubt sie ausdrücklich: Ein geteilter Cache darf die genannten Kopfzeilen nicht speichern, den Rest der Nachricht aber sehr wohl (RFC 9111).
Vary auf Cookie
Erzeugt je Wertkombination einen Eintrag. Weil sich ein Cookie-Kopf je Besucher unterscheidet, ist die Zahl der Einträge am Ende die Zahl der Besucher.
Set-Cookie auf jeder Antwort
Verhindert das Ablegen in vielen Vorschaltungen von vornherein - und wo es das nicht tut, wandert eine fremde Sitzung in den geteilten Cache.
Parameter aus Kampagnen
Jede Kennung in der Adresse erzeugt einen eigenen Eintrag, obwohl das ausgelieferte Dokument Zeichen für Zeichen dasselbe ist.
Einwilligungsstand in der Antwort
Wird der Stand serverseitig in das Dokument gerendert, ist jede Antwort persönlich. Besser ist ein Wert, der erst im Browser wirkt.
Sprache doppelt verhandelt
Steht die Sprache im Pfad und zusätzlich im Vary-Wert, verdoppelt sich die Zahl der Einträge ohne jeden Gewinn an Richtigkeit.
Geräteklasse ohne Normalisierung
Wer nach dem vollständigen Browserkennzeichen unterscheidet, legt für jede Betriebssystemfassung eine eigene Kopie an.
Die Reihenfolge, die sich bewährt hat
Die Trefferquote je Vorlage messen
Vor jeder Änderung steht eine Ausgangszahl, und zwar nicht eine einzige. Eine Trefferquote über die ganze Domain mittelt die Startseite, die praktisch immer trifft, mit der Suchergebnisseite, die nie trifft. Welche Vorlagen es überhaupt gibt und wie man den Bestand danach gruppiert, steht im Beitrag Vorlage statt Startseite. Für die Cache-Diagnose ist dieselbe Gruppierung die Voraussetzung dafür, dass ein Befund überhaupt einen Adressaten hat.
Die Quelle ist das Zugriffsprotokoll der Vorschaltung, nicht ein Messwerkzeug im Browser. Drei Felder genügen: der Trefferstatus, die Vorlage und die Adresse ohne Parameter. Die Vorlage setzt die Anwendung selbst als Antwortkopf - aus dem Pfad geraten wird sie erfahrungsgemäß falsch, sobald es Sonderseiten gibt. Wie viel ein Fehltreffer tatsächlich kostet, zeigt daneben der Serveranteil je Antwort; ihn bis in den Browser zu tragen, ist die Aufgabe von Server-Timing.
# Die Vorschaltung schreibt Trefferstatus und Vorlage in eine eigene Zeile:
# log_format cache '$time_iso8601 $upstream_cache_status '
# '$sent_http_x_vorlage $uri';
# Aufrufe und Treffer je Vorlage, absteigend nach Aufrufen
awk '{ n[$3]++; if ($2 == "HIT") h[$3]++ }
END { for (v in n)
printf "%-18s %8d Aufrufe %6.1f Treffer je hundert\n",
v, n[v], 100 * h[v] / n[v] }' \
/var/log/nginx/cache.log | sort -k2 -nr
# Welche Kopfzeilen erzeugen zu EINER Adresse mehrere Einträge?
varnishlog -g request -q 'ReqURL eq "/kategorie/laufschuhe"' \
-i ReqHeader -I 'Accept-Encoding|Accept-Language|Cookie' \
| sort | uniq -c | sort -nr | head -20
# Obergrenze der Trefferquote: Anteil der Adressen mit genau einem Aufruf
awk '{ print $4 }' /var/log/nginx/cache.log | sort | uniq -c \
| awk '{ gesamt++; if ($1 == 1) einmal++ }
END { print einmal, "von", gesamt, "Adressen nur einmal aufgerufen" }'
- Trefferstatus je Antwort mitschreiben, nicht nur die Gesamtzahl der Treffer aus der Statistik der Vorschaltung übernehmen.
- Vorlage als eigenes Feld führen, von der Anwendung gesetzt - Kategorie, Detail, Suche, Inhaltsseite, Startseite.
- Zahl der gespeicherten Varianten je Adresse erheben; sie ist die eigentliche Kennzahl dieser Diagnose.
- Anteil der Adressen bestimmen, die im Zeitraum nur ein einziges Mal aufgerufen wurden - er ist die Obergrenze jeder erreichbaren Trefferquote.
- Serveranteil je Antwort daneben legen, damit sich beziffern lässt, was ein Fehltreffer kostet.
- Messung über mindestens eine volle Woche laufen lassen, damit Wochenende, Versandtag und Kampagnenstart enthalten sind.
Die Zahl, die fast immer fehlt
Kampagnenparameter und der Schlüssel der Adresse
Der dritte Weg in die Zersplitterung führt über die Adresse selbst. Für den Besucher und für die Anwendung ist /kategorie/laufschuhe dieselbe Seite wie /kategorie/laufschuhe?utm_source=newsletter. Für den Cache sind es zwei Einträge, und mit jeder weiteren Kennung - Klickkennung des Anzeigennetzes, Versandnummer des Newsletters, Testgruppe eines Versuchsaufbaus - kommt einer dazu. Ein einziger Newsletterversand kann so an einem Vormittag mehr Einträge erzeugen als der gesamte organische Verkehr einer Woche.
Der Umbau ist schnell beschrieben und im Detail heikel: Eine Positivliste der Parameter, die den ausgelieferten Inhalt wirklich verändern, geht in den Schlüssel; alles andere fällt vor dem Nachschlagen heraus. Entscheidend ist die Richtung der Liste. Wer stattdessen eine Sperrliste pflegt, hat beim nächsten Kampagnenwerkzeug eine neue Kennung im Schlüssel und merkt es erst an der Last. Dass diese Vervielfachung kein Einzelfall eines Systems ist, zeigt der Cache-Hash in einem redaktionellen System, der nach demselben Prinzip aus Parametern entsteht.
# Schlüssel aus Pfad und einer festen Positivliste von Parametern.
# Alles, was nicht genannt ist - Kampagne, Klick-Kennung, Testgruppe -,
# fällt vor dem Nachschlagen heraus.
proxy_cache_key "$scheme$host$uri|s=$arg_seite|o=$arg_sortierung|f=$arg_filter";
# Vary auf das Nötige begrenzen. Die Anwendung darf weiterhin senden,
# was sie will; abgelegt wird die gekürzte Fassung.
proxy_hide_header Vary;
add_header Vary "Accept-Encoding" always;
# Sitzungs-Cookie aus der abgelegten Antwort entfernen - NUR auf Wegen,
# die nachweislich für alle Besucher gleich sind.
location ^~ /kategorie/ {
proxy_ignore_headers Set-Cookie;
proxy_hide_header Set-Cookie;
proxy_cache seiten;
proxy_cache_valid 200 10m;
# Trefferstatus und Vorlage mitschreiben, damit die Messung eine Quelle hat
add_header X-Cache-Status $upstream_cache_status always;
access_log /var/log/nginx/cache.log cache;
}
Zwei Nebenwirkungen gehören in die Abnahme. Erstens: Werden Parameter aus dem Schlüssel entfernt, die Anwendung aber weiterhin mit ihnen aufgerufen, liefert der Cache unter Umständen eine Antwort aus, die für eine andere Kennung erzeugt wurde - das ist unkritisch bei Kampagnenkennungen und kritisch bei allem, was den Inhalt steuert. Zweitens: Wer Set-Cookie aus abgelegten Antworten entfernt, muss diesen Weg auf Pfade begrenzen, die nachweislich für alle Besucher gleich sind. In einem Shop heißt das in der Regel Kategorie, Detail und Inhaltsseite, nicht Warenkorb und nicht Kasse - eine Abgrenzung, die im Beitrag zur Shopware-Performance an einem konkreten System durchgespielt wird.
Personalisierte Bausteine als eigenes Fragment
Bleibt der Fall, der die ganze Diskussion auslöst: Auf der Seite steht etwas, das für jeden Besucher anders aussieht - der Warenkorbzähler, die Begrüßung mit Namen, der zuletzt gesehene Artikel, der Stand der Einwilligung. Solange dieser Baustein im selben Dokument steckt, ist das ganze Dokument persönlich. Ein Vollseiten-Cache kann es dann nur falsch machen: Entweder er legt es nicht ab, oder er liefert einer fremden Person einen fremden Warenkorb.
Die Trennung löst das, indem sie zwei Fristen nebeneinander stellt. Das Dokument bekommt eine lange Frist und ist für alle gleich, der persönliche Teil bekommt einen eigenen Aufruf und eine kurze Frist. Die Symfony-Dokumentation zeigt die Rechnung an einem Beispiel: Mit Edge Side Includes bleibt der Vollseiten-Cache 600 Sekunden gültig, der Cache des Nachrichtenbausteins nur 60 Sekunden (Symfony). Das Verhältnis ist der Punkt, nicht die absoluten Werte - die Seite lebt zehnmal so lange wie ihr beweglichster Teil.
<!-- Dokument: lange Frist, für alle Besucher gleich
Antwortkopf: Cache-Control: public, s-maxage=600 -->
<header class="kopf">
<a class="marke" href="/">Beispielshop</a>
<!-- Persönlicher Teil als eigener Aufruf mit eigener Frist
Antwortkopf des Fragments: Cache-Control: private, no-store -->
<esi:include src="/fragment/warenkorb" onerror="continue"/>
</header>
<!-- Ohne Vorschaltung mit ESI dasselbe im Browser. Der Platz wird
vorgehalten, damit beim Nachtragen nichts verrutscht. -->
<div id="warenkorb" style="min-height:28px"></div>
<script type="module">
const antwort = await fetch('/fragment/warenkorb', { credentials: 'same-origin' });
if (antwort.ok) {
document.getElementById('warenkorb').innerHTML = await antwort.text();
}
</script>
Wer keine Vorschaltung mit Fragmentunterstützung betreibt, erreicht dasselbe im Browser: Das Dokument wird statisch ausgeliefert, der persönliche Teil kommt als kleiner Abruf nach. Die Kosten sind ein zusätzlicher Aufruf und eine mögliche Layoutverschiebung, wenn der Platz nicht vorgehalten wird. Bei Einwilligungsschichten ist genau das der bekannte Fehler - wie er sich vermeiden lässt, steht im Beitrag zu Einwilligungsbannern und dem größten Inhaltsaufbau. Und wo der persönliche Teil selbst Messdaten sammelt, gelten die Grenzen aus der Messung ohne Einwilligung.
Reihenfolge der Arbeit und Abnahme
Die Diagnose endet mit einer Liste, die sich abarbeiten lässt, und einer Zahl, an der man das Ergebnis später wiedererkennt. Beides gehört in dieselbe Woche: Wer den Ausgangswert nicht erhebt, bevor die erste Zeile geändert wird, hat hinterher eine Vermutung statt eines Nachweises. Liegt der Schwerpunkt der verbleibenden Last im Hintergrundsystem, führt der Weg weiter über die Server-Optimierung; liegt er in der Zahl der Varianten, bleibt es bei der Arbeit am Schlüssel.
- Trefferstatus, Vorlage und Adresse ohne Parameter ins Zugriffsprotokoll aufnehmen und eine volle Woche sammeln.
- Je Vorlage Aufrufe, Treffer und Varianten je Adresse auswerten und die drei Vorlagen mit der größten Menge an Fehltreffern benennen.
- Den Vary-Wert dieser Vorlagen auf das Nötige kürzen und jede Streichung einzeln ausrollen, damit die Wirkung zuzuordnen bleibt.
- Sitzungen nur noch dort starten, wo sie gebraucht werden, und Set-Cookie auf den freigegebenen Pfaden aus der abgelegten Antwort entfernen.
- Kampagnenparameter über eine Positivliste aus dem Schlüssel nehmen und die Liste an derselben Stelle pflegen wie die Kampagnen.
- Personalisierte Bausteine heraustrennen und der Seite die lange, dem Baustein die kurze Frist geben.
- Nach zwei Wochen dieselbe Auswertung wiederholen und Trefferquote je Vorlage, Varianten je Adresse und Last im Hintergrundsystem nebeneinander stellen.
Ein Cache, der nicht trifft, ist kein halber Cache. Er ist eine zusätzliche Schicht, die Arbeit kostet und nichts spart. Der Unterschied steht selten in der Konfiguration und fast immer in der Zahl der Varianten je Adresse.
Der Aufwand dieser Diagnose ist gering im Verhältnis zu dem, was sie verhindert: ein größerer Server, der dasselbe Problem teurer löst. Meist genügen ein erweitertes Protokollformat, eine Auswertung und zwei bis drei Änderungen an Kopfzeilen. Wenn Sie den Einstieg abkürzen möchten: In einer Performance-Analyse zählen wir die Varianten je Adresse, benennen die Ursache je Vorlage und legen gemeinsam fest, welche Trefferquote je Vorlage in die Abnahme geschrieben wird. Wie der Cache in die übrige Auslieferung eingebettet ist, beschreibt daneben die Leistungsseite zu den Caching-Strategien.
Cache-Control: private vorgesehen, und die Browserdokumentation empfiehlt sie ausdrücklich anstelle eines Cookies im Vary-Wert (MDN Web Docs). Sinnvoll bleibt der Wert nur, wenn ein einzelnes Cookie eine kleine, bekannte Zahl von Zuständen hat und die Vorschaltung den Kopf vorher auf genau diesen Wert normalisiert - etwa eine Währung oder eine Filiale mit einer Handvoll Ausprägungen. Der Rohwert des Cookie-Kopfes gehört nie in den Schlüssel.Verwandte Artikel
TYPO3-Performance: Caching und Ladezeit im Griff behalten
Wie der Seiten-Cache in TYPO3 arbeitet, welche Einstellungen ihn aushebeln und wie Cache-Hash, Backends und das Deployment die Ladezeit einer Seite bestimmen.
KI-Crawler-Last: Wenn Bots den Server ausbremsen
Bots erzeugen über die Hälfte der HTML-Anfragen. Warum KI-Crawler uncachebare Long-Tail-URLs treffen, wie Sie die Last messen und drosseln statt blocken.
CDN und Edge-Caching für Shop-Performance 2026
Wie CDN, Edge-Caching und durchdachte Cache-Control-Header die Time to First Byte weltweit senken und Ihren Shop auch fern vom Origin schnell ausliefern.