Back

Wie IndexedDB im Vergleich zu LocalStorage und SessionStorage abschneidet

Wie IndexedDB im Vergleich zu LocalStorage und SessionStorage abschneidet

Bei der Entwicklung moderner Webanwendungen kann die Wahl der richtigen clientseitigen Speicher-API die Performance und User Experience Ihrer App erheblich beeinflussen. Während LocalStorage und SessionStorage gut für einfache Daten funktionieren, bietet IndexedDB Funktionen, die es für Offline-Web-Apps und komplexes Datenmanagement unverzichtbar machen. Schauen wir uns an, wie diese JavaScript-Browser-Speicheroptionen im Vergleich abschneiden und wann man welche verwenden sollte.

Die wichtigsten Erkenntnisse

  • LocalStorage und SessionStorage sind synchrone APIs, die auf 5-10 MB String-Daten begrenzt sind
  • IndexedDB bietet asynchrone, nicht-blockierende Operationen mit praktisch unbegrenztem Speicher
  • IndexedDB unterstützt komplexe Datentypen, Transaktionen und Indizierung für effiziente Abfragen
  • Wählen Sie den Speicher basierend auf der Datenkomplexität: einfache Strings verwenden LocalStorage, komplexe Objekte benötigen IndexedDB

Die drei clientseitigen Speicher-APIs verstehen

LocalStorage: Einfach und persistent

LocalStorage speichert Schlüssel-Wert-Paare als Strings, die unbegrenzt bestehen bleiben, bis sie explizit gelöscht werden. Mit einer typischen Kapazität von 5-10 MB pro Origin eignet es sich ideal für Benutzereinstellungen, Theme-Einstellungen oder kleine Konfigurationsdaten.

localStorage.setItem('userTheme', 'dark');
const theme = localStorage.getItem('userTheme'); // Returns 'dark'

Die synchrone Natur von LocalStorage bedeutet, dass jede Operation den Hauptthread blockiert. Das Lesen oder Schreiben von nur 1 MB Daten kann Ihre UI auf durchschnittlichen Geräten für 100-200 Millisekunden einfrieren.

SessionStorage: Temporärer Tab-Speicher

SessionStorage funktioniert identisch zu LocalStorage, aber mit einem entscheidenden Unterschied: Die Daten verfallen, wenn der Tab geschlossen wird. Es behält das gleiche 5-10 MB Limit und die synchrone API bei und eignet sich daher für temporäre Formulardaten oder Single-Session-Statusverwaltung.

sessionStorage.setItem('formDraft', JSON.stringify(formData));

Daten bleiben pro Tab isoliert – das Öffnen derselben Seite in einem neuen Tab erstellt eine separate SessionStorage-Instanz.

IndexedDB vs. LocalStorage und SessionStorage: Hauptunterschiede

Speicherkapazität und Datentypen

Während LocalStorage und SessionStorage Sie auf Strings und 5-10 MB Speicherplatz beschränken, verarbeitet IndexedDB praktisch unbegrenzten Speicher (oft 50% des verfügbaren Festplattenspeichers) und speichert JavaScript-Objekte direkt:

// IndexedDB stores complex objects without serialization
const userData = {
  id: 1,
  profile: { name: 'Alice', avatar: blobData },
  settings: { theme: 'dark', notifications: true },
  lastSync: new Date()
};
// Note: Map objects cannot be directly stored in IndexedDB

Performance-Eigenschaften

Der kritischste Unterschied liegt in der Performance. LocalStorage und SessionStorage verwenden synchrone Operationen, die die JavaScript-Ausführung blockieren:

  • LocalStorage/SessionStorage: Synchron, blockiert den Hauptthread
  • IndexedDB: Asynchron, nicht-blockierende Operationen

Bei größeren Datensätzen kann LocalStorage die UI aufgrund seiner synchronen Natur spürbar blockieren, während IndexedDB-Operationen asynchron laufen und die UI responsiv halten.

Datenintegrität und Transaktionen

IndexedDB bietet transaktionale Operationen, die Datenkonsistenz gewährleisten. Wenn ein Teil einer Transaktion fehlschlägt, werden alle Änderungen automatisch zurückgesetzt – entscheidend für Offline-Web-Apps, die Datenintegrität wahren müssen.

Wann IndexedDB LocalStorage übertrifft

Offline-First-Anwendungen

Betrachten Sie eine Notizen-App, die offline funktioniert. Mit IndexedDB können Sie Tausende von Dokumenten mit Anhängen speichern, sie effizient mit Indizes durchsuchen und Änderungen bei Wiederverbindung synchronisieren – unmöglich mit den Einschränkungen von LocalStorage.

Verwaltung großer Datensätze

E-Commerce-Seiten können ganze Produktkataloge in IndexedDB zwischenspeichern. Anwendungen wie Linear nutzen diesen Ansatz, um Projektdaten lokal zu speichern und die Cache-Gültigkeit zu prüfen, bevor Server-Anfragen gestellt werden, was die Ladezeiten erheblich reduziert.

Komplexe Datenstrukturen

IndexedDB verarbeitet Blobs, Files und Typed Arrays nativ. Eine Fotobearbeitungs-App kann Bilder direkt speichern, ohne Base64-Kodierung (die die Größe in LocalStorage um 33% erhöht).

Praktischer Implementierungsvergleich

Hier ist ein reales Beispiel zum Speichern von Benutzerdaten:

// LocalStorage - requires serialization, blocks UI
const saveToLocalStorage = (data) => {
  localStorage.setItem('userData', JSON.stringify(data)); // Blocks thread
};

// IndexedDB - handles objects, non-blocking (using idb library)
const saveToIndexedDB = async (data) => {
  const db = await openDB('MyApp', 1, {
    upgrade(db) {
      db.createObjectStore('users', { keyPath: 'id' });
    }
  });
  const tx = db.transaction('users', 'readwrite');
  await tx.objectStore('users').put(data); // Non-blocking
};

Browser-Kompatibilität und Einschränkungen

Alle drei APIs genießen ab 2025 universelle Browser-Unterstützung. Das Verhalten variiert jedoch im privaten Browsing-Modus:

  • Safari: Erzwingt niedrigere Kontingente im privaten Modus im Vergleich zum normalen Browsen
  • Firefox: Löscht alle Speicher, wenn die private Sitzung endet
  • Chrome: Behält Standard-Kontingente im Inkognito-Modus bei

Auch die Speicher-Eviction-Richtlinien unterscheiden sich. Browser können Speicher löschen, wenn der Festplattenspeicher knapp wird, wobei IndexedDB-Daten, die als „persistent” markiert sind, vor automatischer Löschung geschützt werden.

Die richtige Wahl treffen

Wählen Sie LocalStorage für:

  • Benutzereinstellungen unter 1 MB
  • Einfache String-Daten
  • Schnelle Prototypen

Wählen Sie SessionStorage für:

  • Formular-Entwürfe
  • Temporären UI-Status
  • Single-Tab-Workflows

Wählen Sie IndexedDB für:

  • Offline-Funktionalität
  • Daten über 5 MB
  • Komplexe Objekte und Dateien
  • Such- und Filteranforderungen
  • Transaktionsintegritätsanforderungen

Fazit

Während LocalStorage und SessionStorage für einfache Speicheranforderungen wertvoll bleiben, ist IndexedDB für den Aufbau performanter, offline-fähiger Webanwendungen unverzichtbar. Seine asynchrone Natur, unbegrenzte Kapazität und Transaktionsunterstützung machen es zur einzig praktikablen Wahl für die Speicherung großer Datensätze oder komplexer Datenstrukturen. Für moderne JavaScript-Browser-Speicheranforderungen, die über einfache Schlüssel-Wert-Paare hinausgehen, ist IndexedDB die empfohlene Wahl für komplexe oder großangelegte clientseitige Speicherung.

Häufig gestellte Fragen (FAQs)

Nein, IndexedDB kann Map- und Set-Objekte nicht direkt speichern. Sie müssen sie vor dem Speichern in reguläre Objekte oder Arrays umwandeln. Verwenden Sie Array.from() für Sets und Object.fromEntries() für Maps und rekonstruieren Sie sie dann beim Abrufen der Daten.

Das Leeren des Browser-Caches wirkt sich normalerweise nicht auf IndexedDB-Daten aus. Benutzer müssen speziell Site-Daten oder Cookies löschen, um IndexedDB-Inhalte zu entfernen. Browser können IndexedDB-Daten jedoch bei Speicherdruck entfernen, es sei denn, sie sind mit der Storage API als persistent markiert.

Für winzige Daten unter 100 KB kann LocalStorage aufgrund seiner synchronen Natur bei einfachen Lesevorgängen schneller sein. Die nicht-blockierenden Operationen von IndexedDB verhindern jedoch UI-Einfrierungen, was es selbst bei kleinen Datensätzen in Produktionsanwendungen besser für die User Experience macht.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.

OpenReplay