Service workers et API Cache Storage

Jeff Posnick

Vous êtes engagé dans une lutte 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 avec version que vous avez déjà consultées. À lui seul, le cache HTTP ne suffit pas.

Heureusement, deux nouveaux outils sont disponibles pour vous aider à inverser la tendance : les service workers et l'API Cache Storage. Comme ils sont souvent utilisés ensemble, il est utile de les étudier 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 devez créer. Vous le déployez avec les autres fichiers qui composent 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 entre en action en l'interceptant. C'est à vous de décider ce que le service worker fait de cette requête interceptée.

Pour certaines requêtes, la meilleure solution peut être de simplement autoriser la requête à continuer sur le réseau, comme si aucun service worker n'était présent.

Toutefois, pour d'autres requêtes, vous pouvez profiter d'une solution 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 pièce du puzzle : l'API Cache Storage.

API Cache Storage

Browser Support

  • Chrome: 43.
  • Edge: 16.
  • Firefox: 41.
  • Safari: 11.1.

Source

L'API Cache Storage ouvre un tout nouvel éventail de possibilités 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 d'heuristiques intégrées au navigateur, l'API Cache Storage expose une approche de la 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 maintenant ?

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.

Il est toujours recommandé 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 vous contenter de 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.

Lors du remplissage du cache de l'API Cache Storage, le navigateur vérifie par défaut s'il existe des entrées dans le cache HTTP et les utilise s'il en trouve. Si vous ajoutez des URL avec version au cache de l'API Cache Storage, le navigateur évite d'envoyer une requête réseau supplémentaire. En revanche, si vous utilisez des en-têtes Cache-Control mal configurés, par exemple en spécifiant une longue durée de vie du cache pour une URL sans version, vous risquez d'aggraver les choses en ajoutant ce contenu obsolète à l'API Cache Storage. Pour utiliser efficacement l'API Cache Storage, vous devez d'abord trier le comportement de votre cache HTTP.

Qu'est-ce qu'il est désormais possible de faire avec cette nouvelle API ? Beaucoup de choses. Voici quelques utilisations courantes qui seraient difficiles, voire impossibles, avec le cache HTTP seul :

  • Utilisez une approche d'actualisation en arrière-plan pour le contenu mis en cache, appelée "stale-while-revalidate".
  • Imposez un plafond au nombre maximal d'assets à 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 nouvelles réponses pour voir si des modifications ont été apportées, et permettez à l'utilisateur de mettre à jour le contenu (avec un bouton, par exemple) lorsque les données ont effectivement été mises à jour.

Pour en savoir plus, consultez The Cache API: A quick guide (L'API Cache : guide rapide).

Fonctionnement des API

Voici quelques points à garder à l'esprit 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 telle que 'https://example.com/index.html' en tant que clé au lieu d'un objet Request réel, et 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 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 l'actualisation. Une fois que vous stockez 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 : 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, vous devez vous familiariser avec les promesses et la syntaxe async/await associée.

Ne déployez pas encore ce code

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