Double-keyed Caching verstehen: Warum Cache nicht über Sites hinweg geteilt wird

Hast du dich jemals gefragt: „Warum bleiben statische Ressourcen auf einer Website zwischengespeichert, müssen aber erneut heruntergeladen werden, wenn von einer anderen Website darauf zugegriffen wird?“

Dies wird grundsätzlich durch Double-keyed Caching verursacht.

Lass uns heute also eintauchen, was Double-keyed Caching ist, wie es funktioniert und wie wir es optimieren können.

Was ist Double-keyed Caching?

Beim traditionellen Browser-Caching werden Ressourcen typischerweise basierend auf ihrer URL gespeichert.

Wenn du beispielsweise https://cdn.example.com/script.js besuchst, speichert der Browser diese script.js-Datei im Cache. Wenn eine andere Website auf dieselbe URL verweist, verwendet der Browser direkt die zwischengespeicherte Version, ohne sie erneut herunterladen zu müssen.

Diese traditionelle Caching-Methode funktioniert wie erwartet: Sobald eine Ressource zwischengespeichert ist, kann jede Site darauf zugreifen.

Dieser Ansatz birgt jedoch ein erhebliches Sicherheitsrisiko – Cross-Site-Tracking und Datenlecks.

Zum Beispiel:

Einige Websites können den Cache-Status öffentlicher CDN-Ressourcen überprüfen, um abzuleiten, ob ein Benutzer bestimmte Websites besucht hat (z. B. für Ad-Tracking).
Hacker können Cache-Poisoning-Angriffe ausnutzen, um Benutzern kompromittierte Ressourcen bereitzustellen.

Um diese Sicherheitsrisiken zu mindern, haben viele Browser (z. B. Chrome und Firefox) Double-keyed Caching eingeführt.

Die Kernregel des Double-keyed Caching lautet: Beim Zwischenspeichern einer Ressource sollte nicht nur die URL, sondern auch die Site (Origin) berücksichtigt werden, von der sie geladen wird. Das bedeutet, dass das Caching nun auf „Site + URL“ als eindeutiger Kennung basiert.

Mit anderen Worten:

Zuvor konnte eine von Site A zwischengespeicherte Ressource von Site B wiederverwendet werden ✅
Jetzt muss eine von Site A zwischengespeicherte Ressource von Site B erneut heruntergeladen werden ❌

Wie funktioniert Double-keyed Caching?

Double-keyed Caching = Origin + Ressourcen-URL

Verwenden wir ein Beispiel zur Veranschaulichung:

Angenommen, du besuchst Seite A und Seite B, die beide dieselbe CDN-Ressource verwenden: https://cdn.example.com/script.js.

Traditionelles Caching (Single-keyed Caching)

Du lädst script.js auf Seite A, und der Browser speichert die Datei im Cache.
Wenn du Seite B besuchst, stellt der Browser fest, dass dieselbe script.js angefordert wird, und lädt sie direkt aus dem Cache (wodurch Netzwerkanfragen reduziert und die Ladegeschwindigkeit verbessert wird).

Double-keyed Caching

Du lädst script.js auf Seite A, und der Browser speichert sie nur für Seite A im Cache.
Wenn du Seite B besuchst, behandelt der Browser sie, obwohl dieselbe script.js angefordert wird, als völlig neue Ressource und erfordert einen erneuten Download.

Verschiedene Sites müssen, auch wenn sie dieselbe Ressource anfordern, diese separat zwischenspeichern!

Dies erhöht die Sicherheit, verursacht aber auch die Verwirrung, die wir zu Beginn erwähnt haben: Ressourcen können nicht zwischen Sites geteilt werden und müssen mehrmals heruntergeladen werden.

Nachteile des Double-keyed Caching

Während Double-keyed Caching die Sicherheit verbessert, führt es auch zu mehreren Problemen:

Geringere Cache-Wiederverwendungsrate: Selbst bei identischen Ressourcen müssen verschiedene Sites diese erneut herunterladen.
Reduzierte Effektivität öffentlicher CDNs: Traditionell haben CDNs (wie jsDelivr und UNPKG) mehreren Sites geholfen, zwischengespeicherte Ressourcen zu teilen. Jetzt ist dieser Vorteil stark reduziert.
Höhere Kosten für den erstmaligen Zugriff: Wenn ein Benutzer eine Site besucht, muss er, selbst wenn er eine zwischengespeicherte Kopie derselben Ressource von einer anderen Site hat, diese erneut herunterladen, was das anfängliche Laden der Seite verlangsamt.

Wie kann man die Auswirkungen von Double-keyed Caching optimieren?

Nachdem wir nun verstanden haben, wie Double-keyed Caching funktioniert und welche potenziellen Nachteile es hat, wollen wir Möglichkeiten zur Optimierung seiner Auswirkungen untersuchen.

Verwende Service Worker

Service Worker können Anfragen auf der Clientseite abfangen und den lokalen Cache nutzen, um die Abhängigkeit von Netzwerkanfragen zu reduzieren.

Beispielsweise können wir die Cache API verwenden, um bestimmte Ressourcen manuell zu speichern und die Einschränkungen des Double-keyed Caching zu umgehen:

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((response) => {
      return response || fetch(event.request);
    })
  );
});

Da das Service Worker-Caching nicht von Double-keyed Caching betroffen ist, kannst du es verwenden, um häufig verwendete statische Ressourcen zu verwalten, anstatt dich vollständig auf HTTP-Caching zu verlassen.

Verwende HTTP/3, um redundante Anfragen zu reduzieren

Aufgrund des Double-keyed Caching müssen selbst wenn derselbe Benutzer verschiedene Websites besucht, gängige CDN-Ressourcen möglicherweise mehrmals heruntergeladen werden.

Wenn wir jedoch HTTP/3 (QUIC) verwenden, das Multiplexing und 0-RTT-Verbindungen unterstützt, können wir die Leistung optimieren.

Wie überprüfe ich, ob dein CDN HTTP/3 unterstützt? Öffne Chrome DevTools, gehe zum Panel Network und überprüfe die Spalte Protocol. Wenn dort h3 angezeigt wird, bedeutet das, dass die Ressource HTTP/3 verwendet.

Lade kritische Ressourcen vorab

Da wir uns nicht vollständig auf das Browser-Caching verlassen können, können wir kritische Ressourcen proaktiv vorab laden.

Verwende beispielsweise <link rel="preload">, um Schriftarten, Skripte oder CSS vorab zu laden:

<link
  rel="preload"
  href="https://your-cdn.com/fonts/Roboto.woff2"
  as="font"
  type="font/woff2"
  crossorigin="anonymous"
/>

Dies stellt sicher, dass selbst wenn Ressourcen aufgrund von Double-keyed Caching erneut heruntergeladen werden müssen, sie schneller geladen werden.

Durch die Anwendung dieser Strategien können wir die Auswirkungen des Double-keyed Caching reduzieren und gleichzeitig Sicherheit und Leistung aufrechterhalten.

Wir sind Leapcell, deine erste Wahl für das Hosten von Backend-Projekten.

Leapcell ist die Serverless-Plattform der nächsten Generation für Webhosting, asynchrone Aufgaben und Redis:

Multi-Sprachen-Unterstützung

Entwickle mit Node.js, Python, Go oder Rust.

Unbegrenzt Projekte kostenlos bereitstellen

zahle nur für die Nutzung – keine Anfragen, keine Gebühren.

Unschlagbare Kosteneffizienz

Pay-as-you-go ohne Leerlaufgebühren.
Beispiel: 25 $ unterstützen 6,94 Millionen Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

Optimierte Entwicklererfahrung

Intuitive Benutzeroberfläche für mühelose Einrichtung.
Vollständig automatisierte CI/CD-Pipelines und GitOps-Integration.
Echtzeitmetriken und -protokollierung für umsetzbare Erkenntnisse.

Mühelose Skalierbarkeit und hohe Leistung

Automatische Skalierung zur einfachen Bewältigung hoher Parallelität.
Kein Betriebsaufwand – konzentriere dich einfach auf das Bauen.

Erfahre mehr in der Dokumentation!

Folge uns auf X: @LeapcellHQ