Grundlagen des Cachings, die jeder Webentwickler kennen sollte

Feb 24, 2026 · 4 min read

Grundlagen des Cachings, die jeder Webentwickler kennen sollte

Ihre Benutzer haben gerade auf eine Schaltfläche geklickt, und drei Sekunden lang passiert nichts. Die Datenbankabfrage wurde abgeschlossen, der Server hat geantwortet, aber dieselben Daten, die gestern geladen wurden, mussten erneut über das gesamte Internet übertragen werden. Dies ist das Problem, das Caching löst.

Das Verständnis der HTTP-Caching-Grundlagen ist für Frontend-Entwickler nicht optional. Es ist der Unterschied zwischen einer flüssigen Anwendung und einer, die sich defekt anfühlt. Dieser Leitfaden behandelt, was Sie über Browser-Cache vs. CDN-Cache, Cache-Control-Header und Validierungsmechanismen wie ETag und Last-Modified wissen müssen.

Wichtigste Erkenntnisse

Setzen Sie explizite Cache-Control-Header bei jeder Response, um unvorhersehbare Browser-Heuristiken zu vermeiden.
Verwenden Sie lange max-age-Werte in Kombination mit Cache Busting (inhaltshashbasierte Dateinamen) für statische Assets.
Verwenden Sie no-cache mit ETag oder Last-Modified für Inhalte, die aktuell bleiben müssen.
Markieren Sie personalisierte oder authentifizierte Inhalte immer als private, um Datenlecks durch gemeinsam genutzte Caches zu verhindern.

Was ist Caching und warum ist es wichtig?

Caching speichert eine Kopie von Daten näher an dem Ort, wo sie benötigt werden. Wenn Ihr Browser ein Bild anfordert, kann er dieses Bild lokal speichern. Die nächste Anfrage umgeht das Netzwerk vollständig.

Die Leistungsgewinne sind dramatisch. Beispielsweise kann eine Datenbankabfrage mehrere zehn Millisekunden dauern, während das Lesen aus einem Browser-Cache in der Regel nahezu sofort erfolgt und einen Netzwerk-Roundtrip vollständig vermeidet.

Caching bietet drei zentrale Vorteile:

Reduzierte Latenz: Daten legen kürzere Strecken zurück.
Geringere Serverlast: Weniger Anfragen erreichen Ihren Origin-Server.
Bessere Benutzererfahrung: Seiten laden bei wiederholten Besuchen schneller.

Verständnis der Cache-Ebenen

Anfragen durchlaufen mehrere Caches, bevor sie Ihren Server erreichen. Jede Ebene dient einem anderen Zweck.

Browser-Cache (privater Cache)

Der Browser-Cache befindet sich auf dem Gerät des Benutzers. Er speichert Responses, die nur dieser Benutzer sehen sollte. Wenn Sie eine Response als private markieren, bleibt sie hier und wird niemals mit anderen Benutzern geteilt.

Hier gehören personalisierte Inhalte hin – Benutzerprofile, authentifizierte API-Responses, alles, was an eine bestimmte Sitzung gebunden ist.

CDN-Cache (gemeinsam genutzter Cache)

Ein CDN-Cache sitzt zwischen Benutzern und Ihrem Origin-Server und ist über geografische Standorte verteilt. Wenn ein Benutzer in Tokio Ihr JavaScript-Bundle anfordert, liefert das CDN es von einem nahegelegenen Edge-Server anstatt von Ihrem Origin-Rechenzentrum.

CDNs eignen sich hervorragend zum Caching statischer Assets: Bilder, CSS, JavaScript und Schriftarten. Sie können auch öffentliche API-Responses cachen, obwohl dies eine sorgfältige Konfiguration erfordert.

Serverseitiges Caching

Über HTTP-Caching hinaus unterhalten Server oft ihre eigenen Caches mit Tools wie Redis oder Memcached. Als Frontend-Entwickler werden Sie diese nicht direkt konfigurieren, aber das Verständnis ihrer Existenz hilft Ihnen zu verstehen, warum manche API-Responses schneller sind als andere.

Cache-Control-Header: Die wichtigsten Direktiven

Der Cache-Control-Header teilt Caches mit, wie sie mit Responses umgehen sollen. Dies sind die Direktiven, die Sie am häufigsten verwenden werden:

Direktive	Bedeutung
`max-age=3600`	Für 3600 Sekunden (1 Stunde) cachen
`no-cache`	Speichern, aber vor Verwendung revalidieren
`no-store`	Diese Response nirgendwo speichern
`private`	Nur der Browser-Cache darf dies speichern
`public`	Jeder Cache kann dies speichern

Ein häufiger Fehler: no-cache bedeutet nicht „nicht cachen”. Es bedeutet „immer beim Server prüfen, bevor die gecachte Kopie verwendet wird”. Verwenden Sie no-store, wenn Sie wirklich überhaupt kein Caching möchten.

Für statische Assets mit gehashten Dateinamen verwenden Sie aggressives Caching:

Cache-Control: public, max-age=31536000

Für HTML-Seiten, die sich häufig ändern (und insbesondere für sensible oder hochdynamische Inhalte):

Cache-Control: no-cache, private

ETag und Last-Modified: Validierungsmechanismen

Wenn gecachte Inhalte ablaufen, müssen Browser nicht immer alles erneut herunterladen. Validierungs-Header ermöglichen eine effiziente Revalidierung.

Last-Modified enthält einen Zeitstempel. Bei nachfolgenden Anfragen sendet der Browser einen If-Modified-Since-Header mit diesem Zeitstempel. Wenn sich nichts geändert hat, gibt der Server 304 Not Modified zurück – kein Body, minimale Bandbreite.

ETag enthält einen eindeutigen Identifikator (oft ein Content-Hash). Bei nachfolgenden Anfragen sendet der Browser einen If-None-Match-Header mit diesem Identifikator. Gleiches Ergebnis: ein 304, wenn der Inhalt unverändert ist.

ETags sind präziser als Zeitstempel, weil sie tatsächliche Inhaltsänderungen erkennen, nicht nur Dateiänderungszeiten. Eine Datei könnte erneut gespeichert werden, ohne ihren Inhalt zu ändern, wodurch ihr Zeitstempel aktualisiert wird, aber nicht ihr ETag.

Cache Busting für statische Assets

Sie möchten, dass statische Assets so lange wie möglich gecacht werden, aber Sie müssen auch sicherstellen, dass Benutzer Updates erhalten, wenn Sie deployen. Cache Busting löst dies, indem die URL geändert wird, wenn sich der Inhalt ändert.

Moderne Build-Tools hängen Content-Hashes an Dateinamen an:

bundle.a1b2c3d4.js
styles.e5f6g7h8.css

Wenn Sie neuen Code deployen, ändert sich der Hash, die URL ändert sich, und Browser laden die neue Version. Die alten gecachten Dateien laufen einfach natürlich ab.

Häufige Fallstricke, die es zu vermeiden gilt

Öffentliches Caching authentifizierter Inhalte: Verwenden Sie immer private für benutzerspezifische Daten. Das Durchsickern der Daten eines Benutzers an einen anderen durch einen gemeinsam genutzten Cache ist ein ernsthaftes Sicherheitsproblem.

Übermäßiges Caching von API-Responses: Dynamische Daten benötigen kurze TTLs oder no-cache. Veraltete Preise während des Checkouts verursachen echte Probleme.

Vergessen, Header zu setzen: Ohne explizite Cache-Control-Header können Browser heuristisches Caching basierend auf Response-Metadaten anwenden, was zu Verhalten führen kann, das Sie nicht beabsichtigt haben.

Fazit

Caching ist nichts, was Sie einmal konfigurieren und dann vergessen. Setzen Sie explizite Cache-Control-Header bei jeder Response. Kombinieren Sie lange max-age-Werte mit inhaltshashbasierten Dateinamen für statische Assets. Verwenden Sie no-cache zusammen mit ETag oder Last-Modified für Inhalte, die aktuell bleiben müssen, und markieren Sie personalisierte Inhalte immer als private. Überprüfen Sie Ihre Header in den DevTools, verifizieren Sie das Verhalten Ihres CDN und testen Sie, was Benutzer tatsächlich erleben.

Häufig gestellte Fragen (FAQs)

no-cache teilt dem Browser mit, dass er die Response speichern kann, aber vor der Verwendung mit dem Server revalidieren muss. no-store teilt dem Browser mit, die Response überhaupt nicht zu speichern. Verwenden Sie no-store für sensible Daten wie Bankdaten und no-cache für Inhalte, die sich häufig ändern, aber von bedingter Revalidierung profitieren.

Öffnen Sie die Browser-DevTools, gehen Sie zum Network-Tab und wählen Sie eine beliebige Anfrage aus. Der Abschnitt Response Headers zeigt Cache-Control-, ETag- und Last-Modified-Werte. Schauen Sie sich auch die Größenspalte an. Wenn dort disk cache oder memory cache steht, wurde die Response aus dem Browser-Cache statt aus dem Netzwerk bereitgestellt.

Es hängt von den Daten ab. Öffentliche, sich selten ändernde Daten wie Produktkategorien können kurze max-age-Werte verwenden. Benutzerspezifische oder sich häufig ändernde Daten sollten no-cache mit Validierungs-Headern oder no-store verwenden. Markieren Sie authentifizierte Responses immer als private, um zu verhindern, dass CDNs die Daten eines Benutzers an einen anderen ausliefern.

Content-Hashes ermöglichen es Ihnen, sehr lange Cache-Laufzeiten für statische Assets festzulegen und gleichzeitig Updates sofort bereitzustellen. Wenn sich der Dateiinhalt ändert, ändert sich der Hash und erzeugt eine neue URL, die jeden vorhandenen Cache umgeht. Diese Technik wird Cache Busting genannt und ist der Standardansatz, der von Tools wie Webpack, Vite und Rollup verwendet wird.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.