Service workers et API Cache Storage

Jeff Posnick

Vous êtes dans une lutte constante pour la fiabilité du réseau. Le cache HTTP du navigateur est votre première ligne de défense, mais comme vous l'avez appris, il n'est vraiment efficace que lors du chargement d'URL versionnées que vous avez déjà consultées. Le cache HTTP ne suffit pas à lui seul.

Heureusement, deux outils plus récents sont disponibles pour vous aider à inverser la tendance : les service workers et l'API Cache Storage. Étant donné qu'ils sont souvent utilisés ensemble, il est utile de les découvrir 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.

Un service worker dispose de certains 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écider de ce que le service worker fait avec cette requête interceptée.

Pour certaines requêtes, la meilleure solution consiste peut-être simplement à autoriser la requête à continuer sur le réseau, comme cela se passerait s'il n'y avait pas de service worker.

Toutefois, pour d'autres requêtes, vous pouvez utiliser un élément plus flexible que le cache HTTP du navigateur et renvoyer une réponse fiable et rapide sans avoir à vous soucier du réseau. Pour ce faire, vous devez utiliser l'autre pièce du puzzle: l'API Cache Storage.

API Cache Storage

L'API Cache Storage ouvre un tout nouveau champ des possibles en donnant aux développeurs un contrôle total sur le contenu du cache. Au lieu de s'appuyer sur une combinaison d'en-têtes HTTP et des heuristiques 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… Il y a un autre cache à prendre en compte ?

Vous vous demandez probablement si vous devez toujours configurer vos en-têtes HTTP et ce que vous pouvez 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.

Nous vous recommandons toujours de configurer les en-têtes Cache-Control sur votre serveur Web, même si vous savez que vous utilisez l'API Cache Storage. Vous pouvez généralement 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, comme des hachages.

Lors du remplissage du cache de l'API Cache Storage, le navigateur recherche par défaut des entrées existantes dans le cache HTTP et les utilise si elles sont trouvées. Si vous ajoutez des URL avec version au cache de l'API Cache Storage, le navigateur évite une requête réseau supplémentaire. À l'inverse, si vous utilisez des en-têtes Cache-Control mal configurés, par exemple en spécifiant une durée de vie de cache longue pour une URL non versionnée, vous pouvez aggraver la situation en ajoutant ce contenu obsolète à l'API Cache Storage. Il est nécessaire de mettre en ordre le comportement de votre cache HTTP pour utiliser efficacement l'API Cache Storage.

Quant aux possibilités offertes par cette nouvelle API, la réponse est: beaucoup. Voici quelques utilisations courantes qui seraient difficiles ou impossibles avec le seul cache HTTP:

• Utilisez une approche "mise à jour en arrière-plan" pour le contenu mis en cache, appelée "obsolète pendant la validation".
• Imposez une limite au nombre maximal d'éléments à mettre en cache et implémentez une règle d'expiration personnalisée pour supprimer les éléments une fois cette limite atteinte.
• Comparez les réponses réseau précédemment mises en cache et les réponses réseau récentes pour voir si quelque chose a changé, et autorisez l'utilisateur à mettre à jour le contenu (avec un bouton, par exemple) lorsque les données ont effectivement été mises à jour.

Pour en savoir plus, consultez API Cache: guide rapide.

Détails de l'API

Voici quelques points à prendre en compte concernant la conception de l'API:

• Les objets Request sont utilisés comme 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 comme 'https://example.com/index.html' comme clé au lieu d'un objet Request réel. L'API s'en chargera automatiquement.
• Les objets Response sont utilisés comme valeurs dans ces caches.
• L'en-tête Cache-Control d'un Response donné est effectivement ignoré lors de la mise en cache des données. Il n'existe aucune vérification automatique intégrée de l'expiration ou de la fraîcheur. Une fois que vous avez stocké un élément dans le cache, il persiste jusqu'à ce que votre code le supprime explicitement. (Il existe des bibliothèques pour simplifier la maintenance du cache en votre nom. Nous les aborderons 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.

Un petit détour: les promesses et Async/Await

Les services workers et l'API Cache Storage utilisent des concepts de programmation asynchrone. En particulier, elles s'appuient fortement sur des promesses pour représenter le résultat futur des opérations asynchrones. Avant de vous lancer, vous devez vous familiariser avec les promesses et la syntaxe async/await associée.

Ne déployez pas ce code… pour le moment

Bien qu'ils constituent une base importante et qu'ils puissent être utilisés tels quels, les workers de service et l'API Cache Storage sont en fait des composants de base de niveau inférieur, avec un certain nombre de cas particuliers et de pièges. Certains outils de niveau supérieur peuvent vous aider à simplifier les éléments difficiles de ces API et à fournir tout ce dont vous avez besoin pour créer un service worker prêt à la production. Le guide suivant présente un tel outil : Workbox.