Dieser Inhalt wurde automatisch aus dem Englischen übersetzt, und kann Fehler enthalten.Erfahre mehr über dieses Experiment.
Web Storage API
DieWeb Storage API bietet Mechanismen, mit denen Browser Schlüssel/Wert-Paare speichern können, auf eine viel intuitivere Weise als mitCookies.
In diesem Artikel
Konzepte und Nutzung
Die beiden Mechanismen innerhalb von Web Storage sind wie folgt:
sessionStorageist nach Browser-Tabs und nachOrigin partitioniert. Das Hauptdokument und alle eingebettetenBrowsing-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üpftensessionStorage-Daten.localStorageist nur nachOrigin partitioniert. Alle Dokumente mit derselben Origin haben Zugriff auf denselbenlocalStorage-Bereich, der auch dann bestehen bleibt, wenn der Browser geschlossen und erneut geöffnet wird.
Diese Mechanismen sind über die EigenschaftenWindow.sessionStorage undWindow.localStorage verfügbar. Der Zugriff auf eine dieser Eigenschaften gibt eine Instanz einesStorage-Objekts zurück, über das Daten gesetzt, abgerufen und entfernt werden können. Für jede Origin wird ein anderes Speicherobjekt fürsessionStorage undlocalStorage 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, sieheSpeicherquoten und Ausweisungskriterien.
SowohlsessionStorage als auchlocalStorage 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 aufsessionStorage oderlocalStorage 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 wieIndexedDB 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.
Hinweis:Der Zugriff auf Web Storage von Drittanbieter-IFrames wird verweigert, wenn der BenutzerDrittanbieter-Cookies deaktiviert hat.
Bestimmen des Speicherzugriffs durch Drittanbieter
Jede Origin hat ihren eigenen Speicher — dies gilt sowohl für Web Storage als auch fürShared Storage. Der Zugriff von Drittanbieter- (d.h. eingebettetem) Code auf Shared Storage hängt von seinemBrowsing-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<script>-Element eingefügt wird oder indem die Quelle eines<iframe> auf eine Seite gesetzt wird, die Drittanbieter-Code enthält. 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 hinzugefügt wird, wird Ihr Code im Browsing-Kontext des Embedders ausgeführt. Daher wird beim Aufruf vonStorage.setItem()oderSharedStorage.set()das Schlüssel/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 hinzugefügt wird, wird der Code innerhalb des<iframe>mit der Origin des Browsing-Kontexts des<iframe>ausgeführt. 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>-CodeSharedStorage.set()aufruft, werden die Daten in den Shared Storage der Origin des<iframe>geschrieben.
Web Storage-Schnittstellen
StorageErmöglicht es Ihnen, Daten für eine bestimmte Domain und einen bestimmten Speicherart (Session oder lokal) zu setzen, abzurufen und zu entfernen.
WindowDie Web Storage API erweitert das
Window-Objekt um zwei neue Eigenschaften —Window.sessionStorageundWindow.localStorage— die Zugriff auf die Session und lokalenStorage-Objekte der aktuellen Domain bieten, sowie einenstorage-Ereignis-Handler, der ausgelöst wird, wenn sich ein Speicherbereich ändert (z. B. wenn ein neuer Artikel gespeichert wird).StorageEventDas
storage-Ereignis wird auf einem Dokument-Window-Objekt ausgelöst, wenn sich ein Speicherbereich ändert.
Beispiele
Um einige typische Verwendungen von Web Storage zu veranschaulichen, haben wir ein Beispiel erstellt, das fantasievollWeb Storage Demo genannt wird. DieLanding Page bietet Steuerelemente, mit denen Sie die Farbe, Schriftart und das dekorative Bild anpassen können. Wenn Sie verschiedene Optionen wählen, wird die Seite sofort aktualisiert; zusätzlich werden Ihre Auswahlmöglichkeiten inlocalStorage gespeichert, sodass sie bei erneutem Laden der Seite nach Verlassen wiedererkannt werden.
Zudem haben wir eineEreignisausgabeseite bereitgestellt. Wenn Sie diese Seite in einem anderen Tab laden und dann Ihre Auswahl auf der Landing Page ändern, sehen Sie die aktualisierten Speicherinformationen alsStorageEvent ausgelöst wird.
Spezifikationen
| Specification |
|---|
| HTML> # dom-localstorage-dev> |
| HTML> # dom-sessionstorage-dev> |
Browser-Kompatibilität
>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 wirdlocalStorage wiesessionStorage behandelt. Die Speicher-APIs sind immer noch verfügbar und voll funktionsfähig, aber alle im privaten Fenster gespeicherten Daten werden gelöscht, wenn der Browser oder der Browsertab geschlossen wird.