Was ist localStorage und sessionStorage?

localStorage und sessionStorage sind zwei Mechanismen der Web Storage API, einem Standard, der in jeden modernen Browser eingebaut ist. Sie ermöglichen es Websites, Schlüssel-Wert-Paare direkt im Browser des Besuchers zu speichern, ohne dass bei jedem Seitenaufruf der Server kontaktiert werden muss. Wenn du auf einer Website den Dark Mode aktiviert hast und diese Einstellung am nächsten Tag noch aktiv war, hat die Seite deine Wahl sehr wahrscheinlich in localStorage gespeichert.

So funktioniert die Web Storage API

Die Web Storage API ist bewusst einfach gehalten. Mit localStorage.setItem('key', 'value') schreibst du Daten, mit localStorage.getItem('key') liest du sie und mit localStorage.removeItem('key') löschst du sie. sessionStorage verwendet exakt die gleichen Methoden. Beide Speicher akzeptieren nur Strings, deshalb werden Objekte typischerweise mit JSON.stringify() serialisiert, bevor sie gespeichert werden. Es gibt keine Abfragesprache, keine Indizierung und keine relationale Struktur. Es ist ein flacher Key-Value-Store, der für schnelle, leichtgewichtige Lese- und Schreibvorgänge ausgelegt ist.

localStorage vs sessionStorage: Die wichtigsten Unterschiede

• Persistenz: localStorage-Daten bleiben im Browser, bis der Nutzer oder die Website sie explizit löscht. Es gibt kein Ablaufdatum. sessionStorage-Daten werden gelöscht, sobald der Browser-Tab geschlossen wird.
• Geltungsbereich über Tabs: localStorage wird zwischen allen Tabs und Fenstern geteilt, die zum selben Origin (Protokoll + Domain + Port) gehören. sessionStorage ist auf einen einzelnen Tab beschränkt. Wenn du dieselbe Seite in zwei Tabs öffnest, hat jeder Tab seinen eigenen sessionStorage.
• Speicherlimits: Beide bieten typischerweise 5 bis 10 MB pro Origin, abhängig vom Browser. Chrome und Firefox haben standardmäßig etwa 5 MB pro Origin für jeden Speicher. Safari kann strenger sein, besonders im privaten Modus, wo der Speicher teils auf wenige hundert Kilobyte begrenzt wird.
• Netzwerkverhalten: Weder localStorage noch sessionStorage werden bei HTTP-Anfragen an den Server gesendet. Das ist der grundlegende Unterschied zu Cookies, die automatisch an jeden Request-Header angehängt werden.

Was WordPress-Seiten typischerweise speichern

WordPress-Plugins und -Themes nutzen den Browser-Speicher für verschiedenste Zwecke. Hier sind die häufigsten:

• Theme-Einstellungen: Dark-Mode-Toggle, Sidebar ausgeklappt/eingeklappt, Schriftgrößenauswahl. Diese werden fast immer in localStorage gespeichert, weil sie das Schließen eines Tabs überleben sollen.
• Warenkorb-Daten: WooCommerce und ähnliche Plugins cachen Warenkorb-Fragmente manchmal in localStorage, um zusätzliche Server-Roundtrips beim Anzeigen des Mini-Warenkorbs im Header zu vermeiden.
• Formular-Entwürfe: Kontaktformular-Plugins speichern Nutzereingaben manchmal automatisch in sessionStorage, damit ein teilweise ausgefülltes Formular nicht verloren geht, wenn der Nutzer versehentlich wegnavigiert und per Zurück-Button zurückkehrt.
• Cookie-Einwilligungen: Einige Consent-Banner-Plugins (wie Complianz oder CookieYes) speichern den Einwilligungsstatus in localStorage statt in einem Cookie, obwohl ein Cookie häufiger verwendet wird.
• Admin-UI-Status: Das WordPress-Admin-Dashboard selbst nutzt beide Speichermechanismen. Es merkt sich zum Beispiel, welche Meta-Boxen eingeklappt sind, welche Spalten in der Beitragsliste sichtbar sind und ob das Admin-Menü gefaltet ist.
• Analytics- und Tracking-Puffer: Manche Analytics-Skripte sammeln Events in localStorage und senden sie gebündelt an den Server, um Netzwerk-Anfragen zu reduzieren.

Sicherheitsaspekte

Web Storage ist praktisch, bringt aber echte Sicherheitskompromisse mit sich, die Entwickler verstehen müssen.

• XSS-Angriffe: Jedes JavaScript auf der Seite kann localStorage und sessionStorage auslesen. Wenn ein Angreifer über eine Cross-Site-Scripting-Schwachstelle (XSS) ein Skript einschleust, kann er jeden gespeicherten Wert extrahieren. Cookies können mit dem HttpOnly-Flag geschützt werden, das den JavaScript-Zugriff komplett blockiert. Für Web Storage gibt es keinen vergleichbaren Schutz.
• Same-Origin-Policy: Der Speicher ist auf den Origin beschränkt. Das bedeutet, https://example.com kann nicht den Speicher von https://other.com lesen. Allerdings hat jedes Skript auf demselben Origin, einschließlich eingebundener Drittanbieter-Skripte (Analytics, Werbenetzwerke, Chat-Widgets), vollen Zugriff auf denselben Speicher.
• Keine Verschlüsselung: Daten werden im Klartext auf der Festplatte gespeichert. Jeder mit physischem Zugriff auf das Gerät oder Schadsoftware kann sie lesen. Speichere niemals Passwörter, Tokens oder andere sensible Zugangsdaten in Web Storage.
• Keine serverseitige Validierung: Da die Daten nur im Browser leben, kann ein Nutzer oder Skript sie frei verändern. Verlasse dich niemals auf Web-Storage-Werte für Autorisierungs- oder Sicherheitsentscheidungen auf dem Server.

DSGVO und Datenschutzauswirkungen

Nach der DSGVO und der ePrivacy-Richtlinie werden localStorage und sessionStorage bei den Einwilligungsanforderungen genauso behandelt wie Cookies. Das rechtliche Prinzip ist technologieneutral: Wenn du Informationen auf dem Gerät eines Nutzers speicherst oder liest, die nicht unbedingt für den vom Nutzer angeforderten Dienst erforderlich sind, brauchst du eine Einwilligung. Das bedeutet, ein WooCommerce-Warenkorb in localStorage ist wahrscheinlich "unbedingt erforderlich" und braucht keine Einwilligung. Aber eine Analytics-ID in localStorage, die wiederkehrende Besucher trackt, erfordert definitiv eine. Viele Seitenbetreiber übersehen das, weil Cookie-Consent-Tools sich traditionell auf Cookies konzentrieren, aber Aufsichtsbehörden haben klargestellt, dass die Regeln für alle clientseitigen Speichertechnologien gelten.

Web Storage vs Cookies: Wann was verwenden

• Cookies verwenden: wenn der Server den Wert bei jeder Anfrage braucht (Session-IDs, Authentifizierungs-Tokens), wenn HttpOnly-Schutz gegen XSS benötigt wird, oder wenn eine präzise Ablaufsteuerung gebraucht wird.
• localStorage verwenden: wenn clientseitige Einstellungen oder Cache-Daten über Sitzungen hinweg bestehen bleiben sollen, die Daten nicht zum Server übertragen werden müssen und die Daten nicht sensibel sind.
• sessionStorage verwenden: wenn die Daten nur für die Dauer einer einzelnen Tab-Sitzung bestehen sollen, z.B. Formular-Wizard-Fortschritt, temporärer UI-Status oder einmalige Redirect-Tokens.

Performance-Vergleich

Lesen und Schreiben in Web Storage ist synchron und findet auf dem Haupt-Thread statt. Bei kleinen Datenmengen ist das schnell, normalerweise unter einer Millisekunde. Aber wenn eine Seite bei jeder Interaktion große Datenmengen schreibt oder liest, kann das zu Rucklern führen. Cookies verursachen Overhead auf andere Weise: Sie vergrößern jeden HTTP-Request-Header, was jeden Netzwerkaufruf verlangsamt. Für eine Handvoll kleiner Werte funktionieren beide Ansätze gut. Für größere Datenmengen (zehn KB oder mehr) ist IndexedDB zu empfehlen, da es asynchron arbeitet und den Haupt-Thread nicht blockiert.

Web Storage in den DevTools inspizieren

Jeder große Browser ermöglicht die Inspektion von Web Storage. In Chrome öffnest du die DevTools (F12), gehst zum Tab "Application" und findest "Local Storage" und "Session Storage" in der linken Seitenleiste. Du kannst jedes Schlüssel-Wert-Paar sehen, Werte manuell bearbeiten und Einträge löschen. Firefox hat ein ähnliches Panel unter dem Tab "Storage". Das ist der einfachste Weg, um genau zu sehen, was eine WordPress-Seite in deinem Browser speichert, und um unerwartetes Verhalten zu analysieren.

Was InspectWP prüft

InspectWP listet alle localStorage- und sessionStorage-Einträge auf, die deine WordPress-Seite während des Crawls setzt. So erhältst du ein klares Bild davon, was deine Seite clientseitig speichert, welche Plugins dafür verantwortlich sind und ob Einträge möglicherweise datenschutzrechtliche Bedenken nach DSGVO oder ePrivacy aufwerfen.