Speicherplatz für das Web

Es gibt viele verschiedene Möglichkeiten, Daten im Browser zu speichern. Welche Option ist für Sie am besten geeignet?

Pete LePage

Daher kann die Internetverbindung von unterwegs aus instabil sein oder gar nicht vorhanden sein. sind Offline-Support und zuverlässige Leistung gängige Funktionen progressive Web-Apps. Auch bei perfekter kabelloser kann der vernünftige Einsatz von Caching und anderen Speichertechniken die User Experience erheblich verbessern. Es gibt mehrere Möglichkeiten, Ihre statischen Anwendungsressourcen (HTML, JavaScript, CSS, Bilder usw.) und Daten (Nutzerdaten, Nachrichtenartikel usw.). Aber was ist die beste Lösung? Wie wie viel kann ich speichern? Wie verhindern Sie, dass es entfernt wird?

Was soll ich verwenden?

Allgemeine Empfehlung zum Speichern von Ressourcen:

• Für die Netzwerkressourcen, die zum Laden Ihrer App und dateibasierten Inhalte erforderlich sind, Verwenden Sie die Cache Storage API (Teil von Service Worker).
• Verwenden Sie für andere Daten IndexedDB (mit einem Promises-Wrapper).

IndexedDB und die Cache Storage API werden in jedem modernen Browser unterstützt. Beide sind asynchron und blockieren nicht den Hauptthread. Sie sind zugänglich über das window-Objekt, Web Worker und Service Worker. können Sie sie überall im Code verwenden.

Wie sieht es mit anderen Speichermechanismen aus?

Der Browser bietet noch weitere Speichermechanismen, die jedoch werden nur wenig genutzt und können erhebliche Leistungsprobleme verursachen.

SessionStorage ist tabulatorspezifisch und Lebensdauer des Tabs. Dies kann nützlich sein, um kurze Sitzungssitzungen zu speichern. bestimmte Informationen enthalten, z. B. einen IndexedDB-Schlüssel. Diese Methode sollte mit da er synchron ist und den Hauptthread blockiert. Es ist ist auf etwa 5 MB begrenzt und darf nur Strings enthalten. Da sie tabulatorspezifisch sind, Der Zugriff auf sie ist über Web Worker oder Service Worker nicht möglich.

LocalStorage sollte nicht verwendet werden, da dies synchron ist. und blockiert den Hauptthread. Sie ist auf etwa 5 MB beschränkt und kann nur Zeichenfolgen. LocalStorage kann nicht über Web Worker oder Dienste aufgerufen werden Arbeiter.

Cookies werden verwendet, sollten jedoch nicht zum Speichern verwendet werden. Cookies werden mit jeder HTTP-Anfrage gesendet. kleine Datenmenge erhöht die Größe jeder Webanfrage erheblich. Sie sind synchron und können über Web Worker nicht aufgerufen werden. Gefällt mir LocalStorage und SessionStorage sind Cookies nur auf Strings beschränkt.

Die File System API und die FileWriter API bieten Methoden zum Lesen und Schreiben von Dateien in einem Sandbox-Dateisystem. Sie ist zwar asynchron, nicht empfohlen, da sie nur in Chromium-basierten Browsern verfügbar.

Die File System Access API wurde entwickelt, und das Lesen und Bearbeiten von Dateien in ihrem lokalen Dateisystem. Der Nutzer muss die Berechtigung erteilen, bevor eine Seite eine lokale Datei lesen oder in eine lokale Datei schreiben kann und Berechtigungen bleiben sitzungsübergreifend erhalten.

WebSQL sollte nicht verwendet werden und die vorhandene Nutzung sollte migriert werden zu IndexedDB verwendet wird. Fast alle wichtigen Inhalte wurden entfernt Browser. Das W3C hat die Wartung der Web SQL-Spezifikation 2010 eingestellt, und es sind keine weiteren Updates geplant.

Der Application Cache sollte nicht verwendet werden und die vorhandene Nutzung sollte die zu Service Workern und zur Cache API migriert wurden. Es wurde eingestellt und der Support für Browser wird in in die Zukunft zu führen.

Wie viel kann ich speichern?

Kurz gesagt: Sehr, mindestens ein paar hundert Megabyte und potenziell Hunderte Gigabyte oder mehr. Browserimplementierungen unterscheiden sich, hängt in der Regel davon ab, wie viel Speicherplatz .

• Mit Chrome kann der Browser bis zu 80% des gesamten Speicherplatzes nutzen. Ein Ursprung kann bis zu 60% des gesamten Speicherplatzes. Mit dem StorageManager API, um das maximal verfügbare Kontingent zu ermitteln. Andere Chromium-basierte können sich unterscheiden.
  • Im Inkognitomodus reduziert Chrome den Speicherplatz, den ein Ursprung nutzen kann auf etwa 5% des gesamten Festplattenspeichers aus.
  • Wenn der Nutzer die Option „Cookies und Websitedaten nach Schließen aller Fenster" in Chrome wird das Speicherkontingent deutlich auf eine maximal ca. 300 MB groß sein.
  • Siehe PR-Nr. 3896 für Informationen zur Implementierung von Chrome.
• Internet Explorer 10 und höher können bis zu 250 MB speichern und wenn mehr als 10 MB verwendet wurden.
• Bei Firefox können bis zu 50% des freien Speicherplatzes im Browser verwendet werden. Eine eTLD+1 Gruppe (z.B. example.com, www.example.com und foo.bar.example.com) bis zu 2 GB Speicherplatz belegen. Sie können die StorageManager API, um zu ermitteln, wie viel Speicherplatz noch verfügbar ist verfügbar.
• In Safari (Desktop- und Mobilgeräte) sind etwa 1 GB Speicherplatz erlaubt. Wenn der Grenzwert erreicht ist, werden Sie von Safari aufgefordert, das Limit auf 200 MB zu erhöhen. Inkrementen. Ich konnte dazu keine offizielle Dokumentation finden.
  • Wenn in Safari eine PWA zum Startbildschirm hinzugefügt wird, scheint sie Erstellen Sie einen neuen Speichercontainer, sodass nichts von der PWA gemeinsam verwendet wird. und Safari für Mobilgeräte. Sobald das Kontingent für eine installierte PWA erreicht ist, scheint keine Möglichkeit zu sein, zusätzlichen Speicherplatz anzufordern.

Wenn eine Website in der Vergangenheit einen bestimmten Schwellenwert für die Speicherung von Daten überschritten hat, wird der Nutzer aufgefordert, seine Datennutzung zu genehmigen. Für Verwendet der Ursprung beispielsweise mehr als 50 MB, fordert der Browser um bis zu 100 MB speichern zu können, und frage dann noch einmal in Schritten von 50 MB danach.

Heutzutage fordern die meisten modernen Browser den Nutzer nicht auf, sondern lassen eine Website zu. das zugeteilte Kontingent ausgeschöpft werden kann. Die Ausnahme ist Safari, wird bei Überschreitung des Speicherkontingents angezeigt und fordert die Berechtigung zur Erhöhung an. das zugewiesene Kontingent. Wenn ein Ursprung versucht, das zugewiesene Kontingent zu überschreiten, werden weitere Versuche, Daten zu schreiben, schlägt fehl.

Wie kann ich überprüfen, wie viel Speicherplatz verfügbar ist?

In vielen Browsern können Sie den StorageManager API, um den Speicherplatz zu ermitteln für den Ursprung verfügbar ist und wie viel Speicherplatz er verwendet. Die Gesamtzahl der Conversions Anzahl der Byte, die von IndexedDB und der Cache API verwendet werden, und macht es möglich, um den ungefähren verfügbaren Speicherplatz zu berechnen.

if (navigator.storage && navigator.storage.estimate) {
  const quota = await navigator.storage.estimate();
  // quota.usage -> Number of bytes used.
  // quota.quota -> Maximum number of bytes available.
  const percentageUsed = (quota.usage / quota.quota) * 100;
  console.log(`You've used ${percentageUsed}% of the available storage.`);
  const remaining = quota.quota - quota.usage;
  console.log(`You can write up to ${remaining} more bytes.`);
}

Der StorageManager ist noch nicht in allen implemented. müssen vor der Verwendung erkannt werden. Auch wenn sie verfügbar ist, müssen Sie Fehler aufgrund von Kontingentüberschreitungen dennoch erkennen (siehe unten). In einigen Fällen ist es möglich, das verfügbare Kontingent so hoch, dass die tatsächlich verfügbaren Speichermengen überschritten werden.

Prüfen

Während der Entwicklung kannst du mit den Entwicklertools deines Browsers verschiedene Speichertypen verwenden und alle gespeicherten Daten ganz einfach löschen.

In Chrome 88 wurde eine neue Funktion hinzugefügt, mit der sich der Speicherplatz der Website Kontingent im Speicherbereich. Mit dieser Funktion können Sie auf verschiedenen Geräten testen und das Verhalten Ihrer Apps bei geringer Laufwerksverfügbarkeit testen Szenarien durchführen. Gehen Sie zu Anwendung und dann zu Speicher und aktivieren Sie die Benutzerdefiniertes Speicherkontingent simulieren und geben Sie eine gültige Zahl ein, um das Speicherkontingent simulieren.

Während der Arbeit an diesem Artikel habe ich ein einfaches Tool geschrieben, mit dem Sie so viel Speicherplatz wie möglich zu nutzen. So können Sie schnell und einfach verschiedene Speichermechanismen zu experimentieren und zu sehen, was passiert, damit Ihr gesamtes Kontingent ausgeschöpft wird.

Wie gehen Sie bei Überschreitung des Kontingents vor?

Was sollten Sie tun, wenn Sie Ihr Kontingent überschreiten? Am wichtigsten ist, Fehler immer abfangen und verarbeiten, unabhängig davon, ob es sich um QuotaExceededError- oder irgendetwas anderes. Entscheiden Sie dann je nach App-Design, wie Sie damit umgehen möchten. Löschen Sie beispielsweise Inhalte, auf die lange nicht mehr zugegriffen wurde, entfernen Sie oder den Nutzern die Möglichkeit bieten, auszuwählen, was sie löschen möchten.

Sowohl IndexedDB als auch die Cache API lösen eine DOMError namens QuotaExceededError, wenn Sie das verfügbare Kontingent überschritten haben.

IndexedDB

Wenn der Ursprung sein Kontingent überschritten hat, werden Versuche, in IndexedDB zu schreiben, scheitern. Der onabort()-Handler der Transaktion wird aufgerufen und übergibt ein Ereignis. Das Ereignis enthält im Fehlerattribut einen DOMException. Überprüfen der Der Fehler name gibt QuotaExceededError zurück.

const transaction = idb.transaction(['entries'], 'readwrite');
transaction.onabort = function(event) {
  const error = event.target.error; // DOMException
  if (error.name == 'QuotaExceededError') {
    // Fallback code goes here
  }
};

Cache-API

Wenn der Ursprung sein Kontingent überschritten hat, wird versucht, in die Cache API zu schreiben wird mit einer QuotaExceededError-DOMException abgelehnt.

try {
  const cache = await caches.open('my-cache');
  await cache.add(new Request('/sample1.jpg'));
} catch (err) {
  if (error.name === 'QuotaExceededError') {
    // Fallback code goes here
  }
}

Wie funktioniert die Bereinigung?

Webspeicher wird in zwei Kategorien eingeteilt: „Bester Aufwand“. und „Persistent“. Das bedeutet, dass der Speicher vom Browser ohne Nutzer stören, aber für langfristige oder kritische Daten ist sie weniger robust. Nichtflüchtiger Speicher wird nicht automatisch gelöscht, wenn nur noch wenig Speicherplatz verfügbar ist. Der Nutzer muss diesen Speicher manuell über die Browsereinstellungen löschen.

Standardmäßig werden die Daten einer Website (einschließlich IndexedDB, Cache API usw.) in "Best-Effort-Kategorie", d. h. es sei denn, eine Website hat dauerhaften Speicher angefordert, entfernt der Browser möglicherweise Websitedaten nach eigenem Ermessen zu speichern, z. B. bei wenig Speicherplatz auf dem Gerät.

Die Bereinigungsrichtlinie für bestmögliche Ergebnisse lautet:

• Chromium-basierte Browser beginnen mit dem Entfernen von Daten, sobald der Browser aufgebraucht ist zuerst alle Websitedaten vom am wenigsten verwendeten Ursprung gelöscht, und die nächste, bis der Browser die Begrenzung nicht mehr überschreitet.
• Internet Explorer 10+ entfernt keine Daten, verhindert aber, dass der Ursprung nicht mehr schreibe.
• Firefox beginnt, Daten zu entfernen, sobald der verfügbare Speicherplatz voll ist. Löschen aller Websitedaten aus dem am wenigsten verwendeten Ursprung, dann bis der Browser das Limit nicht mehr überschreitet.
• Safari hat zuvor keine Daten entfernt, aber kürzlich wurde eine neue 7-Tage-Grenze für den gesamten beschreibbaren Speicher (siehe unten).

Ab iOS und iPadOS 13.4 bzw. Safari 13.1 unter macOS wird eine 7-Tage-Grenze für den gesamten skriptschreibbaren Speicher, einschließlich IndexedDB, die Worker-Registrierung und die Cache API. Das bedeutet, dass Safari alle Inhalte aus dem Cache nach sieben Tagen Safari löschen. mit der Website interagieren. Diese Bereinigungsrichtlinie gilt nicht für installierte Apps PWAs, die dem Startbildschirm hinzugefügt wurden. Weitere Informationen finden Sie unter Vollständige Blockierung von Drittanbieter-Cookies und mehr im WebKit .

Bonus: Welche Vorteile bietet ein Wrapper für IndexedDB?

IndexedDB ist eine Low-Level-API, die vor der Verwendung umfassend eingerichtet werden muss. was beim Speichern einfacher Daten besonders mühsam sein kann. Im Gegensatz zu den meisten modernen Promise-basierten APIs ist ereignisbasiert. Promise-Wrapper wie Mit idb für IndexedDB werden einige der leistungsstarken Funktionen ausgeblendet, aber mehr Vor allem komplexe Maschinen (z.B. Transaktionen, Schemaversionsverwaltung) verbergen der in der IndexedDB-Bibliothek enthalten ist.

Fazit

Die Zeiten des begrenzten Speicherplatzes und der Aufforderung, mehr zu speichern, mehr Daten. Websites können alle Ressourcen und Daten, die sie ausgeführt werden müssen. Mit der StorageManager API können Sie wie viel Ihnen zur Verfügung steht und wie viel Sie verwendet haben. Und mit Nichtflüchtigen Speicher zu löschen. Wenn der Nutzer sie nicht entfernt, vor der Zwangsräumung schützen.

Zusätzliche Ressourcen

• Best Practices für IndexedDB
• Konzepte für Chrome Web-Speicherplatz und -Kontingente

Vielen Dank

Besonderer Dank geht an Jarryd Goodman, Phil Walton, Eiji Kitamura, Daniel Murphy, Darwin Huang, Josh Bell, Marijn Kruisselbrink und Victor Costan für die Rezension diesem Artikel. Danke an Eiji Kitamura, Addy Osmani und Marc Cohen, den ursprünglichen Artikeln, auf denen sie basiert. Eiji hat ein hilfreiches Tool Browser Storage Abuser aufgerufen, der bei der Validierung aktuelle Verhalten. Damit können Sie so viele Daten wie möglich speichern Speicherlimits in Ihrem Browser. Danke an Francois Beaufort, der in Safari, um die Speicherlimits zu ermitteln.

Das Hero-Image stammt von Guillaume Bolduc Unsplash: