Stockage pour le Web

Hay muchas opciones diferentes para almacenar datos en el le navigateur. ¿Cuál es mejor para tus necesidades?

27 avril 2020
Mise à jour 7 mai 2020

Las conexiones a Internet pueden ser defectuosas o inexistentes mientras viaja, por lo que el soporte sin conexión y el rendimiento confiable son características comunes en las aplicaciones la toile progresivas. Incluso en entornos inalámbricos perfectos, el uso prudente del almacenamiento en cache y otras técnicas de almacenamiento puede mejorar sustancialmente la experiencia del Nom d'utilisateur. Hay varias formas de almacenar en caché los recursos de la aplicación estática (HTML, JavaScript, CSS, imágenes, etc.) y los datos (datos de usuario, artículos de noticias, etc.). ¿Pero cuál es la mejor solución? ¿Cuánto puedes almacenar? ¿Cómo evitas que être desalojado?

Que dois-je utiliser ?

Voici une recommandation générale pour le stockage des ressources :

IndexedDB y la API de almacenamiento en caché son compatibles con todos los navigateurs modernos. Ambos son asincrónicos y no bloquearán el hilo principal. Son accesibles desde el la fenêtre Object, Web Workers et Service Workers, ce qui facilite son utilisation n'importe où dans votre code.

Qu'en est-il des autres mécanismes de stockage ?

Il existe plusieurs autres mécanismes de stockage disponibles dans le navigateur, mais ils sont d'une utilisation limitée et peuvent entraîner des problèmes de performances importants.

stockage des sessions il est spécifique à l'onglet et s'ajuste à la durée de vie de l'onglet. Cela peut être utile pour stocker de petites quantités d'informations spécifiques à la session, par exemple une clé IndexedDB. Il doit être utilisé avec prudence car il est synchrone et bloquera le thread principal. Il est limité à environ 5 Mo et ne peut contenir que des chaînes. Parce qu'il est spécifique à un onglet, il n'est pas accessible aux travailleurs Web ou aux travailleurs de service.

stockage local doit être évité car il est synchrone et bloquera le thread principal. Il est limité à environ 5 Mo et ne peut contenir que des chaînes. LocalStorage n'est pas accessible aux web workers ni aux service workers.

Biscuits tienen sus usos, pero no deben usarse para almacenamiento. Las cookies se envían con cada solicitud HTTP, por lo que almacenar algo más que una pequeña cantidad de datos aumentará significativamente el tamaño de cada solicitud web. Son síncronos y los trabajadores web no pueden acceder a ellos. Al igual que LocalStorage y SessionStorage, las cookies se limitan solo a cadenas.

Les API du système de fichiers et l'API FileWriter fournissent des méthodes pour lire et écrire des fichiers sur un système de fichiers en bac à sable. Bien qu'il soit asynchrone, il n'est pas recommandé car il est
disponible uniquement dans les navigateurs basés sur Chromium.

L'API d'accès au système de fichiers a été conçue pour permettre aux utilisateurs de lire et de modifier facilement des fichiers sur leur système de fichiers local. L'autorisation doit être accordée par l'utilisateur avant qu'une page puisse lire ou écrire dans des fichiers locaux, et les autorisations ne sont pas conservées d'une session à l'autre.

websql devrait non être utilisé, et l'utilisation existante doit être migrée vers IndexedDB. le soutien a a été supprimé de casi todos los principales navegadores. El W3C a cessé de maintenir la spécification Web SQL en 2010, sans autre plan de mise à niveau prévu.

Le cache de l'application doit non et l'utilisation existante doit être migrée vers les agents de service et l'API de cache. A été
obsolète et le support sera supprimé des navigateurs à l'avenir.

Combien puis-je stocker ?

Bientôt, beaucoup de, au moins quelques centaines de mégaoctets et potentiellement des centaines de gigaoctets ou plus. Les implémentations de navigateur varient, mais la quantité de stockage disponible est généralement basée sur la quantité de stockage disponible sur l'appareil.

• Chrome permet au navigateur d'utiliser jusqu'à 80% d'espace disque total. Une source peut utiliser jusqu'à 60% de l'espace disque total. Vous pouvez utiliser l'API StorageManager pour déterminer le quota maximum disponible. D'autres navigateurs basés sur Chromium peuvent permettre au navigateur d'utiliser plus de stockage. Voir PR # 3896 pour plus de détails sur l'implémentation de Chrome.
• Internet Explorer 10 et versions ultérieures peuvent stocker jusqu'à 250 Mo et avertiront l'utilisateur lorsque plus de 10 Mo ont été utilisés.
• Firefox permet au navigateur d'utiliser jusqu'à 50% d'espace disque libre. UN
  eTLD + 1
  groupe (ex. example.com, www.exemple.com y foo.bar.example.com)
  vous pouvez utiliser jusqu'à 2 Go. Vous pouvez utiliser l'API StorageManager pour déterminer la quantité d'espace disponible.
• Safari (ordinateur de bureau et mobile) semble autoriser jusqu'à 1 Go. Lorsque la limite est atteinte, Safari invite l'utilisateur à augmenter la limite par incréments de 200 Mo. Je n'ai trouvé aucune documentation officielle à ce sujet.

Dans le passé, si un site dépassait un certain seuil de données stockées, le navigateur demandait à l'utilisateur d'autoriser l'utilisation de plus de données. Par exemple, si l'origine a utilisé plus de 50 Mo, le navigateur demandera à l'utilisateur de lui permettre de stocker jusqu'à 100 Mo, puis demandera à nouveau par incréments de 50 Mo.

Aujourd'hui, la plupart des navigateurs modernes n'invitent pas l'utilisateur et autorisent un site à utiliser jusqu'à son quota alloué. L'exception semble être Safari, qui demande 750 Mo et demande l'autorisation de stocker jusqu'à 1,1 Go. Si une origine tente d'utiliser plus que son quota alloué, les tentatives suivantes d'écriture de données échoueront.

Comment puis-je vérifier la quantité de stockage disponible ?

Au de nombreux navigateurs, vous pouvez utiliser le
API du gestionnaire de stockage pour déterminer la quantité de stockage disponible à l'origine et la quantité de stockage qu'elle utilise. Indique le nombre total d'octets utilisés par IndexedDB et l'API Cache, et vous permet de calculer l'espace de stockage restant approximatif disponible.

si (navigateur.storage && navigateur.storage.estimate) {
const quota = attendre navigateur.storage.estimate();
const percentageUsed = (quota.usage / quota.quota) * 100;
console.Journal(`You've used ${percentageUsed}% of the available storage.`);
const remaining = quota.quota - quota.usage;
console.Journal(`You can write up to ${remaining} more bytes.`);
}

Le gestionnaire de stockage n'est pas mis en œuvre dans tous les navigateurs pour le moment, vous devez donc le détecter avant de l'utiliser. Même lorsqu'il est disponible, vous devez détecter les erreurs de dépassement de quota (voir ci-dessous). Dans certains cas, le quota disponible peut dépasser la quantité réelle de stockage disponible.

Inspecter

Pendant le développement, vous pouvez utiliser les DevTools de votre navigateur pour inspecter les différents types de stockage et effacer facilement toutes les données stockées.

En travaillant sur cet article, j'ai écrit un outil simple pour essayer d'utiliser rapidement autant de stockage que possible. C'est un moyen simple et rapide d'expérimenter différents mécanismes de stockage et de voir ce qui se passe lorsque vous utilisez votre quota.

Comment gérer les dépassements de quota ?

Que devez-vous faire lorsque vous dépassez le quota ? Plus important encore, vous devez toujours détecter et gérer les erreurs d'écriture, qu'elles soient Erreur de dépassement de quota o algo mas. Luego, dependiendo del diseño de su aplicación, decida cómo manejarlo. Por ejemplo, elimine el Contenu al que no se ha accedido en mucho tiempo, elimine datos según el tamaño o proporcione una forma para que los usuarios elijan lo que desean eliminar.

IndexedDB et Cache API renvoient tous deux un Erreur DOM appelé
Erreur de dépassement de quota lorsque vous avez dépassé le quota disponible.

IndexedDB

Si l'origine a dépassé son quota, les tentatives d'écriture dans IndexedDB échoueront. La transaction onabort() handler será llamado, pasando un un événement. El evento incluirá un DOMException dans la propriété d'erreur. vérification de l'erreur patate douce retourner à Erreur de dépassement de quota.

const transaction = bdi.transaction(['entries'], 'readwrite');
transaction.onabort = une fonction(un événement) {
const Erreur = un événement.cible.Erreur; 
si (Erreur.patate douce == 'QuotaExceededError') {
}
};

API de cache

Si l'origine a dépassé son quota, les tentatives d'écriture dans l'API de cache seront rejetées avec un Erreur de dépassement de quota DOMException.

try {
const cache = attendre caches.open('my-cache');
attendre cache.ajouter(new Demander('/sample1.jpg'));
} catch (err) {
si (Erreur.patate douce === 'QuotaExceededError') {
}
}

Comment fonctionne l'expulsion ?

Le stockage Web se divise en deux catégories, "Best Effort" et "Persistent". Le meilleur effort signifie que le navigateur peut effacer le stockage sans interrompre l'utilisateur, mais il est moins durable pour les données à long terme ou critiques. Le stockage persistant n'est pas automatiquement effacé lorsque le stockage est faible. L'utilisateur doit effacer manuellement ce stockage (via les paramètres du navigateur).

Par défaut, les données d'un site (y compris IndexedDB, Cache API, etc.) sont dans la catégorie des meilleurs efforts, ce qui signifie qu'à moins qu'un site n'ait
stockage persistant demandé, le navigateur peut expulser des données du site à sa discrétion, par exemple, lorsque le stockage de l'appareil est faible.

La politique d'expulsion au mieux est la suivante :

• Les navigateurs basés sur Chromium commenceront à expulser les données lorsque le navigateur manquera d'espace, effaçant d'abord toutes les données du site de l'origine la moins récemment utilisée, puis la suivante, jusqu'à ce que le navigateur ne dépasse plus la limite.
• Internet Explorer 10+ n'expulsera pas les données, mais il empêchera l'origine d'écrire plus.
• Firefox commencera à expulser les données lorsque l'espace disque disponible est plein, effaçant toutes les données du site d'origine le moins récemment utilisé, puis le suivant, jusqu'à ce que le navigateur ne dépasse plus la limite.
• Auparavant, Safari n'expulsait pas les données, mais a récemment mis en place une nouvelle limite de sept jours sur tout le stockage en écriture (voir ci-dessous).

A partir de iOS y iPadOS 13.4 y Safari 13.1 en macOS, existe un límite de siete días en todo el almacenamiento de escritura de scripts, incluido IndexedDB, el registro del trabajador del servicio y la API de caché. Esto significa que Safari desalojará todo el contenido de la caché después de siete días de uso de Safari si el usuario no interactúa con el sitio. Esta política de desalojo ne s'applique pas aux PWA installées qui ont été ajoutés à l'écran d'accueil. Regarder
Blocage complet des cookies tiers et plus dans le Blog de WebKit para obtener detalles completos.

Bonus : Pourquoi utiliser un conteneur pour IndexedDB ?

IndexedDB est une API de bas niveau qui nécessite une configuration importante avant utilisation, ce qui peut être particulièrement pénible pour stocker des données simples. Contrairement à la plupart des API modernes basées sur des promesses, elle est basée sur des événements. Des emballages de promesses comme
bdi pour IndexedDB, il masque certaines des fonctionnalités puissantes, mais plus important encore, il masque la machinerie complexe (par exemple, les transactions, la gestion des versions de schéma) fournie avec la bibliothèque IndexedDB.

conclusion

Fini le temps du stockage limité et incitant l'utilisateur à stocker de plus en plus de données. Les sites peuvent stocker efficacement toutes les ressources et données dont ils ont besoin pour fonctionner. En utilisant le API du gestionnaire de stockage vous pouvez déterminer la quantité dont vous disposez et la quantité que vous avez utilisée. Et avec
stockage persistant, à moins que l'utilisateur ne le supprime, il peut vous protéger contre l'expulsion.

ressources additionnelles

Merci

Remerciements particuliers à Jarryd Goodman, Phil Walton, Eiji Kitamura, Daniel Murphy, Darwin Huang, Josh Bell, Marijn Kruisselbrink et Victor Costan pour la révision de cet article. Merci à Eiji Kitamura, Addy Osmani et Marc Cohen, qui ont écrit les articles originaux sur lesquels il est basé. Eiji a écrit un outil utile appelé Abus de stockage du navigateur ce qui était utile pour valider le comportement actuel. Il vous permet de stocker autant de données que possible et d'afficher les limites de stockage dans votre navigateur. Merci à François Beaufort, qui a fait des recherches sur Safari pour connaître ses limites de stockage.

L'image du héros est de Guillaume Bolduc dans
Unsplash.