Avantages et inconvénients de l'utilisation d'une logique d'expiration cohérente ou différente entre la couche de cache du service worker et la couche 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 présente une vue d'ensemble de la mise en cache du navigateur, y compris :
- Les cas d'utilisation et les différences entre la mise en cache des service workers et la mise en cache HTTP.
- Les avantages et les inconvénients des différentes stratégies d'expiration de la mise en cache des service workers par rapport aux stratégies de mise en cache HTTP classiques.
Présentation du flux de mise en cache
En règle générale, un navigateur suit l'ordre de mise en cache ci-dessous lorsqu'il demande une ressource :
- Cache du service worker : 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 cela ne se produit pas automatiquement. 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 que les requêtes soient traitées à partir du cache du service worker plutôt que du réseau.
- Cache HTTP (également appelé cache du navigateur) : si la ressource est trouvée dans le Cache HTTP et n'a pas encore expiré, le navigateur utilise automatiquement la ressource du cache HTTP.
- Côté serveur : si rien n'est trouvé dans le cache du service worker ni dans 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, la requête doit remonter jusqu'au serveur d'origine.
Couches de mise en cache
Mise en cache des service workers
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 du service worker et le cache HTTP ont le même objectif général, mais le cache du service worker offre davantage de fonctionnalités de mise en cache, telles qu'un contrôle précis sur ce qui est mis en cache et sur la manière dont la mise en cache est effectuée.
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 des service workers et cas d'utilisation
Le tableau suivant présente les stratégies de mise en cache des service workers courantes et les cas dans lesquels chaque stratégie est utile.
| Stratégies | Justification de la fraîcheur | Cas d'utilisation |
|---|---|---|
| Réseau uniquement | Le contenu doit être à jour à tout moment. |
|
| Réseau avec retour au cache | Il est préférable de diffuser le contenu frais. Toutefois, en cas de défaillance ou d'instabilité du réseau, il est acceptable de diffuser un contenu légèrement ancien. |
|
| Ancien pendant la revalidation | Il est acceptable de diffuser immédiatement le contenu mis en cache, mais le contenu mis en cache mis à jour doit être utilisé à l'avenir. |
|
| Cache d'abord, puis réseau | Le contenu n'est pas essentiel et peut être diffusé à partir du cache pour améliorer les performances, mais le service worker doit vérifier occasionnellement 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 précis de la logique de mise en cache, la mise en cache des service workers offre également les avantages suivants :
- Plus de mémoire et d'espace de stockage pour votre origine : le navigateur alloue des ressources de cache HTTP par origine. En d'autres termes, si vous disposez de plusieurs sous-domaines, ils partagent tous le même cache HTTP. Il n'est pas garanti que le contenu de votre origine/domaine reste longtemps dans le cache HTTP. Par exemple, un utilisateur peut vider le cache en le nettoyant manuellement à partir de l'interface utilisateur des paramètres d'un navigateur ou en déclenchant un rechargement forcé sur une page. Avec un cache de service worker, vous avez beaucoup plus de chances que votre contenu mis en cache reste mis en cache. Pour en savoir plus, consultez la section Stockage persistant.
- Plus de flexibilité avec les réseaux instables ou les expériences hors connexion : avec le cache HTTP, vous n'avez qu'un choix binaire : la ressource est mise en cache ou non. Avec la mise en cache des service workers, vous pouvez atténuer beaucoup plus facilement les petits "problèmes" (avec la stratégie "Ancien pendant la revalidation"), offrir une expérience hors connexion complète (avec la stratégie "Cache uniquement") ou même quelque chose entre les deux, 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 le gestionnaire de capture") le cas échéant.
Mise en cache HTTP
La première fois qu'un navigateur charge une page Web et les 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 signifie que vous comptez sur le serveur pour déterminer quand mettre en cache une ressource et pendant combien de temps.
Contrôler l'expiration du cache HTTP avec des en-têtes de réponse HTTP
Lorsqu'un serveur répond à une requête de navigateur pour une ressource, il utilise des en-têtes de réponse HTTP pour indiquer à un navigateur combien de temps il doit mettre en cache la ressource. Pour en savoir plus, consultez la section 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 la mise en cache des service workers, car elle ne traite que la logique d'expiration des ressources basée sur le temps (TTL). Pour en savoir plus sur les stratégies de mise en cache HTTP, consultez les sections Quelles valeurs d'en-tête de réponse devez-vous utiliser ? et Empêcher les requêtes réseau inutiles avec le cache HTTP (résumé).
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 la couche de cache du service worker et la couche de cache HTTP, ainsi que les avantages et les inconvénients d'une logique d'expiration distincte entre ces couches.
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 terme et à court terme.
| Scenarios | Mise en cache à long terme | Mise en cache à moyen terme | Mise en cache à court terme |
|---|---|---|---|
| Stratégie de mise en cache des service workers | Cache, avec retour au réseau | Ancien pendant la revalidation | Réseau avec retour au cache |
| TTL du cache du service worker | 30 jours | 1 jour | 10 minutes |
| Âge maximal du cache HTTP | 30 jours | 1 jour | 10 minutes |
Scénario : Mise en cache à long terme (cache, avec retour au réseau)
- Lorsqu'une ressource mise en cache est valide (<= 30 jours) : le service worker renvoie immédiatement la ressource mise en cache sans accéder au réseau.
- Lorsqu'une ressource mise en cache a expiré (> 30 jours) : le service worker accède au réseau pour récupérer la ressource. Le navigateur ne dispose pas d'une copie de la ressource dans son cache HTTP. Il accède donc à la ressource côté serveur.
Inconvénient : dans ce scénario, la mise en cache HTTP offre 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 (ancien pendant la revalidation)
- Lorsqu'une ressource mise en cache est valide (<= 1 jour) : le service worker renvoie immédiatement la ressource mise en cache et accède au réseau pour récupérer la ressource. Le navigateur dispose d'une copie de la ressource dans son cache HTTP. Il renvoie donc cette copie au service worker.
- Lorsqu'une ressource mise en cache a expiré (> 1 jour) : le service worker renvoie immédiatement la ressource mise en cache et accède au réseau pour récupérer la ressource. Le navigateur ne dispose pas d'une copie de la ressource dans son cache HTTP. Il accède donc à la ressource côté serveur.
Inconvénient : le service worker nécessite une invalidation de cache 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 (réseau avec retour au 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 dispose d'une copie de la ressource dans son cache HTTP. Il la renvoie donc au service worker sans accéder au serveur.
- Lorsqu'une ressource mise en cache a expiré (> 10 minutes) : le service worker renvoie immédiatement la ressource mise en cache et accède au réseau pour récupérer la ressource. Le navigateur ne dispose pas d'une copie de la ressource dans son cache HTTP. Il accède donc à la ressource côté serveur.
Inconvénient : comme dans le scénario de mise en cache à moyen terme, le service worker nécessite une logique d'invalidation de cache supplémentaire pour remplacer le cache HTTP afin de récupérer 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 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 en panne.
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 allons à nouveau examiner les scénarios à long terme, à moyen terme et à court terme.
| Scenarios | Mise en cache à long terme | Mise en cache à moyen terme | Mise en cache à court terme |
|---|---|---|---|
| Stratégie de mise en cache des service workers | Cache, avec retour au réseau | Ancien pendant la revalidation | Réseau avec retour au cache |
| TTL du cache du service worker | 90 jours | 30 jours | 1 jour |
| Âge maximal du cache HTTP | 30 jours | 1 jour | 10 minutes |
Scénario : Mise en cache à long terme (cache, avec retour au réseau)
- Lorsqu'une ressource mise en cache est valide dans le cache du service worker (<= 90 jours) : le service worker renvoie immédiatement la ressource mise en cache.
- Lorsqu'une ressource mise en cache a expiré dans le cache du service worker (> 90 jours) : le service worker accède au réseau pour récupérer la ressource. Le navigateur ne dispose pas d'une copie de la ressource dans son cache HTTP. Il accède donc à la ressource 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 dispose d'un contrôle plus précis sur le moment où il doit utiliser son cache et quand demander de nouvelles versions des ressources.
- Inconvénient : une stratégie de mise en cache des service workers bien définie est requise.
Scénario : Mise en cache à moyen terme (ancien pendant la revalidation)
- Lorsqu'une ressource mise en cache est valide dans le cache du service worker (<= 30 jours) : le service worker renvoie immédiatement la ressource mise en cache.
- Lorsqu'une ressource mise en cache a expiré dans le cache du service worker (> 30 jours) : le service worker accède au réseau pour récupérer la ressource. Le navigateur ne dispose pas d'une copie de la ressource dans son cache HTTP. Il accède donc à la ressource 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 prochaine requête pour une URL donnée utilise une réponse fraîche du réseau, grâce à la revalidation qui se produit "en arrière-plan".
- Inconvénient : une stratégie de mise en cache des service workers bien définie est requise.
Scénario : Mise en cache à court terme (réseau avec retour au cache)
- Lorsqu'une ressource mise en cache est valide dans le cache du service worker (<= 1 jour) : le service worker accède au réseau pour récupérer la ressource. Le navigateur renvoie la ressource à partir du cache HTTP si elle s'y trouve. Si le réseau est en panne, le service worker renvoie la ressource à partir du cache du service worker.
- Lorsqu'une ressource mise en cache a expiré dans le cache du service worker (> 1 jour) : le service worker accède 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 une invalidation de cache supplémentaire pour remplacer le cache HTTP et effectuer des requêtes "Network first".
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 qui couvre tous les cas. Toutefois, en fonction des conclusions 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 des service workers 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 vos stratégies de mise en cache pour chaque ressource afin de vous assurer que votre stratégie de mise en cache des service workers apporte de la valeur ajoutée sans entrer en conflit avec le cache HTTP.