La mise en cache de l'environnement d'exécution consiste à ajouter progressivement des réponses à un cache "au fur et à mesure". Bien que la mise en cache de l'environnement d'exécution n'améliore pas la fiabilité de la requête actuelle, elle permet d'améliorer la fiabilité des requêtes futures pour la même URL.
Le cache HTTP du navigateur est un exemple de mise en cache au moment de l'exécution. Il n'est renseigné qu'après une requête pour une URL donnée. Toutefois, les service workers vous permettent d'implémenter une mise en cache de l'environnement d'exécution qui va au-delà de ce que le cache HTTP seul peut offrir.
Faire preuve de stratégie
Contrairement à la pré-mise en cache (qui tente toujours de diffuser un ensemble de fichiers prédéfinis à partir d'un cache), la mise en cache de l'environnement d'exécution peut combiner l'accès au réseau et au cache de plusieurs manières. Chaque combinaison est généralement appelée stratégie de mise en cache. Les principales stratégies de mise en cache sont les suivantes:
- Priorité au réseau
- Cache-first
- Obsolète pendant la revalidation
Priorité au réseau
Dans cette approche, votre service worker tente d'abord de récupérer une réponse du réseau. Si la requête réseau aboutit, parfait ! La réponse est renvoyée à votre application Web et une copie de celle-ci est stockée à l'aide de l'API Cache Storage. Cette opération crée une entrée ou met à jour une entrée précédente pour la même URL.
Si la requête réseau échoue complètement ou prend trop de temps à renvoyer une réponse, la réponse la plus récente du cache est renvoyée à la place.
Cache-first
Une stratégie axée sur le cache est en fait le contraire de la stratégie axée sur le réseau. Dans cette approche, lorsque votre service worker intercepte une requête, il commence par utiliser l'API Cache Storage pour voir si une réponse mise en cache est disponible. Le cas échéant, cette réponse est renvoyée à l'application Web.
Toutefois, en cas de défaut de cache, le service worker se connecte au réseau et tente d'y récupérer une réponse. En supposant que la requête réseau aboutit, elle est renvoyée à votre application Web et une copie est enregistrée dans un cache. Cette copie mise en cache sera utilisée pour contourner le réseau la prochaine fois qu'une requête sera envoyée pour les mêmes URL.
Obsolète pendant la revalidation
Obsolète tout en revalidant quelque chose comme un hybride. Lorsque vous l'utilisez, votre service worker recherche immédiatement une réponse mise en cache et, le cas échéant, la transmet à votre application Web.
En attendant, qu'une correspondance avec le cache ait été établie ou non, votre service worker déclenche également une requête réseau pour obtenir une réponse "nouvelle". Cette réponse permet de mettre à jour toute réponse précédemment mise en cache. Si la vérification du cache initiale a été effectuée par erreur, une copie de la réponse du réseau est également renvoyée à votre application Web.
Pourquoi utiliser Workbox ?
Ces stratégies de mise en cache correspondent à des recettes que vous devriez normalement réécrire sur votre propre service worker, encore et encore. Au lieu d'avoir recours à cette fonctionnalité, Workbox les propose dans sa bibliothèque de stratégies, que vous pouvez désormais utiliser chez votre service worker.
Workbox prend également en charge la gestion des versions, ce qui vous permet d'expirer automatiquement des entrées mises en cache ou d'avertir votre application Web lorsque des mises à jour d'une entrée précédemment mise en cache sont effectuées.
Quels assets devez-vous mettre en cache et quelles stratégies adopter ?
La mise en cache de l'environnement d'exécution peut être considérée comme un complément à la mise en cache préalable. Si tous vos éléments sont déjà en pré-cache, vous avez terminé. Vous n'avez rien à mettre en cache au moment de l'exécution. Il y a de fortes chances que, pour toute application Web relativement complexe, vous n'allez pas mettre tout en cache.
Les fichiers multimédias plus volumineux, c'est-à-dire les éléments diffusés à partir d'un hôte tiers tel qu'un CDN ou les réponses d'API, ne sont que quelques exemples des types d'éléments qui ne peuvent pas être mis en cache efficacement. Utilisez le panneau "Network" (Réseau) dans les outils de développement pour identifier les requêtes qui appartiennent à cette catégorie, et pour chacune d'elles, réfléchissez au compromis approprié entre fraîcheur et fiabilité.
Utiliser stale-while-revalidate pour privilégier la fiabilité à l'actualisation
Étant donné qu'une stratégie d'actualisation obsolète renvoie une réponse mise en cache presque immédiatement (après que le cache a été rempli via la première requête), vous obtiendrez des performances fiables et rapides lors de son utilisation. Cela s'accompagne d'un compromis : obtenir des données de réponse de retour qui pourraient être obsolètes par rapport à ce qui aurait été récupéré sur le réseau. Cette stratégie fonctionne mieux pour les éléments tels que les images de profil utilisateur ou les réponses initiales de l'API utilisées pour renseigner une vue, lorsque vous savez qu'il est essentiel d'afficher un élément immédiatement, même s'il s'agit d'une valeur plus ancienne.
Utiliser une priorité réseau pour privilégier l'actualisation plutôt que la fiabilité
D'une certaine manière, l'utilisation d'une stratégie axée sur le réseau consiste à accepter une défaite dans votre bataille contre le réseau. Cette stratégie est prioritaire, mais elle est incertaine concernant la fiabilité. Pour certains types d'éléments, il est préférable d'afficher une nouvelle réponse plutôt que de récupérer des informations obsolètes. Par exemple, vous pouvez préférer la fraîcheur lorsque vous effectuez une requête API pour le texte d'un article fréquemment mis à jour.
En utilisant une stratégie axée sur le réseau dans un service worker, au lieu d'aller directement à l'encontre du réseau, vous avez l'avantage de pouvoir revenir à quelque chose, même s'il s'agit d'une réponse potentiellement obsolète. Vous ne serez pas fiable, mais vous resterez hors connexion.
Utiliser le cache-first pour les URL avec gestion des versions
Dans une stratégie axée sur le cache, une fois qu'une entrée est mise en cache, elle n'est jamais mise à jour. Pour cette raison, assurez-vous de ne l'utiliser qu'avec des assets peu susceptibles de changer. En particulier, elle fonctionne mieux pour les URL qui contiennent des informations de gestion des versions, c'est-à-dire le même type d'URL qui doivent également être diffusées avec un en-tête de réponse Cache-Control: max-age=31536000.