Web Storage API

Die beiden Mechanismen innerhalb von Web Storage sind wie folgt:

• sessionStorage ist nach Browser-Tabs und nach Origin partitioniert. Das Hauptdokument und alle eingebetteten Browsing-Kontexte (iframes) werden nach ihrer Origin gruppiert, und jede Origin hat Zugriff auf ihren eigenen separaten Speicherbereich. Das Schließen des Browser-Tabs löscht alle mit diesem Tab verknüpften sessionStorage-Daten.
• localStorage ist nur nach Origin partitioniert. Alle Dokumente mit derselben Origin haben Zugriff auf denselben localStorage-Bereich, der auch dann bestehen bleibt, wenn der Browser geschlossen und erneut geöffnet wird.

Diese Mechanismen sind über die Eigenschaften Window.sessionStorage und Window.localStorage verfügbar. Der Zugriff auf eine dieser Eigenschaften gibt eine Instanz eines Storage-Objekts zurück, über das Daten gesetzt, abgerufen und entfernt werden können. Für jede Origin wird ein anderes Speicherobjekt für sessionStorage und localStorage verwendet — sie funktionieren und werden separat gesteuert.

Um mehr über die verfügbare Speichermenge mithilfe der APIs zu erfahren und was passiert, wenn Speicherlimits überschritten werden, siehe Speicherquoten und Ausweisungskriterien.

Sowohl sessionStorage als auch localStorage in Web Storage sind von Natur aus synchron. Das bedeutet, dass beim Setzen, Abrufen oder Entfernen von Daten aus diesen Speichermethoden die Operationen synchron ausgeführt werden, was die Ausführung anderer JavaScript-Codes blockiert, bis die Operation abgeschlossen ist. Dieses synchrone Verhalten kann potenziell die Leistung der Webanwendung beeinträchtigen, insbesondere wenn eine große Menge an Daten gespeichert oder abgerufen wird.

Entwickler sollten vorsichtig sein, wenn sie Operationen auf sessionStorage oder localStorage ausführen, die eine beträchtliche Menge an Daten oder rechnerisch intensive Aufgaben betreffen. Es ist wichtig, den Code zu optimieren und synchrone Operationen zu minimieren, um eine Blockierung der Benutzeroberfläche und Verzögerungen in der Reaktionsfähigkeit der Anwendung zu vermeiden.

Asynchrone Alternativen wie IndexedDB können besser geeignet sein für Szenarien, bei denen die Leistung eine Rolle spielt oder wenn mit größeren Datenmengen gearbeitet wird. Diese Alternativen ermöglichen nicht-blockierende Operationen, wodurch reibungslosere Benutzererfahrungen und eine bessere Leistung in Webanwendungen erreicht werden.

Jede Origin hat ihren eigenen Speicher — dies gilt sowohl für Web Storage als auch für Shared Storage. Der Zugriff von Drittanbieter- (d.h. eingebettetem) Code auf Shared Storage hängt von seinem Browsing-Kontext ab. Der Kontext, in dem ein Drittanbieter-Code einer anderen Origin läuft, bestimmt den Speicherzugriff des Drittanbieter-Codes.

Drittanbieter-Code kann einer anderen Seite hinzugefügt werden, indem er mit einem