Get best of the week

Webspeicher



Guten Tag, Freunde.

Ich präsentiere Ihnen die Übersetzung des Artikels „Storage for the Web“ von Pete LePage.

Es gibt verschiedene Technologien zum Speichern von Daten in einem Browser. Welches ist besser?

Eine Internetverbindung kann an bestimmten Stellen schlecht sein oder sogar fehlen. Daher ist die Offline-Unterstützung eines der Hauptmerkmale progressiver Webanwendungen . Selbst bei einer Hochgeschwindigkeitsverbindung ist es ratsam, Caching und andere Techniken zu verwenden, um die Benutzererfahrung zu verbessern. Es gibt verschiedene Möglichkeiten, Dateien (HTML, JavaScript, CSS, Bilder usw.) und Daten (Benutzerdaten, Nachrichtenartikel usw.) zu speichern. Aber welche Lösung ist besser zu wählen? Und wie kann man seine Haltbarkeit sicherstellen?

Was ist zu verwenden?


Ich kann folgendes raten:


IndexedDB und Cache API werden von allen modernen Browsern unterstützt. Sie sind asynchron, d.h. Blockieren Sie nicht den Hauptthread (Codeausführung). Sie sind im Fensterobjekt, bei Web- und Servicemitarbeitern verfügbar. Mit anderen Worten, sie können überall verwendet werden.

Was ist mit anderen Mechanismen?


Es gibt auch andere Speichermechanismen im Browser, die jedoch bestimmte Einschränkungen aufweisen und zu Leistungsproblemen führen können.


?


Mindestens einige hundert Megabyte, möglicherweise Hunderte von Gigabyte. Dies hängt vom Browser ab. Die Größe des Speichers hängt jedoch normalerweise von der Menge des verfügbaren Speichers auf dem Gerät des Benutzers ab.

  • Mit Chrome können Sie bis zu 60% des Speicherplatzes nutzen. Sie können die StorageManager-API verwenden, um das Limit (Kontingent) zu bestimmen.
  • Internet Explorer 10 und höher kann bis zu 250 MB Daten speichern.
  • Mit Firefox können Sie bis zu 2 GB Daten speichern. Sie können die StorageManager-API verwenden, um das Limit zu bestimmen.
  • Mit Safari (sowohl Desktop als auch Mobile) können Sie bis zu 1 GB Daten speichern. Bei Erreichen des Grenzwerts bittet Safari den Benutzer um Erlaubnis, das Kontingent um 200 MB zu erhöhen.

In der Vergangenheit, als das Speicherlimit erreicht wurde, forderten die Browser die Benutzererlaubnis an, um die Speichermenge zu erhöhen. Wenn beispielsweise ein Limit von 50 MB erreicht wurde, bat der Browser den Benutzer um die Erlaubnis, das Kontingent auf 100 MB und damit alle 50 MB zu erhöhen.

Heutzutage tun dies die meisten Browser nicht und erhöhen automatisch den Speicherplatz innerhalb des Kontingents. Die Ausnahme ist Safari, das bei Erreichen von 750 MB um die Erlaubnis des Benutzers bittet, das Limit auf 1,1 GB zu erhöhen. Ein Versuch, das Kontingent zu überschreiten, schlägt fehl.

Wie überprüfe ich den Saldo des Limits?


Zu diesem Zweck können Sie in vielen Browsern die StorageManager-API verwenden. Es zeigt die Gesamtzahl der von IndexedDB und der Cache-API verwendeten Bytes an, sodass Sie den Rest berechnen können.

if(navigator.storage && navigator.storage.estimate) {
  const quota = await navigator.storage.estimate()
  // quota.usage ->   
  // quota.quota ->   
  const percentageUsed = (quota.usage / quota.quota) * 100
  console.log(`  ${ percentageUsed}% `)
  const remaining = quota.quota - quota.usage
  console.log(`   ${remaining} `)
}

Bitte beachten Sie, dass die StorageManager-API noch nicht von allen Browsern unterstützt wird. Selbst wenn dies unterstützt wird, muss ein Fehlerbehandler bereitgestellt werden. In einigen Fällen kann das Kontingent die tatsächliche Speicherkapazität überschreiten.

Inspektion


Während der Entwicklung können Sie mithilfe von Browser-Tools den Status verschiedener Repositorys verfolgen und bereinigen.



Während ich an diesem Artikel arbeitete, schrieb ich dieses einfache Tool zum schnellen Testen der Speicherfunktionen. Dies ist eine schnelle und einfache Möglichkeit, mit verschiedenen Datenspeicherungsmechanismen zu experimentieren und festzustellen, was passiert, wenn das Kontingent überschritten wird.

Wie gehe ich mit Fehlern um?


Was tun, wenn das Limit erreicht ist? Behandeln Sie natürlich Fehler, sei es QuotaExceededError oder etwas anderes. Abhängig vom Design Ihrer Anwendung sollten Sie dann die Art und Weise auswählen, in der sie verarbeitet werden. Sie können beispielsweise alte Inhalte oder Daten abhängig von ihrer Größe löschen oder dem Benutzer die Möglichkeit geben, zu entscheiden, was gelöscht werden soll.

IndexedDB und die Cache-API lösen einen DOMError QuotaExceededError aus, wenn ein Kontingent überschritten wird.

Indexeddb


Wenn das Limit erreicht ist, schlägt ein Versuch fehl, Daten in IndexedDB zu schreiben. Die onabort () -Methode wird mit dem Ereignis als Argument aufgerufen. Das Ereignis enthält eine DOMException in der Fehlereigenschaft. Wenn Sie den Fehlernamen überprüfen, wird ein QuotaExceededError zurückgegeben.

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

Cache-API


Ein Versuch, Daten in die Cache-API zu schreiben, wenn das Limit erreicht ist, wird mit einer QuotaExceededError DOMException abgelehnt.

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

Wie funktioniert die Speicherbereinigung?


Web-Repositorys lassen sich in zwei Kategorien einteilen: "eigenständig" und "verwaltet". Standalone bedeutet, dass das Repository vom Benutzer ohne Benutzereingriff gelöscht werden kann, jedoch weniger anpassbar für eine längere Verwendung sowie bei Vorhandensein kritischer Daten ist. Verwaltete Tresore werden nicht automatisch gereinigt, wenn sie voll sind. Der Benutzer muss solche Speicher manuell löschen (über die Browsereinstellungen).

Standardmäßig werden Webspeicher (IndexedDB, Cache-API usw.) als eigenständig klassifiziert. Wenn keine manuelle Steuerung installiert ist , kann der Browser den Speicher unter bestimmten Bedingungen, z. B. beim Befüllen, unabhängig löschen.

Die Bedingungen für die Reinigung des Lagers sind wie folgt:

  • Wenn der Speicher voll ist, löscht Chrome Daten, beginnend mit der am wenigsten angeforderten (der ältesten Nutzungsdauer), bis das Überlaufproblem behoben ist.
  • IE 10+ löscht den Speicher nicht, blockiert jedoch die Fähigkeit, Daten zu schreiben.
  • Firefox macht dasselbe wie Chrome.
  • Safari hat den Tresor zuvor nicht gelöscht, aber kürzlich wurde eine Aufbewahrungsfrist von sieben Tagen hinzugefügt.

Ab iOS und iPad 13.4, Safari 13.1 unter macOS gilt eine Aufbewahrungsfrist von sieben Tagen. Dies bedeutet, dass der Benutzer gelöscht wird, wenn er nicht innerhalb von sieben Tagen auf die Daten zugreift. Diese Richtlinie gilt nicht für Anwendungen, die dem Startbildschirm hinzugefügt wurden.

Bonus: Promise Wrap Over IndexedDB


IndexedDB ist eine Low-Level-API, für deren Verwendung einige Konfigurationen erforderlich sind. Dies ist möglicherweise nicht erforderlich, wenn Sie einfache Daten speichern müssen. Im Gegensatz zu den meisten modernen Promise-basierten APIs ist es ereignisbasiert. Ein Wrapper aus Versprechungen wie idb verbirgt einige leistungsstarke Funktionen dieses Repositorys, vor allem aber auch seine komplexen internen Mechanismen (Transaktionen, Versionierung).

Fazit


Zeiten begrenzter Speicher- und Benutzerberechtigungsanforderungen zur Erhöhung des Limits sind in Vergessenheit geraten. Websites können effektiv alle Ressourcen und Daten speichern, die sie zum Arbeiten benötigen. Mit der StorageManager-API können Sie bestimmen, wie viel Speicher verwendet wird und wie viel noch übrig ist. Wenn Sie den Speicher in den manuellen Steuermodus versetzen, können Sie Daten vor dem Löschen schützen.

Hinweis per .:

  • Hier können Sie sehen, wie Sie mit idb eine Anwendung für Notizen schreiben.
  • Hier können Sie sehen, wie Servicemitarbeiter arbeiten.

Vielen Dank für Ihre Zeit. Ich hoffe es wurde gut angelegt.

More articles:


All Articles