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 ermoglichen es Websites, Schlussel-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 nachsten 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') loschst 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 fur schnelle, leichtgewichtige Lese- und Schreibvorgange ausgelegt ist.

localStorage vs sessionStorage: Die wichtigsten Unterschiede

• Persistenz: localStorage-Daten bleiben im Browser, bis der Nutzer oder die Website sie explizit loscht. Es gibt kein Ablaufdatum. sessionStorage-Daten werden geloscht, sobald der Browser-Tab geschlossen wird.
• Geltungsbereich uber Tabs: localStorage wird zwischen allen Tabs und Fenstern geteilt, die zum selben Origin (Protokoll + Domain + Port) gehoren. sessionStorage ist auf einen einzelnen Tab beschrankt. Wenn du dieselbe Seite in zwei Tabs offnest, hat jeder Tab seinen eigenen sessionStorage.
• Speicherlimits: Beide bieten typischerweise 5 bis 10 MB pro Origin, abhangig vom Browser. Chrome und Firefox haben standardmassig etwa 5 MB pro Origin fur 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 angehangt werden.

Was WordPress-Seiten typischerweise speichern

WordPress-Plugins und -Themes nutzen den Browser-Speicher fur verschiedenste Zwecke. Hier sind die haufigsten:

• Theme-Einstellungen: Dark-Mode-Toggle, Sidebar ausgeklappt/eingeklappt, Schriftgrossenauswahl. Diese werden fast immer in localStorage gespeichert, weil sie das Schliessen eines Tabs uberleben sollen.
• Warenkorb-Daten: WooCommerce und ahnliche Plugins cachen Warenkorb-Fragmente manchmal in localStorage, um zusatzliche Server-Roundtrips beim Anzeigen des Mini-Warenkorbs im Header zu vermeiden.
• Formular-Entwurfe: Kontaktformular-Plugins speichern Nutzereingaben manchmal automatisch in sessionStorage, damit ein teilweise ausgefulltes Formular nicht verloren geht, wenn der Nutzer versehentlich wegnavigiert und per Zuruck-Button zuruckkehrt.
• Cookie-Einwilligungen: Einige Consent-Banner-Plugins (wie Complianz oder CookieYes) speichern den Einwilligungsstatus in localStorage statt in einem Cookie, obwohl ein Cookie haufiger 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-Menu gefaltet ist.
• Analytics- und Tracking-Puffer: Manche Analytics-Skripte sammeln Events in localStorage und senden sie gebundelt an den Server, um Netzwerk-Anfragen zu reduzieren.

Sicherheitsaspekte

Web Storage ist praktisch, bringt aber echte Sicherheitskompromisse mit sich, die Entwickler verstehen mussen.

• XSS-Angriffe: Jedes JavaScript auf der Seite kann localStorage und sessionStorage auslesen. Wenn ein Angreifer uber eine Cross-Site-Scripting-Schwachstelle (XSS) ein Skript einschleust, kann er jeden gespeicherten Wert extrahieren. Cookies konnen mit dem HttpOnly-Flag geschutzt werden, das den JavaScript-Zugriff komplett blockiert. Fur Web Storage gibt es keinen vergleichbaren Schutz.
• Same-Origin-Policy: Der Speicher ist auf den Origin beschrankt. Das bedeutet, https://example.com kann nicht den Speicher von https://other.com lesen. Allerdings hat jedes Skript auf demselben Origin, einschliesslich eingebundener Drittanbieter-Skripte (Analytics, Werbenetzwerke, Chat-Widgets), vollen Zugriff auf denselben Speicher.
• Keine Verschlusselung: Daten werden im Klartext auf der Festplatte gespeichert. Jeder mit physischem Zugriff auf das Gerat oder Schadsoftware kann sie lesen. Speichere niemals Passworter, 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 verandern. Verlasse dich niemals auf Web-Storage-Werte fur 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 Gerat eines Nutzers speicherst oder liest, die nicht unbedingt fur 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 ubersehen das, weil Cookie-Consent-Tools sich traditionell auf Cookies konzentrieren, aber Aufsichtsbehorden haben klargestellt, dass die Regeln fur 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 benotigt wird, oder wenn eine prazise Ablaufsteuerung gebraucht wird.
• localStorage verwenden: wenn clientseitige Einstellungen oder Cache-Daten uber Sitzungen hinweg bestehen bleiben sollen, die Daten nicht zum Server ubertragen werden mussen und die Daten nicht sensibel sind.
• sessionStorage verwenden: wenn die Daten nur fur die Dauer einer einzelnen Tab-Sitzung bestehen sollen, z.B. Formular-Wizard-Fortschritt, temporarer 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 grosse Datenmengen schreibt oder liest, kann das zu Rucklern fuhren. Cookies verursachen Overhead auf andere Weise: Sie vergressern jeden HTTP-Request-Header, was jeden Netzwerkaufruf verlangsamt. Fur eine Handvoll kleiner Werte funktionieren beide Ansatze gut. Fur grossere 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 grosse Browser ermoglicht die Inspektion von Web Storage. In Chrome offnest du die DevTools (F12), gehst zum Tab "Application" und findest "Local Storage" und "Session Storage" in der linken Seitenleiste. Du kannst jedes Schlussel-Wert-Paar sehen, Werte manuell bearbeiten und Eintrage loschen. Firefox hat ein ahnliches 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 pruft

InspectWP listet alle localStorage- und sessionStorage-Eintrage auf, die deine WordPress-Seite wahrend des Crawls setzt. So erhaltst du ein klares Bild davon, was deine Seite clientseitig speichert, welche Plugins dafur verantwortlich sind und ob Eintrage moglicherweise datenschutzrechtliche Bedenken nach DSGVO oder ePrivacy aufwerfen.