Ganz ehrlich: Über Caches denkt niemand freiwillig nach. Bis die Seite langsam ist, im Meeting jemand “aktivier doch mal den Cache” sagt und die nächste Frage im Raum steht: welchen denn?
Denn es sind drei. Sie liegen hintereinander, und jede weitere kostet Zeit. Dabei ist ein Cache immer dasselbe: eine fertige Kopie, damit dieselbe Arbeit nicht zweimal gemacht werden muss. Interessant ist nur, wo diese Kopie liegt und wie weit sie von deinem Besucher entfernt ist.
Ein Besucher ruft deine Seite auf
nicht da, also weiter
nicht da, also weiter
nicht da, also weiter
Die drei Schichten, in normaler Sprache
Der Browser-Cache: die Kopie beim Besucher
Der schnellste Cache ist der, bei dem gar keine Anfrage rausgeht. Der Browser hat die Datei noch auf dem Gerät und nimmt sie von dort. Kein Netz, keine Wartezeit.
Der Haken liegt auf der Hand: Beim ersten Besuch ist dieser Cache leer. Für jeden neuen Besucher, also für jeden, den deine Kampagne gerade bringt, existiert er nicht. Der Browser-Cache belohnt Stammkunden. Neukunden sieht er nie.
Der CDN-Cache: die Kopie in der Nähe
Ein CDN ist ein Netz aus Servern in vielen Ländern, das deine Seite von dem Standort ausliefert, der dem Besucher am nächsten ist. Gespart wird hier nicht nur Arbeit, sondern Entfernung: Ein Besucher in Sydney bekommt seine Antwort aus Sydney statt aus Frankfurt.
Der große Hebel steckt darin, auch die Seite selbst zu cachen, nicht nur Bilder und Skripte. Bei Bildern macht das jeder, bei der Seite kaum jemand. Und genau dort sitzt die Wartezeit, die der Besucher vor dem leeren Bildschirm verbringt.
Der Origin-Cache: die fertige Seite auf deinem Server
Kommt die Anfrage doch bei dir an, entscheidet die dritte Schicht, wie teuer sie wird. Der Origin-Cache hält die fertig gebaute Seite bereit, statt sie jedes Mal neu zusammenzusetzen.
Hier ist der Unterschied am größten. Mit Kopie: einmal rausschicken. Ohne Kopie: Datenbank fragen, Preise rechnen, Templates rendern, Verfügbarkeiten prüfen. Deshalb der Sprung von 150 auf 600 Millisekunden in der Grafik.
Für den Besucher sind diese drei Schichten übrigens nicht unterscheidbar. Er merkt nur, ob die Seite sofort da ist oder nicht.
HIT und MISS: die zwei Wörter, die zählen
Caches beschreiben ihr Ergebnis immer mit denselben Wörtern. Zwei davon reichen für den Anfang:
- HIT: Die Kopie war da, sie ging direkt raus. Der gute Fall.
- MISS: Die Kopie war nicht da, die Anfrage musste eine Schicht tiefer.
Sobald du in ein Dashboard oder ein Server-Log schaust, tauchen ein paar Zwischenstufen auf. Du musst sie nicht auswendig kennen, nur einordnen können: EXPIRED heißt, die Kopie war zu alt und wurde erneuert. STALE heißt, eine alte Kopie ging bewusst raus, um Zeit zu sparen. REVALIDATED heißt, die Kopie wurde geprüft und war noch gültig. BYPASS, PASS, DYNAMIC und NONE heißen alle dasselbe in Varianten: Für diese Anfrage war der Cache nicht zuständig.
Ein Punkt ist dabei wichtig, weil er oft untergeht: Diese Wörter gelten pro Schicht. Ein HIT im CDN und ein MISS im Origin-Cache sind zwei getrennte Aussagen. Erst zusammen ergeben sie ein Bild davon, wer eigentlich geantwortet hat.
Warum das nicht nur Technik ist
Die Zeit bis zum ersten Byte, in Berichten TTFB genannt, ist der Boden, auf dem alles andere steht. Solange sie läuft, sieht dein Besucher nichts. Kein Bild, keine Überschrift, keinen Button. Der Browser kann nichts anzeigen, was er noch nicht bekommen hat.
Zwei Konsequenzen, die über die Technik hinausgehen:
Google bewertet, was echte Besucher erleben. Für das Ranking zählen die Core Web Vitals aus echten Chrome-Besuchen, nicht der Testlauf auf dem Rechner deiner Agentur. Welche Cache-Schicht geantwortet hat, ist damit ein Ranking-Faktor, auch wenn er auf keiner Rechnung steht.
Wartezeit kostet genau dort, wo du sie am wenigsten brauchst. Bezahlten Traffic schickst du auf Landingpages. Deren Besucher kommen zum ersten Mal, haben also keinen Browser-Cache, und landen oft auf URLs mit Kampagnen-Parametern. Wenn irgendwo die Kopie fehlt, zahlt genau dieser Besuch die Wartezeit.
Und hier ist die Falle, die moderne Hosting-Plattformen aufstellen. Antworten aus dem Edge-Cache sehen fantastisch aus, ein Fehlschlag daneben kann zehnmal langsamer sein. Im Durchschnitt verschwindet dieser Unterschied vollständig. Deshalb ist die Trefferquote die Zahl, auf die es ankommt, nicht der Mittelwert.
Ein Cache ist also kein Schalter, den man einmal umlegt. Er ist eine Quote, und die schwankt.
Was einen Cache im Alltag kaputt macht
Drei Dinge erklären die meisten schlechten Trefferquoten, und alle drei kommen selten aus der Technik-Ecke:
- Kampagnen-Parameter. Hängt an jedem Link ein
?utm_source=..., ist das für viele Caches eine andere Adresse und damit eine eigene Kopie. Im schlimmsten Fall bekommt jeder Kampagnen-Klick einen MISS. Gut konfigurierte Caches ignorieren bekannte Tracking-Parameter beim Nachschauen. Das muss man ihnen aber sagen. - Cookies. Setzt eine Antwort ein Cookie oder liest eines, behandeln viele Caches sie als persönlich und cachen sie gar nicht. Ein neu eingebautes Tool, ein Consent-Banner, ein A/B-Test: Solche Dinge können eine gute Trefferquote über Nacht halbieren, ohne dass jemand etwas “an der Performance” geändert hat.
- Jeder Release. Nach einem Deploy ist der Cache erst einmal leer. Die ersten Besucher danach bezahlen den Wiederaufbau. Bei zehn Deploys pro Woche ist das kein Randfall, sondern Alltag.
Alle drei sieht man nicht, wenn man auf einen Durchschnitt schaut. Man sieht sie, wenn man die Trefferquote pro Schicht kennt und weiß, wann sie gefallen ist.
Was du deinen Entwicklern sagen kannst
Deine Server kennen jede dieser Antworten. Sie sagen es nur niemandem, solange man sie nicht darum bittet. Dafür gibt es einen Standard-Header, den der Browser bei jedem Besuch mitliefert:
Server-Timing: cdn-cache;desc="HIT", fm-fpc;desc="MISS", db;dur=48
Übersetzt: Das CDN hatte die Kopie, der Origin-Cache nicht, und die Datenbank brauchte 48 Millisekunden. Vier Zeilen in der Server-Konfiguration reichen dafür.
fastmon liest beide Schichten getrennt aus, aus jedem echten Besuch, und stellt die Trefferquote direkt neben die Ladezeit. Seitenaufrufe ohne Angabe erscheinen als “Unbekannt”, und auch das ist eine Aussage: Dort weiß aktuell niemand, was passiert.
Hinweis: Welche Header-Namen fastmon erkennt und was jeder Status bedeutet, steht in unserer Doku zu Server-Timing. Der Link ist genau das, was deine Entwickler brauchen.
Was du mitnimmst
Drei Schichten, eine Reihenfolge, eine Frage: Wer hat geantwortet? Der Browser-Cache hilft nur Wiederkehrern. Das CDN entscheidet über die Entfernung, wenn du auch die Seite selbst cachst. Der Origin-Cache entscheidet, wie teuer ein Fehlschlag wird.
Und die Trefferquote ist keine Einstellung, die man abhaken kann. Sie ist eine Zahl, die man im Blick behält. Real User Monitoring zeigt sie dir aus jedem echten Besuch, statt sie im Labor zu schätzen.