Web Storage API

Die zwei Mechanismen innerhalb des Web Storage sind wie folgt:

• sessionStorage hält einen separaten Speicherbereich für jeden gegebenen Origin bereit, der für die Dauer der Sitzung der Seite verfügbar ist (solange der Browser-Tab geöffnet bleibt, einschließlich Seitenreloads und -wiederherstellungen).

• localStorage erfüllt die gleiche Funktion, bleibt aber auch bestehen, wenn der Browser geschlossen und erneut geöffnet wird.

Diese Mechanismen sind über die Window.sessionStorage und Window.localStorage Eigenschaften verfügbar. Der Aufruf einer dieser Eigenschaften gibt eine Instanz eines Storage-Objekts zurück, über das Datenobjekte gesetzt, abgerufen und entfernt werden können. Ein unterschiedliches Speicherobjekt wird für sessionStorage und localStorage für jeden Origin verwendet — sie funktionieren und werden separat gesteuert.

Um mehr über die verfügbare Speichermenge mithilfe der APIs zu lernen und was passiert, wenn Speicherlimits überschritten werden, siehe Storage-Quoten und Löschkriterien.

Sowohl sessionStorage als auch localStorage im Web Storage sind synchroner Natur. Dies bedeutet, dass, wenn Daten in diesen Speichermechanismen gesetzt, abgerufen oder entfernt werden, die Operationen synchron durchgeführt werden und die Ausführung anderer JavaScript-Codes blockieren, bis die Operation abgeschlossen ist. Dieses synchrone Verhalten kann potenziell die Leistung der Web-Anwendung beeinträchtigen, insbesondere wenn eine große Datenmenge gespeichert oder abgerufen wird.

Entwickler sollten vorsichtig sein, wenn sie Operationen mit sessionStorage oder localStorage durchführen, die eine erhebliche Datenmenge oder rechenintensive Aufgaben beinhalten. Es ist wichtig, den Code zu optimieren und synchrone Operationen zu minimieren, um die Benutzeroberfläche nicht zu blockieren und Verzögerungen in der Reaktionsfähigkeit der Anwendung zu verhindern.

Asynchrone Alternativen, wie beispielsweise IndexedDB, könnten geeigneter für Szenarien sein, in denen Leistung von Bedeutung ist oder wenn mit größeren Datensätzen gearbeitet wird. Diese Alternativen ermöglichen nicht-blockierende Operationen, die flüssigere Benutzererfahrungen und bessere Leistung in Webanwendungen bieten.

Jeder Origin hat seinen eigenen Speicher — dies gilt sowohl für Web Storage als auch für Shared Storage. Der Zugriff von Third-Party- (also eingebettetem) Code auf geteilten Speicher hängt von seinem Browsing-Kontext ab. Der Kontext, in dem ein Third-Party-Code eines anderen Origins ausgeführt wird, bestimmt den Speicherzugriff des Third-Party-Codes.

Third-Party-Code kann einer anderen Website hinzugefügt werden, indem er mit einem <script>-Element injiziert wird, oder indem die Quelle eines <iframe> auf eine Website eingestellt wird, die Third-Party-Code enthält. Die Methode, die zur Integration von Third-Party-Code verwendet wird, bestimmt den Browsing-Kontext des Codes.

• Wenn Ihr Third-Party-Code mit einem <script>-Element zu einer anderen Seite hinzugefügt wird, wird Ihr Code im Browsing-Kontext des Einbettenden ausgeführt. Daher wird, wenn Sie Storage.setItem() oder SharedStorage.set() aufrufen, das Schlüssel/Wert-Paar im Speicher des Einbettenden geschrieben. Aus der Sicht des Browsers gibt es keinen Unterschied zwischen First-Party-Code und Third-Party-Code, wenn ein <script>-Tag verwendet wird.
• Wenn Ihr Third-Party-Code innerhalb eines <iframe> zu einer anderen Seite hinzugefügt wird, wird der Code innerhalb des <iframe> mit dem Origin des Browsing-Kontexts des <iframe> ausgeführt. Ruft der Code innerhalb des <iframe> Storage.setItem() auf, werden die Daten in den lokalen oder Session Storage des Origins des <iframe> geschrieben. Wenn der <iframe>-Code SharedStorage.set() aufruft, werden die Daten in den Shared Storage des Origins des <iframe> geschrieben.

Storage

Ermöglicht es Ihnen, Daten für eine bestimmte Domain und einen bestimmten Speichertyp (Session oder Lokal) zu setzen, abzurufen und zu entfernen.

Window

Die Web Storage API erweitert das Window-Objekt mit zwei neuen Eigenschaften — Window.sessionStorage und Window.localStorage — die Zugriff auf die Session- und lokalen Storage-Objekte der aktuellen Domain bieten und einen storage-Ereignis-Handler, der ausgelöst wird, wenn sich ein Speicherbereich ändert (z.B. wenn ein neuer Eintrag gespeichert wird).

StorageEvent

Das storage-Ereignis wird auf dem Window-Objekt eines Dokuments ausgelöst, wenn sich ein Speicherbereich ändert.

Um einige typische Anwendungsfälle von Web Storage zu veranschaulichen, haben wir ein einfaches Beispiel erstellt, das kreativ Web Storage Demo genannt wird. Die Startseite bietet Steuerungen, mit denen die Farbe, die Schriftart und das dekorative Bild angepasst werden können. Wenn Sie verschiedene Optionen wählen, wird die Seite sofort aktualisiert; zusätzlich werden Ihre Entscheidungen in localStorage gespeichert, sodass Ihre Entscheidungen gespeichert werden, wenn Sie die Seite verlassen und später erneut laden.

Des Weiteren haben wir eine Ereignisausgabeseite bereitgestellt — wenn Sie diese Seite in einem anderen Tab laden und dann Änderungen an Ihren Entscheidungen auf der Startseite vornehmen, wird die aktualisierte Speichernformation ausgegeben, sobald das StorageEvent ausgelöst wird.

Private Fenster, der Inkognito-Modus und ähnlich benannte Datenschutzoptionen speichern keine Daten wie Verlauf und Cookies. Im privaten Modus wird localStorage wie sessionStorage behandelt. Die Storage-APIs sind weiterhin verfügbar und vollständig funktional, aber alle im privaten Fenster gespeicherten Daten werden gelöscht, wenn der Browser oder der Browser-Tab geschlossen wird.

• Verwendung der Web Storage API
• Browser-Speicherquoten und Löschkriterien