Web Storage API

Konzepte und Nutzung

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 Schlieen des Browser-Tabs lscht alle mit diesem Tab verknpften 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 geffnet wird.

Diese Mechanismen sind ber die Eigenschaften Window.sessionStorage und Window.localStorage verfgbar. Der Zugriff auf eine dieser Eigenschaften gibt eine Instanz eines Storage-Objekts zurck, ber das Daten gesetzt, abgerufen und entfernt werden knnen. Fr jede Origin wird ein anderes Speicherobjekt fr sessionStorage und localStorage verwendet sie funktionieren und werden separat gesteuert.

Um mehr ber die verfgbare 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 ausgefhrt werden, was die Ausfhrung anderer JavaScript-Codes blockiert, bis die Operation abgeschlossen ist. Dieses synchrone Verhalten kann potenziell die Leistung der Webanwendung beeintrchtigen, insbesondere wenn eine groe Menge an Daten gespeichert oder abgerufen wird.

Entwickler sollten vorsichtig sein, wenn sie Operationen auf sessionStorage oder localStorage ausfhren, die eine betrchtliche Menge an Daten oder rechnerisch intensive Aufgaben betreffen. Es ist wichtig, den Code zu optimieren und synchrone Operationen zu minimieren, um eine Blockierung der Benutzeroberflche und Verzgerungen in der Reaktionsfhigkeit der Anwendung zu vermeiden.

Asynchrone Alternativen wie IndexedDB knnen besser geeignet sein fr Szenarien, bei denen die Leistung eine Rolle spielt oder wenn mit greren Datenmengen gearbeitet wird. Diese Alternativen ermglichen nicht-blockierende Operationen, wodurch reibungslosere Benutzererfahrungen und eine bessere Leistung in Webanwendungen erreicht werden.

Bestimmen des Speicherzugriffs durch Drittanbieter

Jede Origin hat ihren eigenen Speicher dies gilt sowohl fr Web Storage als auch fr Shared Storage. Der Zugriff von Drittanbieter- (d.h. eingebettetem) Code auf Shared Storage hngt von seinem Browsing-Kontext ab. Der Kontext, in dem ein Drittanbieter-Code einer anderen Origin luft, bestimmt den Speicherzugriff des Drittanbieter-Codes.

[Ein Box-Diagramm, das einen Top-Level-Browsing-Kontext namens publisher.com zeigt, mit Drittanbieter-Inhalten, die darin eingebettet sind]

Drittanbieter-Code kann einer anderen Seite hinzugefgt werden, indem er mit einem <script>-Element eingefgt wird oder indem die Quelle eines <iframe> auf eine Seite gesetzt wird, die Drittanbieter-Code enthlt. Die Methode, die zur Integration von Drittanbieter-Code verwendet wird, bestimmt den Browsing-Kontext des Codes.

• Wenn Ihr Drittanbieter-Code mit einem <script>-Element zu einer anderen Seite hinzugefgt wird, wird Ihr Code im Browsing-Kontext des Embedders ausgefhrt. Daher wird beim Aufruf von Storage.setItem() oder SharedStorage.set() das Schlssel/Wert-Paar in den Speicher des Embedders geschrieben. Aus Sicht des Browsers gibt es keinen Unterschied zwischen erstem und Drittanbieter-Code, wenn ein <script>-Tag verwendet wird.
• Wenn Ihr Drittanbieter-Code innerhalb eines <iframe> zu einer anderen Seite hinzugefgt wird, wird der Code innerhalb des <iframe> mit der Origin des Browsing-Kontexts des <iframe> ausgefhrt. Wenn der Code innerhalb des <iframe> Storage.setItem() aufruft, werden Daten in den lokalen oder Session-Speicher der Origin des <iframe> geschrieben. Wenn der <iframe>-Code SharedStorage.set() aufruft, werden die Daten in den Shared Storage der Origin des <iframe> geschrieben.

Web Storage-Schnittstellen

Storage

Ermglicht es Ihnen, Daten fr eine bestimmte Domain und einen bestimmten Speicherart (Session oder lokal) zu setzen, abzurufen und zu entfernen.

Window

Die Web Storage API erweitert das Window-Objekt um zwei neue Eigenschaften Window.sessionStorage und Window.localStorage die Zugriff auf die Session und lokalen Storage-Objekte der aktuellen Domain bieten, sowie einen storage-Ereignis-Handler, der ausgelst wird, wenn sich ein Speicherbereich ndert (z. B. wenn ein neuer Artikel gespeichert wird).

StorageEvent

Das storage-Ereignis wird auf einem Dokument-Window-Objekt ausgelst, wenn sich ein Speicherbereich ndert.

Beispiele

Um einige typische Verwendungen von Web Storage zu veranschaulichen, haben wir ein Beispiel erstellt, das fantasievoll Web Storage Demo genannt wird. Die Landing Page bietet Steuerelemente, mit denen Sie die Farbe, Schriftart und das dekorative Bild anpassen knnen. Wenn Sie verschiedene Optionen whlen, wird die Seite sofort aktualisiert; zustzlich werden Ihre Auswahlmglichkeiten in localStorage gespeichert, sodass sie bei erneutem Laden der Seite nach Verlassen wiedererkannt werden.

Zudem haben wir eine Ereignisausgabeseite bereitgestellt. Wenn Sie diese Seite in einem anderen Tab laden und dann Ihre Auswahl auf der Landing Page ndern, sehen Sie die aktualisierten Speicherinformationen als StorageEvent ausgelst wird.

Spezifikationen

Spezifikation
HTML # dom-localstorage-dev
HTML # dom-sessionstorage-dev

Browser-Kompatibilitt

api.Window.localStorage

api.Window.sessionStorage

Privates Surfen / Inkognito-Modi

Private Fenster, Inkognito-Modus und hnlich benannte Datenschutzoptionen speichern keine Daten wie Verlauf und Cookies. Im privaten Modus wird localStorage wie sessionStorage behandelt. Die Speicher-APIs sind immer noch verfgbar und voll funktionsfhig, aber alle im privaten Fenster gespeicherten Daten werden gelscht, wenn der Browser oder der Browsertab geschlossen wird.

Siehe auch

• Using the Web Storage API
• Browser storage quotas and eviction criteria