Browser-Speicher im Vergleich: Cookies, Web Storage und IndexedDB

Worum es geht

Cookies sind Name-Wert-Paare, die vom Server (Set-Cookie) oder per Skript gesetzt und mit jeder passenden Anfrage zurückgeschickt werden. RFC 6265 verlangt von User Agents, mindestens 4096 Bytes je Cookie, 50 Cookies je Domain und 3000 insgesamt zu unterstützen, und erlaubt ihnen, Cookies jenseits solcher Grenzen zu verdrängen. Web Storage (HTML-Standard) bietet localStorage, das je Origin dauerhaft bestehen bleibt, sowie sessionStorage, das auf ein einziges Top-Level-Traversable (einen Tab oder ein Fenster) beschränkt ist und mit diesem endet; beide sind synchron und speichern nur Strings. Die Seite zu den Kontingenten auf MDN hält fest, dass Web Storage insgesamt auf 10 MiB begrenzt ist, davon 5 MiB Local Storage und 5 MiB Session Storage je Origin, und dass eine Überschreitung QuotaExceededError auslöst. IndexedDB ist asynchron und transaktional, speichert strukturierte Werte und Blobs mit Indizes und schöpft aus dem allgemeinen Kontingent der Origin, das in Chromium-basierten Browsern bis zu 60 % der Festplatte erreichen kann. Speicher ist standardmässig Best-Effort und kann unter Druck verdrängt werden; navigator.storage.persist() fordert Persistenz an, navigator.storage.estimate() meldet Nutzung und Kontingent, und privates Browsing verwirft Daten in der Regel beim Ende der Sitzung.

Warum es wichtig ist

Die falsche Wahl schafft Sicherheits- oder Zuverlässigkeitsprobleme: Ein Session-Token in localStorage ist für jedes eingeschleuste Skript lesbar, grosser Zustand in Cookies bläht jede Anfrage auf, ein grosser synchroner localStorage-Schreibvorgang blockiert den Main Thread, und eine Anwendung, die annimmt, Best-Effort-Daten seien immer da, scheitert nach einer Verdrängung still.

So wird es angewendet

• Daten, die der Server bei jeder Anfrage braucht (Session-Kennung): ein kleines Cookie mit HttpOnly, Secure und einem Pfad-Geltungsbereich; sonst nichts in Cookies.
• Kleine, rein clientseitige Einstellungen: localStorage, jeder Zugriff in try/catch eingepackt, da er bei vollem oder blockiertem Speicher werfen kann.
• Flüchtiger Zustand je Tab (Fortschritt eines Assistenten, Entwurfsfilter): sessionStorage.
• Datensätze, Dateien, Offline-Caches: IndexedDB, hinter einem kleinen Wrapper, damit der übrige Code nur Promises sieht.
• Die gespeicherte Form versionieren (settings:v2) und bei Abweichung migrieren oder verwerfen.
• Bevor man sich für kritische Daten auf den Speicher verlässt, persist() aufrufen und eine Ablehnung als «kann verschwinden» behandeln.

Stolpersteine

Speicher ist nach Origin abgegrenzt: app.example.com und example.com teilen sich kein localStorage, während ein Cookie mit Domain=example.com an beide gesendet wird, und Cookies isolieren nicht nach Port. Browser können den Speicher für eine in Third-Party-Frames eingebettete Site zusätzlich partitionieren. JSON.stringify verwirft undefined und macht aus Date Strings; bewusst deserialisieren.