localStorage vs. sessionStorage vs. Cookies – ein detaillierter Vergleich

Cookies gibt es schon seit langer Zeit (Internet Explorer v2 unterstützte sie im Oktober 1995). An ihnen ist nichts auszusetzen, und sie haben das Web sicherlich zu einem angenehmeren Ort gemacht, aber nach fast 25 Jahren hat sich viel geändert.

Lokaler Speicher (Sie finden ihn unter Webspeicher auf W3) ist und ist kein Ersatz für Cookies. Das ist das Verwirrendste daran. In den meisten Fällen können Sie sicher localStorage anstelle von Cookies verwenden und den (falschen) Eindruck bekommen, dass sie gleich sind, obwohl sie es nicht sind. Lesen Sie weiter, um eine sachliche Aufschlüsselung zu sehen, wie und wann Sie localStorage verwenden, um Cookies zu ersetzen.

Revolution oder Evolution?

Lokaler Speicher oder localStorage oder DOM-Speicher oder Webspeicher (ich erfinde diese Namen nicht; sie werden alle verwendet und beziehen sich alle auf dasselbe) wurde 2012 von gängigen Browsern als „HTML5 Merkmal". Es schien wie ein Glücksfall-Ersatz für Kekse. Ein Fix für aufgeblähte Anfragen, die ständig unnötige Daten enthalten, und Größenbeschränkungen. Obwohl es diese Probleme „löst“, ist es kein Apfel-für-Äpfel-Ersatz für Kekse.

Und wo wir gerade beim Thema unnötige Daten sind. Wussten Sie, dass nicht nur Anfragen unnötig aufgebläht werden können, sondern auch Ihre Website. Glücklicherweise gibt es eine Lösung, und sie heißt WP Reset.

WP Reset ist ein Plugin, das mit einer Reihe von Zurücksetzungsoptionen ausgestattet ist, mit denen Sie beispielsweise angesammelte Daten und/oder Add-Ons (Plugins, Themen, Benutzer, Widgets, Inhalte usw.) von Ihrer Website entfernen und sogar Ihre gesamte Website sauber zu wischen. Erstaunlich, oder? Aber das ist nicht alles. Neben anderen Funktionen kann dieses Plugin Datenbank-Snapshots sowie Plugin- und Themensammlungen erstellen, die Sie mit einem Klick beliebig oft installieren können. Auf jeden Fall ein Tool, das es wert ist, überprüft zu werden.

Aber kommen wir jetzt zurück zu localStorage.

Wie der Name schon sagt, werden die Daten lokal auf dem Gerät des Benutzers gespeichert. Daher müssen sie nicht bei jeder HTTP-Anforderung über das Netzwerk übertragen werden, was den Platzbedarf verringert und uns viel mehr Platz zum Speichern der Daten gibt. Dieses Paradigma „nur lokal“ ist der bedeutendste Unterschied zwischen Cookies und lokaler Speicherung. Cookies können sowohl serverseitig als auch clientseitig gelesen werden, lokale Speicherung nur clientseitig. Das ist alles dazu. Wenn Ihre App stark davon abhängt, Cookies serverseitig zu lesen und darauf basierende Inhalte zu generieren, bedeutet der Wechsel zum lokalen Speicher, dass die App neu geschrieben wird. Wenn Sie Cookies nur verwenden, um Einstellungen zu speichern, z. B. welche Registerkarte in der Benutzeroberfläche aktiv ist, ist die lokale Speicherung ein idealer Ersatz.

Täuschend ähnlich

Die folgende Tabelle gibt einen klaren Einblick in die Unterschiede und Anwendungsfälle von Cookies, localStorage und sessionStorage. Sie können zwar schnell einen Blick darauf werfen, um die gewünschte Antwort zu erhalten, und dann gehen, aber ich würde empfehlen, die etwas langen Fußnoten zu lesen, die auf weitere Details eingehen. Ja, ich weiß, dass Sie beschäftigt sind und das nächste Katzenvideo sehen möchten, aber die Dinge sind nicht schwarz und weiß, also wird es Ihnen gut tun, ein bisschen tiefer zu graben.

Tiefer in Webspeicher und Cookies eintauchen

Die maximale Datenmenge, die Sie lokal speichern können, hängt vom Browser ab. Es gibt keine Garantien, und wenn Sie auf Nummer sicher gehen möchten, gehen Sie unter 5 MB auf etwa 2 MB. Verwenden Sie dieses praktische Tool, um die maximal zulässige lokale Speichergröße in Ihrem Browser zu testen.

Es ist ein häufiges Szenario, dass Benutzer Cookies von Drittanbietern oder alle Cookies blockieren . Die gleiche Regel gilt für die lokale Speicherung. Es gibt keine Garantien, und Ihre App muss in einer Umgebung funktionieren (oder zumindest nicht unterbrochen werden), in der kein lokaler Speicher verfügbar ist.

Alle Cookies verfallen irgendwann, aber die Leute neigen dazu, die Lebensdauer auf ein paar Jahre festzulegen, was in der Internetzeit ewig erscheint. Der lokale Speicher hingegen läuft nie ab und ist verfügbar, bis die App oder der Benutzer ihn löscht. Der Sitzungsspeicher wird geleert, wenn Tabs oder Fenster geschlossen werden – keine Ausnahmen.

„Was meinst du damit, dass nur Zeichenketten gespeichert werden können ? Ich speichere ständig Objekte!“ Mit JSON können Sie Objekte und andere Datentypen in Form eines Strings speichern. Die Konvertierung erfolgt beim Lesen und Schreiben ohne Ihr Wissen. Mit einer soliden Bibliothek für den Umgang mit Cookies und lokalem Speicher müssen Sie sich keine Gedanken über Datentypen machen. Das ändert jedoch nichts an der Tatsache, dass nativ nur Strings unterstützt werden.

Es gibt keine einzige clientseitige Funktion, die alle Browser unterstützen . Es ist eine traurige Tatsache, aber immer noch eine Tatsache. Sie können auf Can I Use nach bestimmten Nummern suchen, aber was Cookies und lokalen Speicher betrifft, würde ich alle Browser ignorieren, die sie nicht unterstützen. Sie sind marginal und liegen unter 1 %.

Sie können nicht nur über serverseitige Verarbeitung auf localStorage zugreifen. JS brauchst du auch. Wenn der Benutzer eine Seite anfordert und PHP einsetzt (oder welche serverseitige Sprache Sie verwenden), um sie zu generieren, haben Sie keinen Zugriff auf lokale Daten, Sitzungen oder permanente Daten. Sobald die Seite geladen ist und JS aktiviert wird, können Sie auf die lokalen Daten zugreifen und alles tun, was Sie brauchen – die Benutzeroberfläche anpassen oder AJAX verwenden, um lokale Daten an den Server zurückzusenden. Also ja, Sie können die lokalen Daten auf den Server zurückholen, aber nicht auf die gleiche Weise und im gleichen Moment wie mit einem Cookie. Abhängig von Ihren Anforderungen kann dies ein Deal-Breaker sein, wenn es darum geht, von Cookies auf lokalen Speicher umzusteigen, also bitte – planen Sie im Voraus!

Bei lokaler Speicherung werden keine Daten zwischen dem Client und dem Server übertragen (es sei denn, es gibt einen Code, der dies ausdrücklich tut). Es ist großartig, um die Nutzlastgröße zu reduzieren. Cookies hingegen werden bei jeder Anfrage auf der eingestellten Domain als HTTP-Header-Feld übertragen. Das lässt sich nicht ändern oder selektiv abschalten.

Benutzer „sollten nicht“ auf lokale Daten zugreifen und diese direkt (außerhalb Ihrer App) ändern, aber nichts hindert sie daran. Für die Bearbeitung lokal gespeicherter Daten stehen zahlreiche Debugging-Tools zur Verfügung. Vertrauen Sie also nicht lokalen Daten oder gehen Sie davon aus, dass der Benutzer sie nicht berührt hat. Gehen Sie immer vom Schlimmeren aus.

Obwohl Cookies über ein „sicheres“ Attribut verfügen, das Sie festlegen können, schützt dies das Cookie bei der Übertragung von der Anwendung zum Browser nicht. Es ist also besser als nichts, aber alles andere als sicher. Der lokale Speicher, der nur eine clientseitige Technologie ist, weiß nicht, ob Sie HTTP oder HTTPS verwenden, oder kümmert sich nicht darum. Sicherheit muss sich aus der Art und Weise ergeben, wie Sie mit Daten umgehen. Speichern Sie keine sensiblen Daten wie Kreditkartennummern oder Passwörter in irgendeiner Form von lokalem Speicher! Je!

Ein bisschen Code, um Ihnen den Einstieg zu erleichtern

Dieser Artikel soll kein JavaScript-Webspeicher-Tutorial sein, aber um Ihnen die Mühe zu ersparen, hier ein Hello-World-Beispiel mit lokalem Speicher;

// store a value
localStorage.setItem( 'name', 'John' );

// retrieve a value
localStorage.getItem( 'name' );

// remove the value
localStorage.removeItem( 'name' );

// only string values can be stored so for objects, use JSON
var post = {
  title: 'Cookies are old',
  author: 'Gordan'
}
localStorage.setItem( 'post', JSON.stringify( post ) );

// and to retrieve
var post = JSON.parse( localStorage.getItem( 'post' ) );

Der obige Code funktioniert und ist so einfach wie möglich. Ich empfehle jedoch nicht, es zu verwenden. Wie bei Cookies verwendet niemand document.cookies , um mit ihnen zu interagieren. Es gibt geringfügige browserübergreifende Unterschiede, die berücksichtigt werden müssen, und da sie nur Zeichenfolgen speichern, müssen Sie bei jedem Lese- und Schreibvorgang mit JSON stringifizieren und parsen. Aus diesem Grund verwenden wir kleine Bibliotheken, die uns bei der Handhabung von Cookies wie js-cookie helfen. Gleiches gilt für den lokalen Speicher. Auf lange Sicht hilft es, eine kleine Abstraktionsschicht zwischen Ihren Code und die API zu stellen. Ich empfehle store.js. Es gibt es schon eine Weile, kümmert sich um Cross-Browser-Unsinn und Fallbacks und hat sogar praktische Plugins, die seine Funktionen erweitern. Wenn Sie an etwas Programmierpraxis interessiert sind, erstellen Sie Ihre eigene Bibliothek und konvertieren Sie sie in ein jQuery-Plugin.

Kekse sind schlecht, oder? Wir brauchen etwas Neues!

Kekse sind nicht schlecht. Sie erfüllen seit Jahrzehnten ihren Zweck und werden dies auch weiterhin tun, da die lokale Lagerung kein „Äpfel für Äpfel“-Ersatz ist. Kekse zeigen jedoch Alterungserscheinungen. Abgesehen davon werden einige ihrer Designmängel auch nicht so schnell verschwinden. Nämlich jede Anfrage auf der Domain mit Cookie-Payload und kleiner maximaler Payload-Größe zu „verschmutzen“.

Unzureichend und alt oder nicht, Cookies sind hier, um zu bleiben, also denken Sie nicht, dass die lokale Speicherung in absehbarer Zeit vollständig übernehmen wird. In einigen Anwendungsfällen ist die lokale Speicherung jedoch zweifellos die bessere Wahl.

Wenn Sie (viele) Daten auf der Client-Seite speichern müssen, die selten auf den Server übertragen werden und diese Daten keine sensiblen Daten enthalten, beginnen Sie mit der Verwendung von lokalem Speicher ! Genau dafür wurde es geschaffen. Sie erstellen eine schnellere App, indem Sie alle HTTP-Anforderungen auf der Domain leichter machen, und erhalten das warme, unscharfe Gefühl, etwas Neues zu verwenden.