Storage Manager API: Speicherplatz und Quota im Browser gezielt verwalten

1. Warum die Storage Manager API ein blinder Fleck vieler Web-Apps ist

Die Storage Manager API ist über navigator.storage in jedem modernen Browser verfügbar, wird aber in den meisten Anwendungen komplett ignoriert. Entwickler schreiben mit IndexedDB, Cache Storage oder dem Origin Private File System munter Daten, ohne je zu prüfen, wie viel Platz überhaupt noch da ist oder ob der Browser diese Daten jederzeit unter Speicherdruck räumen könnte. Genau diese Lücke schließt die Storage Manager API mit zwei zentralen Methoden: estimate() für die Quota-Berechnung und persist() für Persistenz-Anfragen.

Das Problem wird sichtbar, sobald eine Anwendung wächst: Ein Foto-Editor, der Bilder im Origin Private File System zwischenspeichert, ein Offline-Shop, der Produktkataloge in IndexedDB hält, oder eine PWA, die Assets im Cache Storage vorhält, alle konkurrieren um denselben Speicherplatz-Anteil, den der Browser dem Origin insgesamt zuteilt. Ohne die Storage Manager API erfährt die Anwendung von einem Engpass erst dann, wenn ein Schreibvorgang mit QuotaExceededError fehlschlägt, meist an einer ungünstigen Stelle im Ablauf.

Die Storage Manager API dreht dieses reaktive Muster um: Statt auf einen Fehler zu warten, kann die Anwendung proaktiv abfragen, wie viel Speicherplatz verfügbar ist, wie viel bereits belegt ist, und ob die Daten dauerhaft geschützt sind. Für datenintensive Web-Anwendungen ist die Storage Manager API damit kein optionales Detail, sondern eine Grundvoraussetzung für robustes Speicher-Management.

2. Quota und Nutzung mit estimate() berechnen

Die Methode navigator.storage.estimate() ist der zentrale Einstiegspunkt der Storage Manager API. Sie liefert ein Promise, das mit einem Objekt aus mindestens zwei Feldern aufgelöst wird: quota, die geschätzte maximale Speichermenge, die dem Origin zur Verfügung steht, und usage, die aktuell belegte Menge über alle Storage-APIs hinweg. Beide Werte sind in Bytes angegeben und erlauben eine einfache Berechnung des verbleibenden Spielraums.

Wichtig für den korrekten Einsatz der Storage Manager API: Der quota-Wert ist eine Schätzung, keine feste Zusage. Er hängt vom verfügbaren Festplattenspeicher, der Anzahl anderer Origins auf demselben Gerät und internen Heuristiken des Browsers ab. Chrome berechnet die Quota beispielsweise typischerweise als Anteil des freien Festplattenspeichers, während Firefox eine Gruppen-Quota über mehrere Origins hinweg verwaltet. Die Storage Manager API abstrahiert diese Unterschiede und liefert in jedem Fall eine konsistente, aktuelle Schätzung.

// Core Storage Manager API usage: query quota and current usage
async function getStorageReport() {
  if (!navigator.storage || !navigator.storage.estimate) {
    return { supported: false };
  }

  const { quota, usage } = await navigator.storage.estimate();
  const percentUsed = quota > 0 ? (usage / quota) * 100 : 0;

  return {
    supported: true,
    quotaBytes: quota,
    usageBytes: usage,
    remainingBytes: quota - usage,
    percentUsed: percentUsed.toFixed(2),
  };
}

const report = await getStorageReport();
console.log(`Using ${report.percentUsed}% of ${report.quotaBytes} bytes quota`);

In der Praxis lohnt es sich, die Storage Manager API regelmäßig abzufragen, etwa beim Anwendungsstart und vor größeren Schreiboperationen, statt sie nur einmalig beim ersten Laden aufzurufen. Da sich der verfügbare Speicherplatz durch andere Anwendungen auf demselben Gerät verändern kann, liefert eine einmalige Abfrage schnell veraltete Werte. Eine wiederkehrende Prüfung über die Storage Manager API, etwa alle paar Minuten oder vor kritischen Schreibvorgängen, hält die Einschätzung aktuell.

3. UsageDetails: Aufschlüsselung nach Speichertyp

Einige Browser, insbesondere Chrome-basierte, erweitern das Ergebnis von estimate() um ein usageDetails-Objekt, das die Gesamtnutzung nach Storage-Typ aufschlüsselt: indexedDB, caches, serviceWorkerRegistrations und weitere Felder zeigen an, welcher Anteil der Quota von welchem Mechanismus belegt wird. Diese Detailtiefe ist zwar nicht standardisiert und daher nicht auf allen Browsern verfügbar, aber für Debugging und Kapazitätsplanung äußerst hilfreich.

Mit den UsageDetails der Storage Manager API lässt sich zum Beispiel erkennen, dass eine Anwendung unerwartet viel Platz durch alte Cache-Einträge verbraucht, während IndexedDB nur einen kleinen Bruchteil ausmacht. Ohne diese Aufschlüsselung würde ein Team nur die Gesamtsumme sehen und müsste raten, welcher Speichermechanismus aufgeräumt werden muss. Die Storage Manager API liefert damit die Datenbasis für gezielte Cache-Invalidierung statt eines pauschalen "alles löschen".

// Break down usage by storage mechanism (Chromium-based browsers)
async function getUsageBreakdown() {
  const estimate = await navigator.storage.estimate();

  if (!estimate.usageDetails) {
    return { breakdown: null, total: estimate.usage };
  }

  const breakdown = Object.entries(estimate.usageDetails)
    .sort(([, a], [, b]) => b - a)
    .map(([mechanism, bytes]) => ({
      mechanism,
      megabytes: (bytes / (1024 * 1024)).toFixed(2),
    }));

  return { breakdown, total: estimate.usage };
}

const { breakdown } = await getUsageBreakdown();
breakdown?.forEach((entry) => {
  console.log(`${entry.mechanism}: ${entry.megabytes} MB`);
});

4. Best-Effort- gegenüber persistenter Speicherung

Der zweite zentrale Baustein der Storage Manager API ist das Persistenz-Modell. Standardmäßig behandeln Browser Daten in IndexedDB, Cache Storage oder dem Origin Private File System als "best effort", was bedeutet: Unter Speicherdruck, etwa wenn die Festplatte fast voll ist, darf der Browser Daten selten besuchter Origins automatisch löschen, ohne den Nutzer zu fragen. Für eine Notiz-App mag das akzeptabel sein, für eine Anwendung mit unwiederbringlichen Nutzerdaten ist es ein ernstes Risiko.

Mit navigator.storage.persist() stellt die Storage Manager API einen Mechanismus bereit, um Daten in den persistenten Modus zu überführen. Wird die Anfrage gewährt, garantiert der Browser, dass die Daten nur noch durch explizite Nutzeraktion gelöscht werden, etwa über die Browser-Einstellungen. Der Aufruf navigator.storage.persisted() prüft den aktuellen Status, ohne eine neue Anfrage auszulösen, was sich gut für einen Status-Check beim Anwendungsstart eignet.

// Storage Manager API: check and request persistent storage mode
async function ensureDurableStorage() {
  if (!navigator.storage || !navigator.storage.persist) {
    return { durable: false, reason: "not-supported" };
  }

  const alreadyPersisted = await navigator.storage.persisted();
  if (alreadyPersisted) {
    return { durable: true, reason: "already-persisted" };
  }

  const granted = await navigator.storage.persist();
  return {
    durable: granted,
    reason: granted ? "granted-now" : "denied-by-browser",
  };
}

const result = await ensureDurableStorage();
if (!result.durable) {
  console.warn("Data may be evicted under storage pressure:", result.reason);
}

5. Wie Browser über Persistenz-Anfragen entscheiden

Anders als bei Berechtigungen für Kamera oder Standort zeigt die Storage Manager API bei persist() normalerweise keinen sichtbaren Dialog an. Die Entscheidung basiert stattdessen auf internen Heuristiken, die je nach Browser unterschiedlich gewichtet sind: Wurde die Seite zum Startbildschirm hinzugefügt, existiert eine Push-Subscription, wie hoch ist die "Site Engagement"-Bewertung, wie oft besucht der Nutzer das Origin. Chrome gewährt Persistenz beispielsweise deutlich häufiger, wenn die Web-App bereits als PWA installiert wurde.

Diese unsichtbare Heuristik macht die Storage Manager API in der Praxis etwas unberechenbar: Eine Anfrage kann beim ersten Besuch abgelehnt und beim zweiten Besuch, nachdem der Nutzer die Seite mehrfach genutzt hat, automatisch gewährt werden. Für Teams bedeutet das: Eine einzelne Anfrage beim ersten Laden reicht nicht aus. Sinnvoller ist es, die Persistenz-Anfrage über die Storage Manager API bei jedem Anwendungsstart erneut zu prüfen und bei Bedarf erneut zu stellen, ohne den Nutzer dabei zu stören.

Firefox verhält sich anders und zeigt unter bestimmten Umständen tatsächlich einen Berechtigungsdialog an, während Safari die Persistenz-Anfrage der Storage Manager API bislang nicht vollständig unterstützt und stattdessen eigene Mechanismen zur Speicherplatz-Verwaltung nutzt. Diese Fragmentierung bedeutet, dass produktiver Code immer mit dem Fall rechnen muss, dass persist() entweder nicht existiert, sofort ablehnt oder sofort gewährt.

6. Ein proaktives Warnsystem gegen Speicherplatzmangel

Statt auf einen QuotaExceededError zu warten, lässt sich mit der Storage Manager API ein Warnsystem bauen, das Nutzer rechtzeitig informiert, bevor kritische Schreibvorgänge scheitern. Ein solches System prüft in regelmäßigen Abständen den verbleibenden Speicherplatz und löst ab einer definierten Schwelle, etwa 90 Prozent Auslastung, eine Benutzerbenachrichtigung oder eine automatische Bereinigung alter Daten aus.

Ein durchdachtes Warnsystem auf Basis der Storage Manager API kombiniert mehrere Signale: den aktuellen Prozentsatz aus estimate(), den Persistenz-Status aus persisted(), und optional die Aufschlüsselung aus usageDetails, um dem Nutzer nicht nur "Speicher wird knapp" zu melden, sondern konkret vorzuschlagen, welche Daten er löschen könnte. Diese Kombination macht aus einer technischen API-Abfrage ein nutzbares Produkt-Feature.

// Proactive storage pressure monitor using the Storage Manager API
class StorageWatchdog {
  #warningThreshold = 0.85;
  #criticalThreshold = 0.95;

  async checkAndReport() {
    const { quota, usage } = await navigator.storage.estimate();
    const ratio = usage / quota;

    if (ratio >= this.#criticalThreshold) {
      return { level: "critical", ratio, message: "Storage almost full, cleanup required" };
    }
    if (ratio >= this.#warningThreshold) {
      return { level: "warning", ratio, message: "Storage usage is high" };
    }
    return { level: "ok", ratio, message: "Storage usage is healthy" };
  }

  startMonitoring(intervalMs = 60000, onStatus) {
    const tick = async () => onStatus(await this.checkAndReport());
    tick();
    return setInterval(tick, intervalMs);
  }
}

const watchdog = new StorageWatchdog();
watchdog.startMonitoring(60000, (status) => {
  if (status.level !== "ok") console.warn(status.message, status.ratio);
});

7. Quota-Management über mehrere Storage-APIs hinweg

Ein wichtiger Aspekt der Storage Manager API: Die Quota gilt origin-weit, nicht pro einzelner Storage-Technologie. Das heißt, IndexedDB, Cache Storage, der Origin Private File System und sogar Service-Worker-Registrierungen teilen sich denselben Speicherplatz-Topf. Eine Anwendung, die aggressiv Bilder im Cache Storage vorhält, kann dadurch den Platz einschränken, der eigentlich für die IndexedDB-Datenbank vorgesehen war.

Für ein sauberes Quota-Management über die Storage Manager API empfiehlt sich eine zentrale Stelle im Code, die alle Storage-Schreibvorgänge koordiniert und vor größeren Operationen prüft, ob genug Spielraum vorhanden ist. Statt jeder Komponente eigenständig IndexedDB oder Cache Storage schreiben zu lassen, sollte ein gemeinsamer Storage-Koordinator die Storage Manager API konsultieren, Prioritäten zwischen den Datentypen setzen und im Zweifel ältere, weniger wichtige Cache-Einträge zuerst räumen.

8. Browser-Unterschiede und Testbarkeit

Die Storage Manager API ist zwar in der Spezifikation standardisiert, ihre konkreten Zahlen unterscheiden sich aber deutlich zwischen Browsern. Chrome liefert in der Regel großzügige Quota-Werte, oft mehrere Gigabyte, während Firefox konservativer rechnet und die Quota über eine Gruppen-Regelung mit anderen Origins teilt. In DevTools lässt sich die Storage Manager API mit gedrosselten Quota-Werten testen: Chrome DevTools bietet unter "Application > Storage" eine Simulation von Speicherplatzknappheit, mit der sich das Verhalten der eigenen Anwendung bei einem QuotaExceededError gezielt provozieren lässt.

Für automatisierte Tests empfiehlt sich, die Storage Manager API zu mocken, statt sich auf echte Browser-Quota zu verlassen, da diese je nach Testumgebung und verfügbarem Speicherplatz stark variiert. Ein Mock von navigator.storage.estimate, der feste Werte zurückgibt, macht Tests für das Warnsystem und die Quota-Logik deterministisch und unabhängig von der tatsächlichen Festplattenbelegung des Test-Runners.

9. Storage Manager API im Vergleich zu manuellen Ansätzen

Viele ältere Anwendungen versuchen, Speicherplatz-Probleme ohne die Storage Manager API zu lösen, etwa durch Try-Catch um jeden Schreibvorgang oder durch feste, willkürliche Obergrenzen im Anwendungscode. Die folgende Tabelle zeigt, warum die native Storage Manager API in fast allen Fällen die robustere Lösung ist.

Die Storage Manager API ersetzt Rätselraten durch belastbare Zahlen. Ein manueller Ansatz mit festen Obergrenzen ist immer entweder zu konservativ, was ungenutzten Speicherplatz verschenkt, oder zu optimistisch, was zu Datenverlust führt. Die Storage Manager API liefert die einzige Quelle, die tatsächlich weiß, wie viel Platz auf dem konkreten Gerät des Nutzers zur Verfügung steht.

10. Zusammenfassung

Die Storage Manager API schließt eine kritische Lücke in nahezu jeder Offline-fähigen Web-Anwendung: das Wissen um verfügbaren Speicherplatz und die Kontrolle darüber, ob Daten dauerhaft geschützt sind. Mit estimate() lässt sich jederzeit Quota und Nutzung abfragen, mit persist() und persisted() lässt sich der Persistenz-Status aktiv beeinflussen und überprüfen. Die optionale Aufschlüsselung über usageDetails liefert zusätzlich die Datenbasis für gezielte Bereinigung statt pauschaler Löschaktionen.

Wer die Storage Manager API konsequent in eine Anwendung integriert, ersetzt reaktives Fehlerhandling nach einem gescheiterten Schreibvorgang durch proaktives Monitoring, das Nutzer rechtzeitig informiert und Datenverlust verhindert, bevor er entsteht. Gerade für Anwendungen mit großen Datenmengen im Origin Private File System, in IndexedDB oder im Cache Storage ist die Storage Manager API damit kein Nice-to-have, sondern eine Grundvoraussetzung für verlässliches Speicher-Management.

11. FAQ: Storage Manager API und Quota