Speicher für das Web

Es gibt viele verschiedene Möglichkeiten, Daten im Browser zu speichern. Welches ist am besten für Ihre Bedürfnisse?

27. April 2020
Aktualisiert 7. Mai 2020

Internetverbindungen können unterwegs fehlerhaft oder nicht vorhanden sein, sodass Offline-Unterstützung und zuverlässige Leistung in progressiven Webanwendungen häufig vorkommen. Selbst in perfekten drahtlosen Umgebungen kann die umsichtige Verwendung von Caching und anderen Speichertechniken die Benutzererfahrung erheblich verbessern. Es gibt verschiedene Möglichkeiten, statische Anwendungsressourcen (HTML, JavaScript, CSS, Bilder usw.) und Daten (Benutzerdaten, Nachrichtenartikel usw.) zwischenzuspeichern. Aber was ist die beste Lösung? Wie viel können Sie speichern? Wie verhindern Sie, dass er vertrieben wird?

Was soll ich anziehen?

Hier ist eine allgemeine Empfehlung zum Speichern von Ressourcen:

IndexedDB und die Caching-API sind mit allen modernen Browsern kompatibel. Sie sind beide asynchron und blockieren den Hauptthread nicht. Sie sind von der zugänglich Fenster Objekt-, Web- und Servicemitarbeiter, sodass sie überall in Ihrem Code einfach verwendet werden können.

Was ist mit anderen Speichermechanismen?

Im Browser stehen mehrere andere Speichermechanismen zur Verfügung, die jedoch nur begrenzt von Nutzen sind und erhebliche Leistungsprobleme verursachen können.

Sitzungsspeicher ist wimpernspezifisch und auf das Leben der Wimpern zugeschnitten. Dies kann nützlich sein, um kleine Mengen sitzungsspezifischer Informationen zu speichern, z. B. einen IndexedDB-Schlüssel. Es sollte mit Vorsicht verwendet werden, da es synchron ist und den Haupt-Thread blockiert. Es ist auf ca. 5 MB begrenzt und kann nur Zeichenfolgen enthalten. Da es sich um eine Registerkarte handelt, können Web- oder Servicemitarbeiter nicht darauf zugreifen.

Lokaler Speicher sollte vermieden werden, da es synchron ist und den Haupt-Thread blockiert. Es ist auf ca. 5 MB begrenzt und kann nur Zeichenfolgen enthalten. Auf LocalStorage können Web- oder Servicemitarbeiter nicht zugreifen.

Kekse Sie haben ihre Verwendung, sollten aber nicht zur Aufbewahrung verwendet werden. Cookies werden mit jeder HTTP-Anfrage gesendet. Wenn Sie also mehr als eine kleine Datenmenge speichern, wird die Größe jeder Webanforderung erheblich erhöht. Sie sind synchron und können von Web-Workern nicht aufgerufen werden. Wie LocalStorage und SessionStorage sind Cookies nur auf Zeichenfolgen beschränkt.

das Dateisystem-API und die FileWriter-API bieten Methoden zum Lesen und Schreiben von Dateien in ein Sandbox-Dateisystem. Es ist zwar asynchron, wird jedoch nicht empfohlen, da dies der Fall ist
Nur in Chromium-basierten Browsern verfügbar.

Die Dateisystemzugriffs-API wurde entwickelt, um Benutzern das Lesen und Bearbeiten von Dateien in ihrem lokalen Dateisystem zu erleichtern. Der Benutzer muss die Berechtigung erteilen, bevor eine Seite eine lokale Datei lesen oder schreiben kann. Die Berechtigungen werden zwischen den Sitzungen nicht beibehalten.

WebSQL sollte nein verwendet werden, und die vorhandene Verwendung muss nach IndexedDB migriert werden. Die Unterstützung hat wurde gelöscht von fast allen gängigen Browsern. Der W3C Die Pflege der Web SQL-Spezifikation wurde beendet im Jahr 2010, ohne zusätzliche Upgrade-Pläne geplant.

Der Anwendungscache muss nein Die vorhandene Verwendung muss auf die Servicemitarbeiter und die Cache-API migriert werden. Ist gewesen
obsolet und die Kompatibilität wird in Zukunft aus den Browsern entfernt.

Wie viel kann ich speichern?

Bald, vielmindestens ein paar hundert Megabyte und möglicherweise Hunderte von Gigabyte oder mehr. Browser-Implementierungen variieren, aber die Menge des verfügbaren Speichers hängt im Allgemeinen von der Menge des auf dem Gerät verfügbaren Speichers ab.

• Mit Chrome kann der Browser bis zu 80% des gesamten Speicherplatzes verwenden. Eine Quelle kann bis zu 60% des gesamten Speicherplatzes verwenden. Mit der StorageManager-API können Sie das maximal verfügbare Kontingent ermitteln. Andere Chromium-basierte Browser ermöglichen es dem Browser möglicherweise, mehr Speicherplatz zu verwenden. Weitere Informationen zur Chrome-Bereitstellung finden Sie in PR # 3896.
• Internet Explorer 10 und neuere Versionen können bis zu 250 MB speichern und benachrichtigen den Benutzer, wenn mehr als 10 MB verwendet wurden.
• Mit Firefox kann der Browser bis zu 50% freien Speicherplatz verwenden. EIN
  eTLD + 1
  Gruppe (zum Beispiel, example.com, www.example.com y foo.bar.example.com)
  kann bis zu 2 GB verwenden. Mithilfe der StorageManager-API können Sie ermitteln, wie viel Speicherplatz verfügbar ist.
• Safari (sowohl Desktop als auch Mobile) scheint bis zu 1 GB zuzulassen. Wenn das Limit erreicht ist, fordert Safari den Benutzer auf, das Limit in Schritten von 200 MB zu erhöhen. Ich konnte keine offizielle Dokumentation dazu finden.

In der Vergangenheit hat der Browser den Benutzer um Erlaubnis gebeten, weitere Daten zu verwenden, wenn eine Site einen bestimmten Schwellenwert für gespeicherte Daten überschreitet. Wenn die Quelle beispielsweise mehr als 50 MB verwendet hat, fordert der Browser den Benutzer auf, das Speichern von bis zu 100 MB zuzulassen, und fragt dann erneut in Schritten von 50 MB.

Heutzutage werden die meisten modernen Browser den Benutzer nicht warnen und es einer Site ermöglichen, bis zu ihrem zugewiesenen Kontingent zu verwenden. Die Ausnahme scheint Safari zu sein, das 750 MB anfordert und die Erlaubnis zum Speichern von bis zu 1,1 GB anfordert. Wenn eine Quelle versucht, mehr als das zugewiesene Kontingent zu verwenden, schlagen nachfolgende Versuche, Daten zu schreiben, fehl.

Wie kann ich den verfügbaren Speicherplatz überprüfen?

Im viele Browser, du kannst den ... benutzen
StorageManager-API um festzustellen, wie viel Speicher für die Quelle verfügbar ist und wie viel Speicher sie verwendet. Gibt die Gesamtzahl der von IndexedDB und der Cache-API verwendeten Bytes an und berechnet den ungefähren verbleibenden verfügbaren Speicherplatz.

if ( Navigator . Speicher && Navigator . Speicher . Schätzung ) {
 const quota = warte auf Navigator . Lagerung . Schätzung ( ) ;
 const ProzentsatzUsed = ( Kontingent . Nutzung / Kontingent . Kontingent ) * 100 ;
 Konsole . log ( 'Sie haben $ verwendet} {Prozentsatz % des verfügbaren Speichers verwendet` .);
 const verbleibend = Kontingent . Quote - Quote . Nutzung ;
 Konsole . log ( 'Sie können bis zu $ {} weitere Bytes schreiben `.);
 }}

StorageManager ist nicht implementiert in allen Browsern noch, so dass Sie es erkennen müssen, bevor Sie es verwenden. Selbst wenn es verfügbar ist, sollte es Kontingentfehler abfangen (siehe unten). In einigen Fällen kann das verfügbare Kontingent die tatsächlich verfügbare Speichermenge überschreiten.

Inspizieren

Während der Entwicklung können Sie die DevTools Ihres Browsers verwenden, um die verschiedenen Speichertypen zu überprüfen und alle gespeicherten Daten einfach zu löschen.

Während ich an diesem Artikel arbeitete, schrieb ich eine einfaches Werkzeug um schnell zu versuchen, so viel Speicher wie möglich zu verwenden. Auf diese Weise können Sie schnell und einfach mit verschiedenen Speichermechanismen experimentieren und sehen, was passiert, wenn Sie Ihr gesamtes Kontingent verbrauchen.

Wie gehe ich mit dem Kontingentüberschuss um?

Was sollten Sie tun, wenn Sie das Kontingent überschreiten? Am wichtigsten ist, dass Sie immer Tippfehler erkennen und behandeln, sei es QuotaExceededError oder etwas anderes. Entscheiden Sie dann je nach Design Ihrer Anwendung, wie Sie damit umgehen möchten. Löschen Sie beispielsweise Inhalte, auf die seit langem nicht mehr zugegriffen wurde, löschen Sie Daten basierend auf der Größe oder bieten Sie Benutzern die Möglichkeit, auszuwählen, was sie löschen möchten.

Sowohl IndexedDB als auch Cache API geben a zurück DOMError namens
QuotaExceededError wenn Sie das verfügbare Kontingent überschritten haben.

IndexedDB

Wenn der Ursprung sein Kontingent überschritten hat, schlagen Versuche, in IndexedDB zu schreiben, fehl. Die Transaktion onabort () Der Handler wird aufgerufen und übergibt ein Ereignis. Die Veranstaltung wird a DOME-Ausnahme in der Fehlereigenschaft. Überprüfen Sie den Fehler Süßkartoffel Um zu zurückkehren QuotaExceededError.

const transaction = idb . Transaktion ( [ 'Einträge' ] , 'Lesen' ) ;
 Transaktion . onabort = Funktion ( Ereignis ) {
 const error = Ereignis . Ziel . Fehler ;
 if ( error . name == 'QuotaExceededError' ) {
 }}
 } ;

Cache-API

Wenn der Ursprung sein Kontingent überschritten hat, werden Versuche, in die Cache-API zu schreiben, mit a abgelehnt QuotaExceededError DOME-Ausnahme.

versuche {
 const cache = warte auf Caches . open ( 'mein Cache' ) ;
 Warten Sie auf den Cache . add ( neue Anfrage ( '/sample1.jpg' ) ) ;
 } catch ( err ) {
 if ( error . name === 'QuotaExceededError' ) {
 }}
 }}

Wie funktioniert die Räumung?

Der Webspeicher fällt in zwei Kategorien: "Bester Aufwand" und "Dauerhaft". Bester Aufwand bedeutet, dass der Browser den Speicher löschen kann, ohne den Benutzer zu unterbrechen, aber für langfristige oder kritische Daten weniger haltbar ist. Permanenter Speicher wird nicht automatisch gelöscht, wenn der Speicherplatz niedrig ist. Der Benutzer muss diesen Speicher manuell löschen (über die Browsereinstellungen).

Standardmäßig befinden sich die Daten einer Site (einschließlich IndexedDB, Cache-API usw.) in der Kategorie "Best Effort". Dies bedeutet, dass es sich nicht um eine Site handelt
persistenter Speicher angefordertkann der Browser nach eigenem Ermessen Daten von der Site entfernen, beispielsweise wenn der Gerätespeicher niedrig ist.

Die bestmögliche Räumungsrichtlinie lautet:

• Chromium-basierte Browser beginnen, Daten zu entfernen, wenn der Browser nicht mehr über genügend Speicherplatz verfügt. Dabei werden zuerst alle Daten von der zuletzt verwendeten Ursprungssite und dann von der nächsten gelöscht, bis der Browser das Limit nicht mehr überschreitet.
• Internet Explorer 10+ entfernt die Daten nicht, verhindert jedoch, dass die Quelle mehr schreibt.
• Firefox beginnt mit der Räumung von Daten, wenn der verfügbare Speicherplatz voll ist, und löscht alle Daten von der zuletzt verwendeten Quellwebsite und dann von der nächsten, bis der Browser das Limit nicht mehr überschreitet.
• Safari hat zuvor keine Daten entfernt, aber kürzlich ein neues Limit von sieben Tagen für den gesamten Schreibspeicher eingeführt (siehe unten).

Ab iOS und iPadOS 13.4 und Safari 13.1 unter macOS ist der gesamte Speicher für das Schreiben von Skripten, einschließlich IndexedDB, des Service Worker-Protokolls und der Cache-API, auf sieben Tage begrenzt. Dies bedeutet, dass Safari nach sieben Tagen mit Safari den gesamten Inhalt aus dem Cache entfernt, wenn der Benutzer nicht mit der Site interagiert. Diese Räumungspolitik gilt nicht für installierte PWAs die dem Startbildschirm hinzugefügt wurden. Uhr
Vollständige Blockierung von Cookies von Drittanbietern und mehr Weitere Informationen finden Sie im WebKit-Blog.

Bonus: Warum einen Container für IndexedDB verwenden?

IndexedDB ist eine Low-Level-API, die vor der Verwendung eine umfangreiche Konfiguration erfordert, was beim Speichern einfacher Daten besonders schmerzhaft sein kann. Im Gegensatz zu den meisten modernen vielversprechenden APIs ist es ereignisbasiert. Versprechen Wrapper mögen
idb Für IndexedDB werden einige der leistungsstarken Funktionen ausgeblendet, vor allem aber die komplexe Maschinerie (z. B. Transaktionen, Schemaversionierung), die mit der IndexedDB-Bibliothek geliefert wird.

Fazit

Vorbei sind die Zeiten begrenzter Speicherung, in denen der Benutzer immer mehr Daten speichern muss. Websites können alle Ressourcen und Daten, die sie zum Funktionieren benötigen, effizient speichern. Verwendung der StorageManager-API Sie können bestimmen, wie viel Ihnen zur Verfügung steht und wie viel Sie verwendet haben. Und mit
DauerspeicherSofern der Benutzer es nicht entfernt, können Sie es vor Räumung schützen.

Zusätzliche Ressourcen

Vielen Dank

Ein besonderer Dank geht an Jarryd Goodman, Phil Walton, Eiji Kitamura, Daniel Murphy, Darwin Huang, Josh Bell, Marijn Kruisselbrink und Victor Costan für die Durchsicht dieses Artikels. Vielen Dank an Eiji Kitamura, Addy Osmani und Marc Cohen, die die Originalartikel geschrieben haben, auf denen sie basieren. Eiji hat ein nützliches Tool namens geschrieben Browser-Speicher-Missbraucher Dies war nützlich, um das aktuelle Verhalten zu überprüfen. Sie können so viele Daten wie möglich speichern und die Speicherbeschränkungen in Ihrem Browser anzeigen. Vielen Dank an Francois Beaufort, der Safari untersucht hat, um die Speichergrenzen herauszufinden.

Das Bild des Helden stammt von Guillaume Bolduc in
Unsplash.