Im Gespräch mit dem Hoster fällt der Begriff fast immer: „Haben Sie schon den Cache geleert?" Das Wort klingt nach einem geheimen Knopf, der Webseiten schneller macht oder kaputte Anzeigen repariert. In Wirklichkeit ist Caching keine versteckte Zusatzfunktion, sondern eine eingebaute Schichten-Logik des Web.
Wer diese Schichten kennt, versteht zwei Dinge: warum „Cache leeren" manchmal hilft und meistens überflüssig ist, und warum dieselbe Webseite für zwei Besucher unterschiedlich schnell wirken kann. Du brauchst dafür kein Entwickler-Wissen, sondern ein mentales Modell mit drei Ebenen.
Was Caching eigentlich macht
Caching heißt: eine Antwort einmal erzeugen, dann zwischenspeichern und beim nächsten Mal wiederverwenden. Ein Browser lädt ein Bild einmal vom Server, legt es in den lokalen Speicher und zeigt es beim nächsten Aufruf direkt aus dem eigenen Vorrat. Der Server muss nicht noch einmal liefern, das Netz nicht noch einmal übertragen.
Vergleichbar mit einer Notiz am Schreibtisch. Du schlägst eine häufig gebrauchte Telefonnummer einmal im Adressbuch nach und klebst sie als Zettel an den Monitor. Beim nächsten Anruf greifst Du nicht ins Archiv, sondern liest vom Zettel ab. Spart Zeit, spart Wege.
Genau diese Idee steckt im Web an mehreren Stellen gleichzeitig. Der Browser cached. Der Server cached. Und ein vorgeschaltetes Netzwerk kann zusätzlich cachen. Drei Schichten, ein Mechanismus, jede mit eigener Reichweite und eigener Lebensdauer.
Browser-Cache — was Dein Besucher mitnimmt
Die erste Schicht sitzt direkt auf dem Gerät des Besuchers. Wenn jemand Deine Webseite öffnet, lädt der Browser Bilder, CSS-Dateien, Schriften und JavaScript herunter und legt sie in seinem lokalen Speicher ab. Beim nächsten Aufruf derselben Seite zieht der Browser diese Bausteine aus dem eigenen Vorrat.
Folge: die zweite Seitenansicht ist spürbar kürzer als die erste. Sichtbar wird das in den Core Web Vitals, vor allem beim Largest Contentful Paint. Das ist der Zeitpunkt, an dem das größte sichtbare Element fertig geladen ist. Wer wiederkehrt, sieht die Seite oft in einem Bruchteil der Erstaufruf-Zeit.
Wie lange der Browser eine Datei aufhebt, entscheiden die Cache-Header, die der Server mitschickt. Ein Logo bekommt vielleicht eine Lebensdauer von einem Jahr, eine HTML-Seite oft nur Minuten oder gar nicht. Der Server gibt vor, der Browser hält sich daran.
Praktische Konsequenz für Dich als Betreiber: nach einem Layout-Update sieht ein Stammbesucher manchmal noch die alte Version. Das ist kein Bug, sondern Browser-Cache. Ein normaler Reload (F5) holt oft nur das HTML neu und behält Bilder und CSS aus dem Vorrat. Erst ein harter Reload (Strg+Shift+R bzw. Cmd+Shift+R) zwingt den Browser, alle Bausteine frisch zu laden.
Server-Cache und CDN — wenn die Seite gar nicht gebaut wird
Die zweite Schicht sitzt auf Deinem Hoster. Ein CMS wie TYPO3 oder WordPress baut eine Seite aus vielen Bauteilen zusammen: Datenbank-Abfragen, Templates, Bilder, Plugins. Dieser Bau-Vorgang kostet Rechenzeit. Bei jedem Aufruf neu zu bauen wäre Verschwendung, weil sich der Inhalt selten ändert.
Der Server-Cache löst das, indem er die fertig zusammengebaute Seite zwischenspeichert. Der nächste Aufruf bekommt direkt die Kopie geliefert, ohne den Bau-Vorgang zu wiederholen. Erst wenn Du einen Inhalt änderst oder die Cache-Lebensdauer abläuft, wird die Seite neu gebaut.
Wirkung: weniger Last auf dem Server, schnellere Auslieferung, weniger Datenbank-Anfragen. Managed Hoster bringen das oft mit, als TYPO3- oder WordPress-Cache, der automatisch greift. Bei Shared-Tarifen ohne CMS-Cache übernimmt das CMS selbst die Speicherung.
Die dritte Schicht ist das CDN, das Content Delivery Network. Ein Beispiel: Dein Server steht in Frankfurt. Ein Besucher aus Australien wartet auf jedes Bild die volle Funkstrecke. Ein CDN legt Kopien Deiner Seite auf Server in verschiedenen Erdteilen. Der Besucher bekommt die Daten vom geografisch nächsten Knoten.
Für eine kleine Seite mit überwiegend lokalem Publikum ist ein CDN selten der Engpass. Sobald Besucher aus mehreren Kontinenten kommen oder die Seite eine große Bild-Last hat, lohnt sich der zusätzliche Aufwand. Bei rein deutscher Zielgruppe bleibt es Overhead.
Cache leeren — wann, wo, warum nicht ständig
Drei typische Anlässe lassen Dich an den Cache denken. Erstens ein Layout-Update, bei dem Stammbesucher noch die alte Optik sehen. Zweitens ein ausgetauschtes Bild, das unter altem Dateinamen liegen bleibt. Drittens mysteriöse Anzeige-Fehler, bei denen niemand weiß, woran es liegt.
Geleert wird je nach Schicht an unterschiedlichen Stellen:
- Browser: harter Reload mit Strg+Shift+R, oder die Browser-Einstellungen für den lokalen Speicher.
- Server: im Backend des CMS, oft als „Cache leeren"-Button im Admin-Bereich.
- CDN: im Dashboard des CDN-Anbieters, meist als „Purge Cache" oder „Invalidate".
Wichtig: das Leeren ist kein Aufräum-Ritual, das man präventiv mitnimmt. Jeder geleerte Cache zwingt die nächsten Besucher zur vollen Aufbau-Zeit. Wer bei jedem kleinen Edit pauschal alles flusht, verschenkt genau den Geschwindigkeits-Vorteil, den Caching liefert.
Cache-Pflege gehört in den festen Pflege-Rhythmus: nach größeren Layout-Updates, nach Bild-Austausch, nach unerklärlichen Anzeige-Fehlern. Nicht nach jedem Komma-Edit. Die Faustregel: leeren, wenn Du gezielt einen Effekt erwartest, sonst ruhen lassen.
Fazit — Caching ist Schichten-Logik, kein Knopf
Caching erscheint mysteriös, solange man es als Ein-Schalter denkt. Die drei Ebenen Browser, Server und CDN folgen alle derselben Logik: Antworten zwischenspeichern statt jedes Mal neu erzeugen. Wer das Modell im Kopf hat, kann gezielt fragen, wo geleert werden muss, und gezielt darauf verzichten, wenn es nichts bringt.
Wie Du den Cache in einem bestimmten Browser konkret leerst, gehört nicht in dieses Modell, sondern in die Bedienungs-Ebene. Wichtiger ist die strategische Sicht: Cache ist Dein Verbündeter für Tempo, nicht Dein Reparatur-Werkzeug für jedes Anzeige-Problem.