Tous les navigateurs imposent une limite supérieure à la quantité de stockage que l'origine de votre application Web est autorisée à utiliser. Vous pouvez configurer Workbox de sorte qu'elle nettoie automatiquement les données mises en cache au moment de l'exécution afin d'éviter les limites de quota de stockage qui peuvent affecter l'efficacité et la fiabilité de la mise en cache de votre site Web.
Quelles sont les options de configuration compatibles ?
Lorsque vous configurez une stratégie de mise en cache du routage et de l'environnement d'exécution, vous pouvez ajouter une instance de ExpirationPlugin
à partir de workbox-expiration
configurée avec les paramètres les plus adaptés au type d'éléments que vous mettez en cache.
Par exemple, la configuration suivante peut être utilisée pour la mise en cache d'images au moment de l'exécution, avec des limites explicites et un nettoyage automatique en cas de dépassement du quota:
import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';
import {ExpirationPlugin} from 'workbox-expiration';
registerRoute(
({request}) => request.destination === 'image',
// Use a cache-first strategy with the following config:
new CacheFirst({
// You need to provide a cache name when using expiration.
cacheName: 'images',
plugins: [
new ExpirationPlugin({
// Keep at most 50 entries.
maxEntries: 50,
// Don't keep any entries for more than 30 days.
maxAgeSeconds: 30 * 24 * 60 * 60,
// Automatically cleanup if quota is exceeded.
purgeOnQuotaError: true
})
]
})
);
Vous devez définir maxEntries
, maxAgeSeconds
ou les deux lorsque vous utilisez ExpirationPlugin
. purgeOnQuotaError
est facultatif.
maxEntries
Cela impose une limite supérieure au nombre d'entrées (c'est-à-dire, les URL uniques) pour un cache donné.
Cette configuration est en principe conseillée, sauf si vous savez que seul un petit nombre d'URL peuvent être gérées par une stratégie donnée.
maxAgeSeconds
Les entrées ajoutées au cache plus tôt seront considérées comme obsolètes et seront automatiquement nettoyées lors du prochain accès au cache.
Cette approche n'est pas aussi efficace que maxEntries
pour gérer les quotas de stockage, car la taille de vos caches peut augmenter de manière arbitraire tant que toutes les entrées ont été ajoutées en peu de temps. Cette approche est particulièrement utile lorsque vous savez que vous souhaitez imposer une limite maximale d'actualisation et que le fait de conserver les entrées plus anciennes n'a que peu d'intérêt pour votre application Web.
purgeOnQuotaError
Cette option vous permet de marquer un cache donné comme pouvant être supprimé automatiquement de manière sécurisée si votre application Web dépasse l'espace de stockage disponible.
Cette option est actuellement définie par défaut sur false
. Les caches d'exécution doivent généralement être résilients face à la suppression. Il est donc recommandé de définir cette option sur true
, et de garantir la récupération automatique de votre application Web en cas de contraintes de stockage.
Quelle quantité de données êtes-vous autorisé à stocker ?
Chaque navigateur possède ses propres limites de stockage. Il n'y a donc pas de réponse unique. En outre, certains navigateurs affichent une limite dynamique qui varie en fonction de l'espace de stockage disponible sur un appareil donné. La limite supérieure effective peut donc être modifiée sans préavis.
Certains navigateurs proposent une interface permettant d'interroger la quantité approximative de stockage utilisée par votre origine, ainsi que la limite supérieure, via navigator.storage.estimate()
. Pour en savoir plus sur l'utilisation de cet espace dans vos propres applications Web, consultez l'article Estimer l'espace de stockage disponible.
Remarques spéciales concernant la navigation privée dans Chrome
Lorsque vous ouvrez une application Web en mode navigation privée de Chrome, vous imposez une restriction de stockage spéciale qui ne s'applique pas aux contextes de navigation normaux: la limite de quota est d'environ 100 mégaoctets, quel que soit l'espace disponible sur votre appareil.
Méfiez-vous des réponses opaques !
Une source fréquente d'utilisation inattendue des quotas est due à la mise en cache des réponses opaques lors de l'exécution, c'est-à-dire des réponses multi-origines aux requêtes effectuées sans que le CORS soit activé.
Pour des raisons de sécurité, les navigateurs augmentent automatiquement l'impact de ces réponses opaques sur le quota. Dans Chrome, par exemple, même une réponse opaque de quelques kilo-octets finira par contribuer à environ 7 mégaoctets à votre utilisation du quota.
Une fois que vous commencez à mettre en cache des réponses opaques, vous pouvez rapidement utiliser beaucoup plus de quota que prévu. La bonne pratique consiste donc à utiliser ExpirationPlugin
avec maxEntries
, et éventuellement purgeOnQuotaError
, configurés de manière appropriée.