Avantages et inconvénients de l'utilisation d'une logique d'expiration cohérente ou différente dans le cache de service worker et les couches de cache HTTP
Alors que les service workers et les PWA deviennent la norme des applications Web modernes, la mise en cache des ressources est devenu plus complexe que jamais. Cet article offre une vue d'ensemble de la mise en cache dans le navigateur, y compris:
- Cas d'utilisation et différences entre la mise en cache des service workers et la mise en cache HTTP
- Avantages et inconvénients des différentes stratégies d'expiration de la mise en cache des service workers par rapport aux stratégies d'expiration Stratégies de mise en cache HTTP
Présentation du flux de mise en cache
De manière générale, lorsqu'il demande une ressource, un navigateur suit l'ordre de mise en cache ci-dessous:
- Service worker cache: le service worker vérifie si la ressource se trouve dans son cache et décide si la ressource doit être renvoyée ou non en fonction de ses stratégies de mise en cache programmées. Remarque que cela ne s'effectue pas automatiquement. Vous devez créer un gestionnaire d'événements d'extraction dans votre service worker et intercepter les requêtes réseau afin qu'elles soient diffusées à partir du service le cache du nœud de calcul plutôt que le réseau.
- Cache HTTP (également appelé cache du navigateur): si la ressource se trouve dans le cache HTTP cache et n'a pas encore expiré, le navigateur utilise automatiquement le à partir du cache HTTP.
- Côté serveur:si rien n'est trouvé dans le cache du service worker ou le cache HTTP, le navigateur accède au réseau pour demander la ressource. Si la ressource n'est pas mise en cache dans un CDN, doit remonter jusqu'au serveur d'origine.
Mettre en cache des couches
Mise en cache d'un service worker
Un service worker intercepte les requêtes HTTP de type réseau et utilise un stratégie de mise en cache pour déterminer quelles ressources doivent être renvoyées au navigateur. Le cache de service worker et la couche HTTP ont la même utilité générale, mais le cache de service worker offre davantage de fonctionnalités de mise en cache, comme un contrôle précis sur ce qui est mis en cache et sur la façon dont la mise en cache est effectuée.
Contrôler le cache de service worker
Un service worker intercepte les requêtes HTTP présentant un événement
écouteurs (généralement l'événement fetch). Ce
extrait de code illustre la logique d'un
Mise en cache prioritaire
stratégie de mise en cache.
Nous vous recommandons vivement d'utiliser Workbox pour éviter de réinventer la roue. Par exemple, vous pouvez enregistrer les chemins d'URL des ressources avec une seule ligne de code d'expression régulière.
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
Stratégies de mise en cache des service workers et cas d'utilisation
Le tableau suivant décrit les stratégies courantes de mise en cache des service workers, ainsi que leur utilité.
| Stratégies | Justification de l'actualisation | Cas d'utilisation |
|---|---|---|
| Réseau uniquement | Le contenu doit être à jour en permanence. |
|
| Réseau retour au cache | Il est préférable de diffuser le contenu récent. Toutefois, si le réseau tombe en panne ou est instable, pour diffuser du contenu un peu ancien. |
|
| Obsolète pendant la revalidation | La diffusion immédiate du contenu mis en cache est autorisée. Toutefois, le contenu mis en cache mis à jour doit être utilisé dans la section à venir. |
|
| Mise en cache d'abord, retour au réseau | Le contenu n'est pas critique et peut être diffusé à partir du cache pour des performances accrues, le service worker recherche régulièrement les mises à jour. |
|
| Cache uniquement | Le contenu change rarement. |
|
Avantages supplémentaires de la mise en cache des service workers
En plus d'un contrôle ultraprécis de la logique de mise en cache, la mise en cache d'un service worker offre également les avantages suivants:
- Plus de mémoire et d'espace de stockage pour votre origine:le navigateur alloue le cache HTTP ressources par origine. Dans d'autres mots, si vous avez plusieurs sous-domaines, ils partagent tous le même cache HTTP. Il n'y a aucun garantir que le contenu de votre origine/domaine reste longtemps dans le cache HTTP. Pour Par exemple, un utilisateur peut vider le cache en nettoyant manuellement le cache à partir de l'interface utilisateur des paramètres d'un navigateur. pour déclencher l'actualisation forcée d'une page. Avec un cache de service workers, la probabilité que votre contenu mis en cache reste en cache. Voir la section Persistent stockage pour en savoir plus.
- Flexibilité accrue avec les réseaux instables ou les expériences hors connexion:le cache HTTP vous permet n'ont qu'un choix binaire: soit la ressource soit mise en cache, soit non. Avec mise en cache des service workers vous pouvez atténuer les petits « hoquets » avec la stratégie "stale-while-revalidate", offrent une expérience hors connexion complète (avec la stratégie "Cache uniquement") ou même un élément entre les différentes interfaces, comme les interfaces utilisateur personnalisées, certaines parties de la page provenant du cache de service worker et certaines parties sont exclues (avec la stratégie "Définir le gestionnaire d'interception", le cas échéant).
Mise en cache HTTP
La première fois qu'un navigateur charge une page Web et des ressources associées, il stocke ces ressources dans son Cache HTTP. Le cache HTTP est généralement activé automatiquement par les navigateurs, sauf s'il a été explicitement désactivées par l'utilisateur final.
L'utilisation de la mise en cache HTTP signifie s'appuyer sur le serveur pour déterminer quand mettre en cache une ressource et comment très longtemps.
Contrôler l'expiration du cache HTTP à l'aide d'en-têtes de réponse HTTP
Lorsqu'un serveur répond à une demande de ressource du navigateur, il utilise des en-têtes de réponse HTTP pour indiquer à un navigateur combien de temps il doit mettre en cache la ressource. Reportez-vous à la section En-têtes de réponse: configurer votre Google Cloud pour en savoir plus.
Stratégies de mise en cache HTTP et cas d'utilisation
La mise en cache HTTP est beaucoup plus simple que la mise en cache d'un service worker, car elle ne traite que des d'expiration des ressources basée sur le temps (TTL). Voir Quelles valeurs d'en-tête de réponse devez-vous utiliser ? et Résumé pour en savoir plus sur les stratégies de mise en cache HTTP.
Concevoir la logique d'expiration du cache
Cette section explique les avantages et les inconvénients liés à l'utilisation d'une logique d'expiration cohérente sur l'ensemble du service worker et HTTP, ainsi que les avantages et les inconvénients d'une logique d'expiration distincte couches.
Le Glitch ci-dessous illustre le fonctionnement de la mise en cache d'un service worker et de la mise en cache HTTP différents scénarios:
Logique d'expiration cohérente pour toutes les couches de cache
Pour illustrer les avantages et les inconvénients, nous allons étudier trois scénarios: à long terme, à moyen terme et à court terme.
| Scénarios | Mise en cache à long terme | Mise en cache à moyen terme | Mise en cache à court terme |
|---|---|---|---|
| Stratégie de mise en cache d'un service worker | Cache, retour au réseau | Obsolète pendant la revalidation | Retour au cache sur le réseau |
| Valeur TTL du cache de service worker | 30 jours | 1 jour | 10 min |
| Âge maximal du cache HTTP | 30 jours | 1 jour | 10 min |
Scénario: mise en cache à long terme (cache, retour au réseau)
- Lorsqu'une ressource mise en cache est valide (<= 30 jours): le service worker renvoie la valeur mise en cache. sans passer par le réseau.
- Lorsqu'une ressource mise en cache expire (plus de 30 jours): le service worker accède au réseau pour récupérer la ressource. Le navigateur ne possède pas de copie de la ressource dans son cache HTTP. est effectuée côté serveur pour la ressource.
Inconvénient: dans ce scénario, la mise en cache HTTP offre moins de valeur, car le navigateur transmettre la requête côté serveur lorsque le cache expire dans le service worker.
Scénario: Mise en cache à moyen terme (obsolète pendant la revalidation)
- Lorsqu'une ressource mise en cache est valide (<= 1 jour): le service worker renvoie la valeur mise en cache. ressource immédiatement et va la récupérer sur le réseau. Le navigateur a une copie de la ressource dans son cache HTTP. La copie est donc renvoyée au service worker.
- Lorsqu'une ressource mise en cache expire (plus d'un jour): le service worker renvoie la valeur mise en cache. ressource immédiatement et va la récupérer sur le réseau. Le navigateur ne dispose pas de la ressource dans son cache HTTP, de sorte qu'il la récupère côté serveur.
Inconvénient: le service worker nécessite un cache busting supplémentaire pour remplacer le cache HTTP dans afin de tirer le meilleur parti de la « revalidation » étape.
Scénario: Mise en cache à court terme (remplacement du réseau vers le cache)
- Lorsqu'une ressource mise en cache est valide (<= 10 minutes): le service worker accède au réseau pour récupérer la ressource. Le navigateur possède une copie de la ressource dans son cache HTTP. au service worker sans passer côté serveur.
- Lorsqu'une ressource mise en cache expire (plus de 10 minutes): le service worker renvoie la ressource mise en cache. ressource immédiatement et va la récupérer sur le réseau. Le navigateur ne dispose pas de la ressource dans son cache HTTP, de sorte qu'il la récupère côté serveur.
Inconvénient: à l'instar du scénario de mise en cache à moyen terme, le service worker nécessite des ressources pour remplacer le cache HTTP afin d'extraire la dernière ressource du côté serveur.
Service worker dans tous les scénarios
Dans tous les scénarios, le cache du service worker renvoie toujours des ressources mises en cache lorsque le réseau est instable. En revanche, le cache HTTP n'est pas fiable lorsque le réseau est instable ou indisponible.
Une logique d'expiration du cache différente au niveau du cache du service worker et des couches HTTP
Pour illustrer les avantages et les inconvénients, nous nous intéresserons à nouveau différents scénarios.
| Scénarios | Mise en cache à long terme | Mise en cache à moyen terme | Mise en cache à court terme |
|---|---|---|---|
| Stratégie de mise en cache d'un service worker | Cache, retour au réseau | Obsolète pendant la revalidation | Retour au cache sur le réseau |
| Valeur TTL du cache de service worker | 90 jours | 30 jours | 1 jour |
| Âge maximal du cache HTTP | 30 jours | 1 jour | 10 min |
Scénario: mise en cache à long terme (cache, retour au réseau)
- Lorsqu'une ressource mise en cache est valide dans le cache du service worker (<= 90 jours): le service Le nœud de calcul renvoie immédiatement la ressource mise en cache.
- Lorsqu'une ressource mise en cache expire dans le cache du service worker (plus de 90 jours): le service Le nœud de calcul va récupérer la ressource sur le réseau. Le navigateur n'a pas de copie dans son cache HTTP, et passe donc côté serveur.
Avantages et inconvénients :
- Avantage: les utilisateurs bénéficient d'une réponse instantanée lorsque le service worker renvoie des ressources mises en cache. immédiatement.
- Avantage: Le service worker contrôle plus précisément quand utiliser son cache et quand. pour demander de nouvelles versions des ressources.
- Inconvénient: une stratégie bien définie de mise en cache de service worker est requise.
Scénario: mise en cache à mi-parcours (obsolète pendant la revalidation)
- Lorsqu'une ressource mise en cache est valide dans le cache du service worker (<= 30 jours): le service Le nœud de calcul renvoie immédiatement la ressource mise en cache.
- Lorsqu'une ressource mise en cache expire dans le cache du service worker (plus de 30 jours): le service le nœud de calcul accède au réseau pour la ressource. Le navigateur ne dispose d'aucune copie de la ressource dans son cache HTTP, elle passe donc côté serveur.
Avantages et inconvénients :
- Avantage: les utilisateurs bénéficient d'une réponse instantanée lorsque le service worker renvoie des ressources mises en cache. immédiatement.
- Avantage: le service worker peut s'assurer que la requête next pour une URL donnée utilise un une nouvelle réponse du réseau, grâce à la revalidation qui se produit "en arrière-plan".
- Inconvénient: une stratégie bien définie de mise en cache de service worker est requise.
Scénario: Mise en cache à court terme (remplacement du réseau vers le cache)
- Lorsqu'une ressource mise en cache est valide dans le cache du service worker (<= 1 jour): le service le nœud de calcul accède au réseau pour la ressource. Le navigateur renvoie la ressource à partir de la requête s'il est présent. Si le réseau est indisponible, le service worker renvoie la ressource à partir du cache de service worker
- Lorsqu'une ressource mise en cache expire dans le cache du service worker (plus d'un jour): le service Le nœud de calcul va récupérer la ressource sur le réseau. Le navigateur récupère les ressources sur le car la version mise en cache dans son cache HTTP a expiré.
Avantages et inconvénients :
- Avantage: lorsque le réseau est instable ou indisponible, le service worker renvoie des données mises en cache. des ressources.
- Inconvénient: le service worker nécessite un cache busting supplémentaire pour remplacer le cache HTTP et sélectionnez "Réseau d'abord" requêtes.
Conclusion
Compte tenu de la complexité des scénarios de mise en cache, il n'est pas possible de concevoir une seule règle qui couvre tous les cas. Toutefois, compte tenu des conclusions des sections précédentes, suggestions à prendre en compte lorsque vous concevez vos stratégies de cache:
- La logique de mise en cache du service worker n'a pas besoin d'être cohérente avec l'expiration de la mise en cache HTTP logique. Si possible, utilisez une logique d'expiration plus longue dans le service worker pour lui accorder plus de contrôle.
- La mise en cache HTTP joue toujours un rôle important, mais elle n'est pas fiable lorsque le réseau est instable ou en panne.
- Revoyez vos stratégies de mise en cache pour chaque ressource afin de vous assurer que votre service worker fournit sa valeur, sans entrer en conflit avec le cache HTTP.