Vous êtes confronté à un problème de fiabilité du réseau. Le cache HTTP du navigateur constitue votre première ligne de défense, mais comme vous l'avez appris, il n'est vraiment efficace que pour charger des URL avec versions gérées que vous avez déjà consultées. À lui seul, le cache HTTP ne suffit pas.
Heureusement, deux outils plus récents sont disponibles pour vous aider à renverser le cours : les service workers et l'API Cache Storage. Étant donné qu'ils sont si souvent utilisés ensemble, il peut être utile de les connaître tous les deux en même temps.
Service workers
Un service worker est intégré au navigateur et contrôlé par un peu de code JavaScript supplémentaire que vous êtes chargé de créer. Vous le déployez avec les autres fichiers qui constituent votre application Web réelle.
Un service worker possède des pouvoirs spéciaux. Entre autres tâches, il attend patiemment que votre application Web effectue une requête sortante, puis passe à l'action en l'interceptant. C'est à vous de déterminer la manière dont le service worker traite la requête interceptée.
Pour certaines requêtes, le meilleur plan d'action peut consister à autoriser simplement la requête à poursuivre sur le réseau, comme ce qui se passerait en l'absence de service worker.
Pour les autres requêtes, vous pouvez tirer parti d'un outil plus flexible que le cache HTTP du navigateur et renvoyer une réponse rapide et fiable sans avoir à vous soucier du réseau. Cela implique d'utiliser l'autre partie du puzzle: l'API Cache Storage.
API Cache Storage
L'API Cache Storage ouvre un tout nouveau champ de possibilités, en offrant aux développeurs un contrôle total sur le contenu du cache. Plutôt que de s'appuyer sur une combinaison d'en-têtes HTTP et sur les heuristics intégrées du navigateur, l'API Cache Storage expose une approche de mise en cache basée sur le code. L'API Cache Storage est particulièrement utile lorsqu'elle est appelée à partir du code JavaScript de votre service worker.
Attendez... Y a-t-il un autre cache auquel réfléchir maintenant ?
Vous vous posez probablement des questions telles que "Dois-je toujours configurer mes en-têtes HTTP ?" et "Que puis-je faire avec ce nouveau cache qui n'était pas possible avec le cache HTTP ?" Ne vous inquiétez pas, ce sont des réactions naturelles.
Il est toujours recommandé de configurer les en-têtes Cache-Control sur votre serveur Web, même lorsque vous savez que vous utilisez l'API Cache Storage. En règle générale, vous pouvez définir Cache-Control: no-cache pour les URL sans version et/ou Cache-Control: max-age=31536000 pour les URL contenant des informations de gestion des versions, telles que des hachages.
Lorsque vous remplissez le cache de l'API Cache Storage, le navigateur recherche par défaut les entrées existantes dans le cache HTTP et les utilise si elles sont trouvées. Si vous ajoutez des URL avec gestion des versions au cache de l'API Cache Storage, le navigateur évite une requête réseau supplémentaire. En revanche, si vous utilisez des en-têtes Cache-Control mal configurés (par exemple, si vous spécifiez une longue durée de vie du cache pour une URL sans version), vous pouvez aggraver la situation en ajoutant ce contenu obsolète à l'API Cache Storage. Le tri du comportement du cache HTTP est une condition préalable à une utilisation efficace de l'API Cache Storage.
En ce qui concerne ce qui est désormais possible avec cette nouvelle API, la réponse est: beaucoup. Voici quelques utilisations courantes qui seraient difficiles, voire impossibles, avec le seul cache HTTP:
- Pour le contenu mis en cache, adoptez une approche d'actualisation en arrière-plan, appelée "stale-while-revalidate".
- Limitez le nombre maximal d'éléments à mettre en cache et mettez en œuvre une règle d'expiration personnalisée pour supprimer des éléments une fois cette limite atteinte.
- Comparez les réponses réseau précédemment mises en cache et les nouvelles réponses réseau pour voir si quelque chose a changé, et permettez à l'utilisateur de mettre à jour le contenu (à l'aide d'un bouton, par exemple) lorsque les données ont bien été mises à jour.
Pour en savoir plus, consultez The Cache API: A Quick guide (L'API Cache : guide rapide).
rouages de l'API
Il y a quelques points à garder à l'esprit concernant la conception de l'API:
- Les objets
Requestservent de clés uniques lors de la lecture et de l'écriture dans ces caches. Pour plus de commodité, vous pouvez transmettre une chaîne d'URL telle que'https://example.com/index.html'en tant que clé au lieu d'un objetRequestréel. L'API gérera automatiquement cela pour vous. - Les objets
Responsesont utilisés comme valeurs dans ces caches. - L'en-tête
Cache-Controlsur unResponsedonné est effectivement ignoré lors de la mise en cache des données. Il n'existe pas de vérification automatique de l'expiration ou de la fraîcheur, et une fois que vous avez stocké un élément dans le cache, il est conservé jusqu'à ce que votre code le supprime explicitement. Il existe des bibliothèques qui simplifient la maintenance du cache en votre nom. Nous y reviendrons plus tard dans cette série.) - Contrairement aux anciennes API synchrones telles que
LocalStorage, toutes les opérations de l'API Cache Storage sont asynchrones.
Détour rapide: promesses et async/await
Les service workers et l'API Cache Storage utilisent des concepts de programmation asynchrone.
En particulier, elles s'appuient fortement sur les promesses pour représenter le résultat futur des opérations asynchrones. Avant de vous lancer, familiarisez-vous avec les promesses et la syntaxe async/await associée.
Ne déployez pas ce code pour l'instant
Bien qu'ils constituent une base importante et puissent être utilisés tels quels, les service workers et l'API Cache Storage sont en fait des composants de base de niveau inférieur, avec un certain nombre de cas limites et de "gotchas" (littéralements). Il existe des outils de niveau supérieur qui peuvent faciliter les tâches complexes de ces API et vous fournir tout ce dont vous avez besoin pour créer un service worker prêt pour la production. Le guide suivant porte sur l'un de ces outils : Workbox.