Avantages et inconvénients de l'utilisation d'une logique d'expiration cohérente ou différente entre les couches de cache de service worker et de cache HTTP
Alors que les service workers et les PWA deviennent des normes pour les applications Web modernes, la mise en cache des ressources est devenue plus complexe que jamais. Cet article couvre la vue d'ensemble de la mise en cache du navigateur, y compris:
- Cas d'utilisation et différences entre la mise en cache par service worker et la mise en cache HTTP
- Avantages et inconvénients des différentes stratégies d'expiration de la mise en cache par service worker par rapport aux stratégies de mise en cache HTTP standards
Présentation du flux de mise en cache
De manière générale, un navigateur suit l'ordre de mise en cache ci-dessous lorsqu'il demande une ressource:
- Service worker Cache: le service worker vérifie si la ressource se trouve dans son cache et décide s'il doit renvoyer la ressource elle-même en fonction de ses stratégies de mise en cache programmées. Notez que cette opération n'est pas automatique. Vous devez créer un gestionnaire d'événements de récupération dans votre service worker et intercepter les requêtes réseau afin qu'elles soient diffusées à partir du cache du service worker plutôt que depuis le réseau.
- Cache HTTP (également appelé cache du navigateur): si la ressource se trouve dans le cache HTTP et n'a pas encore expiré, le navigateur l'utilise automatiquement à partir du cache HTTP.
- Côté serveur:si rien n'est trouvé dans le cache du service worker ou le cache HTTP, le navigateur se connecte au réseau pour demander la ressource. Si la ressource n'est pas mise en cache dans un CDN, la requête doit remonter jusqu'au serveur d'origine.
Mise en cache des calques
Mise en cache du service worker
Un service worker intercepte les requêtes HTTP de type réseau et utilise une stratégie de mise en cache pour déterminer les ressources à renvoyer au navigateur. Le cache de service worker et le cache HTTP ont la même fonction générale, mais le cache de service worker offre des fonctionnalités de mise en cache supplémentaires, telles qu'un contrôle précis des éléments mis en cache et des modalités de mise en cache.
Contrôler le cache du service worker
Un service worker intercepte les requêtes HTTP avec des écouteurs d'événements (généralement l'événement fetch). Cet extrait de code illustre la logique d'une stratégie de mise en cache Cache-First.
Nous vous recommandons vivement d'utiliser Workbox pour éviter de réinventer la roue. Par exemple, vous pouvez enregistrer des chemins d'URL de 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 et cas d'utilisation pour les service workers
Le tableau suivant présente les stratégies courantes de mise en cache des service workers et les cas où chaque stratégie est utile.
| Stratégies | Justification de l'actualisation | Cas d'utilisation |
|---|---|---|
| Réseau uniquement | Le contenu doit être à jour en permanence. |
|
| Le réseau revient au cache | Il est préférable de diffuser le contenu récent. Toutefois, si le réseau tombe en panne ou est instable, il est acceptable de diffuser du contenu légèrement ancien. |
|
| Stale-while-revalidate | Vous pouvez diffuser du contenu mis en cache immédiatement, mais vous devrez utiliser le contenu mis en cache mis à jour à l'avenir. |
|
| Mise en cache d'abord, retour au réseau | Le contenu n'est pas critique et peut être diffusé à partir du cache pour améliorer les performances, mais le service worker doit parfois rechercher des mises à jour. |
|
| Cache uniquement | Le contenu change rarement. |
|
Avantages supplémentaires de la mise en cache des service workers
En plus d'offrir un contrôle ultraprécis de la logique de mise en cache, la mise en cache par service worker offre également les avantages suivants:
- Plus de mémoire et d'espace de stockage pour votre origine:le navigateur alloue les ressources de cache HTTP par origine. En d'autres termes, si vous possédez plusieurs sous-domaines, ils partagent tous le même cache HTTP. Rien ne garantit que le contenu de votre origine ou de votre domaine reste dans le cache HTTP pendant une longue période. Par exemple, un utilisateur peut vider le cache manuellement à partir de l'interface utilisateur des paramètres d'un navigateur ou déclencher une actualisation forcée d'une page. Avec un cache de service worker, il est beaucoup plus probable que votre contenu mis en cache le reste. Pour en savoir plus, consultez la page Stockage persistant.
- Flexibilité accrue avec les réseaux instables ou les expériences hors connexion:avec le cache HTTP, vous n'avez qu'un choix binaire: soit la ressource est mise en cache, soit elle ne l'est pas. Avec la mise en cache du service worker, vous pouvez atténuer les problèmes complexes (avec la stratégie "obsolète" pendant le processus de revalidation), offrir une expérience hors connexion complète (avec la stratégie "Mise en cache uniquement") ou même quelque chose d'intermédiaire, comme des interfaces utilisateur personnalisées avec des parties de la page provenant du cache du service worker et certaines parties exclues (avec la stratégie "Définir un gestionnaire de récupération") 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é par l'utilisateur final.
L'utilisation de la mise en cache HTTP implique de s'appuyer sur le serveur pour déterminer quand et pendant combien de temps une ressource doit être mise en cache.
Contrôler l'expiration du cache HTTP à l'aide d'en-têtes de réponse HTTP
Lorsqu'un serveur répond à une requête de navigateur pour obtenir une ressource, il utilise des en-têtes de réponse HTTP pour indiquer au navigateur pendant combien de temps il doit mettre en cache la ressource. Pour en savoir plus, consultez En-têtes de réponse: configurer votre serveur Web.
Stratégies de mise en cache HTTP et cas d'utilisation
La mise en cache HTTP est beaucoup plus simple que celle des service workers, car elle ne traite que la logique d'expiration des ressources basée sur le temps (TTL). Consultez les sections 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 votre logique d'expiration du cache
Cette section explique les avantages et les inconvénients de l'utilisation d'une logique d'expiration cohérente entre les couches de cache de service worker et HTTP, ainsi que les avantages et les inconvénients d'une logique d'expiration distincte entre ces couches.
Le glitch ci-dessous montre comment la mise en cache du service worker et la mise en cache HTTP fonctionnent en action dans 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 examiner trois scénarios: à long terme, à moyen 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 du service worker | Cache, retour au réseau | Obsolète pendant la revalidation | Retour au cache du réseau |
| Valeur TTL du cache de service worker | 30 jours | 1 jour | 10 min |
| HTTP cache max-age | 30 jours | 1 jour | 10 min |
Scénario: mise en cache à long terme (mise en cache, retour au réseau)
- Lorsqu'une ressource mise en cache est valide (<= 30 jours): le service worker la renvoie immédiatement, sans passer par le réseau.
- Lorsqu'une ressource mise en cache expire (plus de 30 jours): le service worker se connecte au réseau pour récupérer la ressource. Le navigateur ne possède pas de copie de la ressource dans son cache HTTP. La ressource est donc côté serveur.
Inconvénient: dans ce scénario, la mise en cache HTTP fournit moins de valeur, car le navigateur transmet toujours la requête côté serveur lorsque le cache expire dans le service worker.
Scénario: mise en cache à moyen terme (obsolète)
- Lorsqu'une ressource mise en cache est valide (<= 1 jour): le service worker la renvoie immédiatement et se rend sur le réseau pour la récupérer. Le navigateur possède une copie de la ressource dans son cache HTTP. Il renvoie donc cette copie au service worker.
- Lorsqu'une ressource mise en cache expire (plus d'un jour): le service worker renvoie immédiatement la ressource mise en cache et se connecte au réseau pour la récupérer. Le navigateur ne disposant pas d'une copie de la ressource dans son cache HTTP, il va côté serveur pour la récupérer.
Inconvénient: le service worker nécessite un cache busting supplémentaire pour remplacer le cache HTTP afin de tirer le meilleur parti de l'étape de revalidation.
Scénario: mise en cache à court terme (le réseau revient au cache)
- Lorsqu'une ressource mise en cache est valide (<= 10 minutes): le service worker se connecte au réseau pour récupérer la ressource. Le navigateur possède une copie de la ressource dans son cache HTTP. Il la renvoie donc au service worker sans passer par le côté serveur.
- Lorsqu'une ressource mise en cache expire (plus de 10 minutes): le service worker la renvoie immédiatement et se rend sur le réseau pour la récupérer. Le navigateur ne disposant pas d'une copie de la ressource dans son cache HTTP, il va côté serveur pour la récupérer.
Inconvénient: comme dans le scénario de mise en cache à moyen terme, le service worker a besoin d'une logique de contournement du cache supplémentaire pour remplacer le cache HTTP et extraire la dernière ressource côté serveur.
Service Worker dans tous les scénarios
Dans tous les scénarios, le cache du service worker peut toujours renvoyer les 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 en panne.
Une logique d'expiration de cache différente au niveau du cache de service worker et des couches HTTP
Pour illustrer les avantages et les inconvénients, nous étudierons à nouveau les scénarios à long, moyen 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 du service worker | Cache, retour au réseau | Obsolète pendant la revalidation | Retour au cache du réseau |
| Valeur TTL du cache de service worker | 90 jours | 30 jours | 1 jour |
| HTTP cache max-age | 30 jours | 1 jour | 10 min |
Scénario: mise en cache à long terme (mise en cache, retour au réseau)
- Lorsqu'une ressource mise en cache est valide dans le cache du service worker (moins de 90 jours): le service worker 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 worker se connecte au réseau pour récupérer la ressource. Le navigateur ne possède pas de copie de la ressource dans son cache HTTP, elle est donc côté serveur.
Avantages et inconvénients :
- Avantage: les utilisateurs bénéficient d'une réponse instantanée, car le service worker renvoie immédiatement les ressources mises en cache.
- Avantage: le service worker contrôle plus précisément quand utiliser son cache et quand demander de nouvelles versions des ressources.
- Inconvénient: une stratégie de mise en cache bien définie par service worker est requise.
Scénario: mise en cache à moyen terme (obsolète)
- Lorsqu'une ressource mise en cache est valide dans le cache du service worker (moins de 30 jours): le service worker 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 worker se connecte au réseau pour la ressource. Le navigateur n'a pas de copie de la ressource dans son cache HTTP, elle est donc côté serveur.
Avantages et inconvénients :
- Avantage: les utilisateurs bénéficient d'une réponse instantanée, car le service worker renvoie immédiatement les ressources mises en cache.
- Avantage: le service worker peut s'assurer que la requête suivante pour une URL donnée utilise une nouvelle réponse du réseau, grâce à la revalidation qui se produit "en arrière-plan".
- Inconvénient: une stratégie de mise en cache bien définie par service worker est requise.
Scénario: mise en cache à court terme (le réseau revient au cache)
- Lorsqu'une ressource mise en cache est valide dans le cache du service worker (moins d'un jour): le service worker se connecte au réseau pour la ressource. Le navigateur renvoie la ressource à partir du cache HTTP, le cas échéant. Si le réseau est indisponible, le service worker renvoie la ressource depuis son cache.
- Lorsqu'une ressource mise en cache expire dans le cache du service worker (plus d'un jour): le service worker se connecte au réseau pour récupérer la ressource. Le navigateur récupère les ressources sur le réseau, car la version mise en cache dans son cache HTTP a expiré.
Avantages et inconvénients :
- Avantage: Lorsque le réseau est instable ou en panne, le service worker renvoie immédiatement les ressources mises en cache.
- Inconvénient: le service worker nécessite un cache busting supplémentaire pour remplacer le cache HTTP et effectuer des requêtes "Réseau en premier".
Conclusion
Compte tenu de la complexité de la combinaison des scénarios de mise en cache, il n'est pas possible de concevoir une règle unique qui couvre tous les cas. Toutefois, sur la base des résultats des sections précédentes, voici quelques suggestions à prendre en compte lors de la conception de vos stratégies de mise en cache:
- La logique de mise en cache du service worker n'a pas besoin d'être cohérente avec la logique d'expiration de la mise en cache HTTP. 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 les stratégies de mise en cache de chaque ressource pour vous assurer que la stratégie de mise en cache de votre service worker fournit sa valeur, sans conflit avec le cache HTTP.