Il existe de nombreuses options différentes pour stocker des données dans le navigateur. Quel est le meilleur pour vos besoins?
Mise à jour
Les connexions Internet peuvent être défectueuses ou inexistantes lors de vos déplacements, c'est pourquoi la prise en charge hors ligne et des performances fiables sont des fonctionnalités courantes dans les applications Web progressives. Même dans des environnements sans fil parfaits, une utilisation judicieuse de la mise en cache et d'autres techniques de stockage peut considérablement améliorer l'expérience utilisateur. Il existe plusieurs façons de mettre en cache les ressources statiques de l'application (HTML, JavaScript, CSS, images, etc.) et les données (données utilisateur, articles d'actualité, etc.). Mais quelle est la meilleure solution ? Combien pouvez-vous stocker ? Comment l'empêcher d'être expulsé ?
Que dois-je utiliser ?
Voici une recommandation générale pour le stockage des ressources :
IndexedDB et l'API de mise en cache sont pris en charge par tous les navigateurs modernes. Les deux sont asynchrones et ne bloqueront pas le thread principal. Ils sont accessibles depuis 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 Ils ont leurs utilisations, mais ne doivent pas être utilisés pour le stockage. Des cookies sont envoyés avec chaque requête HTTP, donc stocker plus qu'une petite quantité de données augmentera considérablement la taille de chaque requête Web. Ils sont synchrones et ne sont pas accessibles aux web workers. Comme LocalStorage et SessionStorage, les cookies sont limités aux chaînes uniquement.
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 presque tous les principaux navigateurs. 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.comyfoo.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.
if ( navigateur . stockage && navigateur . stockage . estimation ) {
const quota = attendre le navigateur . stockage . estimation ( ) ;
const pourcentageUtilisé = ( quota . utilisation / quota . quota ) * 100 ;
consoler . log ( ` Vous avez utilisé ${ percentUsed } % du stockage disponible. ` ) ;
const restant = quota . quota - quota . utilisation ;
consoler . log ( ` Vous pouvez écrire jusqu'à ${ restant } octets de plus. ` ) ;
}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.
D'autres navigateurs basés sur Chromium peuvent prendre en compte la quantité d'espace libre lorsqu'ils signalent le quota disponible. Chrome ne signale pas et signalera toujours au 60% la taille réelle du disque. Cela permet de réduire la capacité à déterminer la taille des ressources d'origine croisée stockées.
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 ou autre chose. Ensuite, en fonction de la conception de votre application, décidez comment la gérer. Par exemple, supprimez du contenu qui n'a pas été consulté depuis longtemps, supprimez des données en fonction de leur taille ou offrez aux utilisateurs un moyen de choisir ce qu'ils souhaitent supprimer.
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 sera appelé, passant un événement. L'événement comprendra une DOMException dans la propriété d'erreur. vérification de l'erreur patate douce retourner à Erreur de dépassement de quota.
const transaction = idb . transaction ( [ 'entries' ] , 'readwrite' ) ;
transaction . onabort = fonction ( événement ) {
const erreur = événement . cible . erreur ;
si ( erreur . nom == '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.
essayer {
const cache = attendre les caches . open ( 'mon-cache' ) ;
attendre le cache . add ( nouvelle demande ( '/sample1.jpg' ) ) ;
} attrape ( erre ) {
si ( erreur . nom === '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).
À partir d'iOS et d'iPadOS 13.4 et de Safari 13.1 sur macOS, il existe une limite de sept jours sur tout le stockage d'écriture de script, y compris IndexedDB, le journal du service worker et le cache de l'API. Cela signifie que Safari expulsera tout le contenu du cache après sept jours d'utilisation de Safari si l'utilisateur n'interagit pas avec le site. Cette politique d'expulsion 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 sur le blog WebKit pour plus de détails.
Vous pouvez demander un stockage persistant pour votre site afin de protéger les applications critiques ou les données utilisateur.
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.
