Cache Storage API pour les applications hors connexion
Conception respectueuse de la vie privée pour Cache Storage API, avec requêtes, versions, repli hors connexion et nettoyage.
Vous voulez la documentation structurée pour Identité ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Cache Storage API fournit à une application web hors connexion un espace nommé pour les objets Request et Response. Un Service Worker peut ouvrir un cache, rechercher une requête et renvoyer une réponse enregistrée quand le réseau est indisponible. L’API ne décide pas quelles ressources conserver, quand elles sont fraîches ni quel compte peut les lire : ces décisions relèvent de l’application.
Le mode hors connexion est donc un problème de stockage autant qu’un problème de Service Worker. Une conception fiable nomme chaque cache, versionne les ressources lors d’une nouvelle publication, définit un repli pour chaque catégorie de requête et propose une suppression prévisible. La spécification Service Workers décrit le cycle de vie et la référence MDN de Cache décrit les méthodes et la correspondance.
Ce que possède Cache Storage
caches est l’objet CacheStorage disponible dans un worker et, lorsque c’est autorisé, dans une fenêtre. caches.open('app-shell-v3') crée ou ouvre un Cache; cache.put(request, response) enregistre une réponse; cache.match(request) recherche une entrée; et caches.delete('app-shell-v2') supprime un cache nommé. Le navigateur associe ces données à l’origine et au profil ou contexte concerné. Un nom de cache est un espace de noms applicatif, pas une frontière de sécurité entre du code du même domaine.
L’API conserve des objets web : HTML, JavaScript, CSS, images ou JSON, ainsi que des en-têtes qui influencent parfois l’interprétation du corps. Ne stockez que les réponses dont le but, la durée et le responsable sont compris. Une réponse contenant un jeton de session, des données de compte ou une décision d’autorisation temporaire doit être traitée comme un état applicatif, pas comme une ressource hors connexion ordinaire.
Cache Storage est distinct du cache HTTP, des cookies, de localStorage, d’IndexedDB et des enregistrements de Service Worker. Vider un stockage ne vide pas les autres. Une revue de déconnexion doit les lister et tester chaque nettoyage. La réussite de cache.delete() prouve la disparition d’un cache nommé, pas celle des cookies ou des enregistrements IndexedDB. Consultez le modèle de stockage du navigateur et le partitionnement du stockage pour distinguer ces frontières.
Le navigateur peut évincer des données sous pression de stockage et la personne peut les effacer dans ses réglages. L’éviction est une sécurité d’espace, non un processus de publication ni une garantie de confidentialité. Une application doit pouvoir télécharger à nouveau une réponse et fonctionner avec un cache vide. Lorsque plusieurs fonctions partagent une origine, utilisez des préfixes distincts et limitez la suppression aux noms possédés par la fonction active.
Faire correspondre les requêtes sans surprise
Cache.match() compare une requête aux entrées conservées selon les règles de la plateforme. Ce n’est ni une recherche générale dans les corps ni une permission de répéter chaque méthode. Classez les requêtes afin que la politique du worker reste lisible.
Les fichiers statiques associés à une version, comme un paquet JavaScript, conviennent à cache-first : le worker consulte le cache versionné, puis télécharge et stocke l’élément absent. Pour une navigation ou des données qui doivent refléter le serveur, network-first est souvent préférable : tenter le réseau, mettre à jour avec une réponse valide et n’utiliser l’ancienne réponse qu’en cas d’échec.
Ne stockez pas automatiquement chaque réponse réussie. Un POST qui crée une commande ou modifie un profil ne devient pas répétable sans risque parce que sa réponse est dans Cache Storage. Une réponse personnalisée par une autorisation, un cookie ou un compte exige une politique explicite. Dans de nombreux produits, le repli le plus sûr affiche une indisponibilité claire et demande une reconnexion.
Les paramètres, en-têtes, méthodes et modes de cache peuvent modifier la correspondance. Si la représentation dépend d’un en-tête, intégrez cette dimension à la clé ou évitez un cache partagé. Une URL peut avoir plusieurs représentations valides; restituer la mauvaise est une erreur de fonctionnement. Documentez la catégorie de requête, le cache, la fraîcheur attendue et le repli.
Un repli de navigation doit indiquer si les données sont actuelles. Le worker peut renvoyer une coquille d’application, mais l’interface doit signaler le mode hors connexion et proposer une nouvelle tentative; elle ne doit pas présenter un ancien tableau de bord comme une réponse serveur actuelle. Examinez séparément les réponses opaques et les ressources d’autres origines, sans utiliser Cache Storage pour inspecter du contenu privé.
Versions et mises à jour
Considérez le nom du cache comme un contrat de publication, par exemple offline-shell-v7. Pendant install, créez et remplissez le nouveau cache; pendant activate, listez les noms de la fonction puis supprimez les anciennes versions. Un nouveau worker peut rester en attente pendant qu’un autre contrôle des pages ouvertes; consultez le cycle de vie MDN.
Si une ressource obligatoire échoue, refusez l’installation plutôt que d’activer une version partielle. Les ressources facultatives peuvent avoir un cache et une nouvelle tentative distincts. Le nettoyage d’activation doit conserver la version courante et supprimer uniquement le préfixe de la fonction. Notez la version, les noms avant et après, et la présence éventuelle d’un worker en attente.
skipWaiting() et clients.claim() avancent le moment où le nouveau worker sert des pages, mais un ancien onglet peut recevoir des réponses préparées pour un contrat nouveau. Utilisez-les seulement après un test de compatibilité; sinon laissez le worker attendre et demandez un rechargement à une frontière claire. Préférez des URL avec empreinte de contenu ou version de publication pour éviter de remplacer des octets sans changer le nom du cache.
Repli et récupération hors connexion
Définissez un résultat pour la coquille, la navigation, l’image, la police, la lecture d’API et l’écriture. Une ancienne lecture peut afficher son âge et un bouton d’actualisation. Une écriture ne doit être mise en file que si elle est idempotente ou possède une clé d’idempotence et un état de nouvelle tentative visible. Cache Storage ne fournit ni file persistante ni résolution de conflit.
Distinguez une absence de cache d’une erreur conservée. Ne stockez ni un 500 temporaire ni une redirection d’authentification comme page hors connexion. Vérifiez le statut et le type de contenu avant cache.put(). Sans repli, renvoyez un document court et contrôlé qui indique l’action suivante.
Après une nouvelle tentative réussie, remplacez l’ancienne réponse seulement si la nouvelle passe les mêmes validations. Gardez les brouillons hors connexion dans un stockage applicatif approprié et affichez la dernière synchronisation; ne cachez pas une écriture en attente dans une entrée qu’une publication peut supprimer. Testez les contextes froid, chaud et dégradé, et consignez état du worker, noms, catégorie, source et résultat sans conserver de jetons ni de corps.
Nettoyage, déconnexion et contrôle de l’utilisateur
La suppression est une fonction. Prévoyez une opération pour les caches de publication obsolètes et une autre pour les comptes ou brouillons, afin qu’une publication ne supprime pas le travail hors connexion et qu’une déconnexion ne laisse pas de données de compte dans la coquille. Lors d’une déconnexion ou d’un changement de compte, terminez la session serveur, demandez au worker de supprimer les caches du compte, effacez l’état mémoire et avertissez les autres onglets. Testez deux onglets ouverts.
Clear-Site-Data peut demander l’effacement de catégories de données, mais sa couverture dépend du navigateur et ne remplace pas le nettoyage applicatif. Cache-Control décrit le cache HTTP; il n’empêche pas un worker d’appeler cache.put(). Le code qui écrit dans Cache Storage doit appliquer la politique avant l’enregistrement.
Minimisez les données : gardez seulement la réponse nécessaire à l’écran hors connexion, évitez les jetons dans les corps et définissez une durée pour les brouillons et médias. Le contrôle de nettoyage doit préciser s’il touche la session, le travail en file ou seulement les ressources statiques.
Tests avec BotBrowser et limites documentées
BotBrowser peut créer des contextes de navigateur reproductibles avec stockage et session isolés; une équipe peut ainsi comparer un contexte froid, chaud et déconnecté sans transporter l’état d’un contexte à l’autre. Consultez la documentation d’isolation multi-compte et notez l’état du worker, les noms de cache et le repli visible. BotBrowser prend en charge des contextes isolés pour ces contrôles, mais BotBrowser ne peut pas écrire, versionner, purger ni interpréter les entrées Cache Storage, ni garantir l’éviction du navigateur, la disponibilité hors connexion ou la justesse de la stratégie Service Worker; l’application garde la responsabilité du cache et du nettoyage.
Utilisez un contexte sans cache, un contexte après installation et un contexte après mise à jour. Chargez une coquille connue, interrompez le réseau dans la limite autorisée, vérifiez le marquage hors connexion, puis restaurez-le et vérifiez qu’une réponse validée remplace l’ancienne. Répétez la déconnexion et le changement de compte avec deux contextes et deux onglets. Comparez les noms et l’état du worker, jamais les corps privés.
Les preuves BotBrowser doivent rester limitées à l’isolement, à la navigation, à l’état exposé du worker et aux assertions de la liste de caches de l’application. Une comparaison réussie ne prouve pas l’éviction de tous les navigateurs, la justesse en production ou la répétition sûre d’une écriture; ces affirmations demandent des tests applicatifs, une couverture par navigateur et une décision explicite.
Chaque nom de cache doit indiquer sa fonction et sa version.
L’installation doit refuser une ressource obligatoire manquante.
Les ressources facultatives doivent avoir une nouvelle tentative distincte.
L’activation ne peut supprimer que le préfixe de sa fonction.
Une réponse conservée ne prouve pas que le réseau a été utilisé.
Un repli visible doit expliquer quand une nouvelle tentative est possible.
Une réponse de compte n’est pas une ressource publique de la coquille.
Deux onglets doivent recevoir le signal d’un changement de compte.
Le nettoyage d’une version ne doit pas supprimer un brouillon.
Un contexte neuf sépare l’état précédent.
Les journaux de test doivent exclure les jetons et corps privés.
Sources publiques
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.