Zuletzt aktualisiert am 14. April 2021.
Oder: Mittels JavaScript eine Alternative zu Cookies nutzen und Webanwendungen beschleunigen
localStorage und sessionStorage sind Teil der Web Storage API, die mittlerweile von allen modernen Browsern unterstützt wird. Einsatzzweck ist das lokale Speichern von Daten im Browser. Manch einem schießen nun sicherlich sofort die allseits bekannten “Cookies” in den Sinn. Aber die Web Storage API samt local- und sessionStorage bietet viele Vorteile.
Was sind localStorage, sessionStorage und Indexed DB?
Vergleich von localStorage, sessionStorage, Indexed DB und Cookies. Schauen wir uns einmal an, was ie verschiedenen Ansätze bieten und was sie unterscheidet. Daraus ergeben sich dann natürlich die Einsatzzwecke.
localStorage: Local Storage ist im Prinzip ein Replacement für die althergebrachten, aber mittlerweile im Datenschutz in Verruf geratenen Cookies. Der große Unterscheid zu Cookies ist, dass der localStorage NUR vom Client und nicht vom Server ausgelesen werden kann.
sessionStorage: Session Storage ist localStorage mit einer begrenzten Lebenszeit und einem begrenzten Scope. Die gespeicherten key => value Paare sind nur bis zum Schließen des jeweiligen Browserfensters oder Browsertabs verfügbar. Ebenso bezieht sich der Geltungsbereich NUR auf das jeweils geöffnete Browserfenster bzw. Browsertab.
Wichtig: Sowohl localStorage als auch sessionStorage sind nur vom Client lesbar. Es handelt sich zudem um einen strukturierten Speicher, der einem Array ähnelt und auf key => value Basis arbeitet.
Tabellarische Gegenüberstellung:
localStorage | sessionStorage | indexed DB | Cookies | |
Speichergröße (Nutzlast) | bis zu 10MB | bis zu 10MB | – | > 4kB |
Lebenszeit | unbegrenzt | Bis das Browserfenster oder der Tab geschlossen wird | – | unbegrenzt (wie im Cookie angegeben) |
Scope/Geltungsbereich | Innerhalb ALLER Browserfenster/Tabs | Innerhalb des gerade geöffneten Browserfensters/Tabs | – | Alle Tabs und Fenster des Browsers |
Lesbarkeit / Datenschutz | Nur vom Client selbst lesbar | Nur vom Client selbst lesbar | – | Von Client und Server lesbar! |
Besonderheiten | Wird erst gelöscht, wenn Cache des Browsers gelöscht wird, oder explizit der Eintrag von der Anwendung gelöscht wird. | Wird gelöscht, wenn der Browser, das Browserfenster oder das Browsertab geschlossen wird. | – |
Cookies sind das etablierte, aber etwas in die Zeit gekommene Werkzeug, das besonders im Datenschutz strukturelle Schwächen aufweist.
Nur der localStorage und der sessionStorage zählen zur Web Storage API.
Sonderfall Indexed DB
Das Speichern von Daten lokal im Browser des Nutzers eröffnet viele und komplexe Möglichkeiten. So sind neben normalen Webseiten auch Webseiten für den Offline-Betrieb und/oder komplexe Web-Apps denkbar.
Hier kann der localStorage und SessionStorage an seine Grenzen stoßen, da es sich um einen simplen – und daher komfortabel nutzbaren – Speicher nach dem key => value Prinzip handelt. Es sind keinerlei Querys, oder dergleichen, sondern nur simple String-Operationen. Das – und das Fehlen eines Index – sorgt zudem für Performanceeinschränkungen bei größeren Datenmengen.
Die Lösung ist hier eine komplett lokal im Browser laufende Datenbank (genauer gesagt ein DBMS, also Datenbankmanagement System). Hier bietet sich dann indexed DB an.
Kompatibilität: Wie sieht es mit der Browserunterstützung aus?
Browser | localStorage | sessionStorage | indexed DB | Cookies |
Chrome | 4 | 5 | 31 | ✅* |
Firefox | 3.6 | 3.6 | 38 | ✅* |
Internet Explorer | 8 | 8 | 10 | ✅* |
Edge | 12 | 12 | 12 | ✅* |
Opera | 10.5 | 10.5 | 32 | ✅* |
Safari (iOS) | 3.2 | 3.2 | – | ✅* |
Android Browser | 37 | 37 | – | ✅* |
(*) Achtung: Cookies sind angezählt. Zwar werden Cookies von nahezu jedem Browser unterstützt, die Technologie ist jedoch durch sog. “Third-Party-Cookies” in Verruf geraten, die das Tracken von Nutzern über mehrere Webseiten und Browserfenster hinweg ermöglichen.
Was benötigt man für die Nutzung?
Als Nutzer benötigt man nur einen aktuellen Browser und eine Unterstützung durch die jeweils aufgerufene Webseite.
Um localStorage und sessionStorage als Entwickler zu nutzen, sollten rudimentäre JavaScript-Kenntnisse vorhanden sein. Dann kann es auch schon losgehen 😉
Ab in die Praxis: Arbeiten mit localStorage und sessionStorage
Die aktuelle Belegung der verschiedenen Storages kann z.B: im Chrome Browser in den Developer-Tools unter dem Reiter “Application” eingesehen werden.
Sowohl localStorage, als auch sessionStorage stehen als Objekte in JavaScript zur Verfügung und verfügen über eigene Methoden:
Eintrag im localStorage/sessionStorage erstellen
Nichts einfacher als das 😉
Wir definieren/benennen zunächst den Key, unter dem unser Eintrag im local.Storage oder synonym im sessionStorage gespeichert werden soll.
Wir nutzen nun das localStorage-Objekt und dessen Methode “setItem()” um unter dem entsprechenden Key einen Value (String) zu speichern.
//Zuerst den Key definieren/benennen
let key = 'Position1';
//Mittels setItem und Übergabe des key den Value setzen
localStorage.setItem(key, 'Value');
Eintrag im localStorage/sessionStorage lesen
Wie aus der objektorientieren Programmierung gewohnt, können wir auch einzelne Werte aus dem Storage lesen:
let myPosition = localStorage.getItem(key);
Eintrag aus dem localStorage/sessionStorage entfernen
//Einen Eintrag entfernen
localStorage.removeItem(key);
//Den gesamten localStorage löschen
localStorage.clear();
Probleme mit sessionStorage und Co? Ein Fall aus der Praxis
Ich arbeite häufig mit einem größeren Projekt auf WordPress/BuddyPress-Basis. Hier werden Gruppen genutzt, um den Austausch zu bestimmten Themen zu gewährleisten.
Jetzt werden auf der Startseite mittels eines Shortcodes die 5 aktivsten Gruppen angezeigt. Zusätzlich gibt es eine “Gruppen-Übersichts-Seite”, auf der alle verfügbaren Gruppen angezeigt werden.
Dummerweise wird seitens BuddyPress nun die Query für die jeweilige Gruppenanzeige in den sessionStorage geschrieben und zwischengespeichert.
Das Ergebnis ist, dass wenn man zuvor eine der erwähnten Seiten aufgerufen hat, die gleiche Query auch für die darauf aufgerufene Seite gilt. So kommt es dazu, dass auf der Startseite z.B. alle Gruppen angezeigt werden, wenn man zunächst auf der Gruppen-Übersichts-Seite” gewesen ist usw.
Also liegt es hier nahe, dass wir den sessionStorage hier nicht nutzen sollten/wollen.
Dafür ist es umso komfortabler, dass die zwischengespeicherte Filterung einfach per JavaScript aus dem session Storage gelöscht werden kann:
sessionStorage.removeItem('bp-groups');
Das Skript führe ich einfach auf den entsprechenden Seite nach vollständigem Laden mittels jQuery aus:
jQuery( document ).ready( function(){
sessionStorage.removeItem('bp-groups');
});
Et voila, nun wird bei jedem Aufruf wieder neu der Inhalt geladen und nicht mehr die zwischengespeicherte Query genutzt.
Quellen
- https://developer.mozilla.org/de/docs/Web/API/Window/localStorage
Schreibe eine Antwort