HTML5: Einführung in die Web Storage API - LocalStorage & SessionStorage

Die HTML5 Web Storage API, teilweise auch als DOM Storage bezeichnet, dient der clientseitigen Speicherung von Daten in Form von Schlüssel-Wert-Paaren. Man kann auch vereinfacht sagen, die Daten werden lokal im Webbrowser gespeichert.

Grundsätzlich ist die Web Storage API in die zwei verschiedenen Speicherarten namens LocalStorage und SessionStorage unterteilt.

In diesem Beitrag stelle ich euch nun die HTML5 Web Storage API vor.

LocalStorage vs. SessionStorage

LocalStorage dient zur dauerhaften Speicherung von langlebigen Daten. Wohingegen SessionStorage das temporäre Speichern von sitzungsbezogenen und kurzlebigen Daten ermöglicht. Infolgedessen unterscheiden sich beide Speicherarten bzgl. Gültigkeitsdauer und Gültigkeitsbereich:

LocalStorageSessionStorage
GültigkeitsdauerDaten bleiben sowohl nach Schließen des Webbrowser-Fensters bzw. Tabs als auch nach Schließen des Webbrowsers erhalten.Daten bleiben nur solange erhalten bis das Fenster bzw. der Tab des Webbrowsers, in dessen Kontext die Daten gespeichert wurden, geschlossen wird.
GültigkeitsbereichDaten sind unabhängig vom Webbrowser-Fenster bzw. Tab verfügbar.Daten sind nur in dem Webbrowser-Fenster bzw. Tab verfügbar, in dessen Kontext die Daten gespeichert wurden.

Im Zusammenhang mit dem Gültigkeitsbereich sei noch erwähnt, dass die Web Storage API der Same Origin Policy (SOP) unterliegt. Konkret bedeutet das, dass eine Webseite mit der Herkunft (Origin) http://www.abc.de:80 keinen Zugriff auf die mittels der Web Storage API gespeicherten Daten einer Webseite mit der Herkunft http://www.xyz.de:80 hat.

Die Web Storage API im Detail

Die synchrone Web Storage API setzt sich zum einen aus dem Storage- und zum anderen aus dem StorageEvent-Interface zusammen. Der eigentliche Zugriff auf den jeweiligen Speicher erfolgt über das globale localStorage bzw. sessionStorage-Objekt, die das Storage-Interface gleichermaßen implementieren.

Das Storage-Interface ist dabei wie folgt definiert:

interface Storage
{
    readonly attribute unsigned long length;
    DOMString? key(unsigned long index);
    getter DOMString getItem(DOMString key);
    setter creator void setItem(DOMString key, DOMString value);
    deleter void removeItem(DOMString key);
    void clear();
};
JavaScript

Sowohl für die Schlüssel als auch die einzelnen Werte sind nur Daten vom Typ DOMString zulässig. Wenn ihr also Arrays oder Objekte speichern wollt, müsst ihr diese erst in einen String konvertieren.

Die Spezifikation der Web Storage API gibt vor, dass Webbrowser den verfügbaren Speicher aus Sicherheitsgründen begrenzen sollen. Das Speicherlimit kann dabei je Webbrowser unterschiedlich sein.

Tipp Speicherlimit des Webbrowsers ermitteln

Zum Ermitteln, welches Speicherlimit euer Webbrowser für die Web Storage API festgelegt hat, kann euch folgendes Tool behilflich sein: Browser Storage Abuser

In der folgenden Tabelle sind die einzelnen Attribute bzw. Funktionen kurz erläutert:

Attribut / MethodeBeschreibung
lengthGibt die Anzahl der Schlüssel-Wert-Paare zurück.
key(index)Gibt den Schlüssel an der Position index zurück.
getItem(key)Gibt den Wert für den Schlüssel key zurück.
setItem(key, value) Speichert den Wert value für den Schlüssel key.
removeItem(key)Löscht den mit dem Schlüssel key assoziierten Wert.
clear()Löscht alle Schlüssel-Wert-Paare.

Bei der setItem-Funktion ist es so, dass zuallererst geprüft wird, ob der angegebene Schlüssel bereits existiert. Falls dem nicht so ist, wird der Schlüssel erzeugt und der angegebene Wert gespeichert. Für den Fall, dass der Schlüssel bereits existiert, wird der alte mit dem neuen Wert überschrieben. Weiterhin ist es bei der removeItem-Funktion so, dass neben dem Wert auch der Schlüssel selbst gelöscht wird.

Neben dem eigentlichen Storage-Interface gibt es, wie bereits erwähnt, zusätzlich noch das StorageEvent-Interface. Ein StorageEvent wird ausgelöst, sobald im Speicher eine Änderung registriert wurde. Dadurch besteht die Möglichkeit Race Conditions entgegenzuwirken, indem bei Eintritt eines solchen Events die Daten synchronisiert werden können. Hierfür liefert das entsprechende StorageEvent-Objekt sowohl den Schlüssel als auch den alten sowie neuen Wert des geänderten Schlüssel-Wert-Paares mit.

Die Web Storage API in Aktion

Dank der Einfachheit der Web Storage API benötigen wir nur eine einzelne Zeile Code, um ein Schlüssel-Wert-Paar zu speichern:

localStorage.setItem('name1', 'Tom');
JavaScript

Da es sich bei dem localStorage-Objekt um ein JavaScript-Objekt handelt, können wir auch folgendermaßen Daten speichern:

localStorage.name2 = 'Hans';
localStorage['name3'] = 'Sandra';
JavaScript

Analog zum Speichern können wir genauso einfach die Daten wieder auslesen:

localStorage.getItem('name1');
localStorage.name2;
localStorage['name3'];
JavaScript

Einen einzelnen Datensatz können wir mittels der removeItem-Funktion löschen:

localStorage.removeItem('name1');
JavaScript

Webbrowser-Unterstützung

Die Web Storage API wird in allen gängigen Webbrowsern unterstützt. Eine genaue Auflistung der einzelnen Webbrowser und den jeweiligen Versionen findet ihr auf caniuse.com.

Vor- & Nachteile

Wie jede API bzw. Technik hat natürlich auch die Web Storage API gewisse Vor- als auch Nachteile:

Vorteile:

  • einfach zu implementierende API
  • einfache Struktur der Daten durch Schlüssel-Wert-Format
  • von allen modernen Webbrowsern unterstützt
  • bietet mehr Speicher als Cookies

Nachteile:

  • synchrone API blockiert UI-Thread bei jedem Lese- und Schreibvorgang
  • keine asynchrone Variante der API vorhanden
  • nicht innerhalb von Worker-Threads nutzbar
  • keine Unterstützung von Transaktionen (wie bei Datenbanksystemen)
  • Speicherlimit mit ca. 5MB relativ gering bemessen
  • nur DOMString als Datentyp unterstützt
  • kein Mechanismus zum Durchsuchen der Daten

Mögliche Anwendungsfälle

Im Folgenden einige mögliche Anwendungsfälle für den Einsatz der Web Storage API:

  • Status der GUI einer Webseite bzw. Webapplikation speichern
  • Spielstatus bei Spielen speichern
  • anwendungs- & benutzerspezifische Einstellungen speichern
  • Web-Service-Anfragen bzw. die erhaltenen Daten cachen, da speziell Web-Services oftmals nur eine begrenzte Anzahl an Zugriffen in einem bestimmten Zeitintervall erlauben
  • generell zum Cachen von Daten, um z.B. Netzwerktraffic einzusparen und Performance einer Webapplikation zu verbessern

Fazit

Die HTML5 Web Storage API eignet sich, wie ich finde hervorragend zum Speichern von Daten kleinerer Größe. Habt ihr also Daten, die nicht notwendigerweise auf dem Server gespeichert werden müssen, wäre Web Storage eine sinnvolle Möglichkeit die Daten clientseitig zu speichern.

Was ich wünschenswert fände, wäre eine asynchrone API-Variante, wobei die API dann wohl wieder komplexer geworden werden.

Aktualisierungshistorie:
  • 5. Mai 2013
    ursprüngliche Veröffentlichung in meinem ehemaligen Blog "Smart-Webentwicklung"
Feedback

Für Feedback zum Beitrag, seien es Fragen, Korrigierungen und/oder Anregungen, könnt ihr mir gerne eine Nachricht per E-Mail oder Mastodon schreiben (siehe Kontakt).