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'aide pas à garantir la fiabilité du système actuel cela permet de rendre les futures requêtes envoyées à la même URL plus fiables.
Le cache HTTP du navigateur est un exemple de mise en cache de l'environnement d'exécution. il est simplement renseigné après une requête pour une URL donnée. Mais les service workers 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.
Stratégie
Par opposition à la mise en cache préalable (qui tente toujours pour 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
- Mise en cache prioritaire
- Obsolète pendant la revalidation
Priorité au réseau
Avec cette approche, le service worker tente d'abord de récupérer une réponse d'un le réseau. Si la requête réseau aboutit, c'est parfait ! La réponse est renvoyée votre application Web, et une copie de la réponse est stockée dans le cache API : soit en créant une nouvelle entrée, soit en mettant à jour une entrée précédente pour URL.
Si la requête réseau échoue complètement, ou prend trop de temps pour renvoyer une réponse, la réponse la plus récente du cache est renvoyée à la place.
Mise en cache prioritaire
Une stratégie axée sur le cache est en fait l'inverse d'une stratégie axée sur le réseau. Dans ce lorsque votre service worker intercepte une requête, il utilise d'abord l'objet Cache l'API Storage pour vérifier si une réponse mise en cache est disponible. Si c'est le cas, cette réponse est renvoyée à l'application Web.
Toutefois, en cas de défaut de cache (miss), le service worker accède au réseau et tenter d'y récupérer une réponse. En supposant que la requête réseau est réussi, elle est renvoyée à votre application Web et une copie est enregistrée dans un cache. Ce copie en cache sera utilisée pour contourner le réseau la prochaine fois qu'une requête les mêmes URL sont créées.
Obsolète pendant la revalidation
L'état obsolète de la revalidation est en quelque sorte hybride. Lorsque vous l'utilisez, votre service Le nœud de calcul vérifie immédiatement si une réponse mise en cache est disponible et, le cas échéant, transmet à votre application Web.
Dans l'intervalle, qu'il y ait eu ou non une correspondance de cache, votre service Le nœud de calcul déclenche également une requête réseau pour obtenir une "nouvelle" de réponse. Ce est utilisée pour mettre à jour toute réponse précédemment mise en cache. Si le cache initial a échoué, une copie de la réponse du réseau est également renvoyée à votre serveur Web l'application.
Pourquoi utiliser Workbox ?
Ces stratégies de mise en cache revient à des recettes que vous auriez normalement dû dans votre propre service worker, encore et encore. Au lieu de recourir à Workbox les propose sous forme de package bibliothèque de stratégies à passer à votre service worker.
Workbox est également compatible avec la gestion des versions, ce qui vous permet de expire mises en cache ou notifier votre application Web mises à jour à une entrée précédemment mise en cache se produisent.
Avec quelles stratégies devez-vous utiliser la mise en cache ?
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à mis en pré-cache, vous avez terminé : vous n'avez pas besoin à mettre en cache au moment de l'exécution. Il y a de fortes chances que pour une application Web relativement complexe, vous mais sans tout mettre en cache.
Les fichiers multimédias plus volumineux, les éléments diffusés à partir d'un hôte tiers comme un CDN, ou de l'API ne sont que quelques exemples des types d'éléments qu'il est impossible efficacement mis en pré-cache. Identifier les requêtes à l'aide du panneau "Network" (Réseau) des outils de développement qui entrent dans cette catégorie. Réfléchissez au compromis entre fraîcheur et fiabilité est appropriée.
Utiliser "stale-while-revalidate" pour privilégier la fiabilité à la fraîcheur
Étant donné qu'une stratégie "stale-while-revalidate" 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 terminerez des performances fiables et rapides lors de l'utilisation de cette stratégie. Inclut le compromis d'obtenir des données de réponse qui pourraient être obsolètes par rapport à ce qui aurait été récupéré sur le réseau. Cette stratégie est plus efficace pour les éléments tels que les images de profil utilisateur ou les réponses initiales de l'API permettant d'afficher une vue, quand vous savez qu'il est essentiel d'afficher immédiatement quelque chose, s'il s'agit d'une valeur plus ancienne.
Utiliser une approche réseau-first pour privilégier l'actualisation plutôt que la fiabilité
D'une certaine manière, utiliser une stratégie axée sur le réseau revient à admettre la victoire dans la bataille par rapport au réseau. La priorité est donnée, mais cela génère de l'incertitude. sur la fiabilité. Pour certains types de composants, il est préférable de voir une nouvelle réponse plutôt que de récupérer des informations obsolètes. Vous préférez peut-être une fréquence d'actualisation une requête API pour le texte d'un article mis à jour fréquemment, par Compute Engine.
En utilisant une stratégie axée sur le réseau au sein d'un service worker, au lieu d'utiliser uniquement directement au réseau, vous avez l'avantage de tomber à quelque chose, même s'il s'agit d'une réponse potentiellement obsolète. Vous ne pourrez pas de manière fiable, mais au moins une fois hors connexion.
Utiliser la mise en cache prioritaire pour les URL avec gestion des versions
Dans une stratégie de type "cache-first", une fois qu'une entrée est mise en cache, elle n'est jamais mise à jour. Pour cela
ne l'utilisez qu'avec des assets dont vous savez qu'ils
le changement. En particulier, cette option est plus efficace pour les URL contenant
des informations supplémentaires. Il s'agit du même type d'URL qui devrait être diffusé avec
En-tête de réponse Cache-Control: max-age=31536000.