Avantages et inconvénients de l'utilisation d'une logique d'expiration cohérente ou différente entre les couches de cache du service worker et 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:
- Découvrez les cas d'utilisation de la mise en cache des service workers et la mise en cache HTTP, et les différences qui existent entre elles.
- Avantages et inconvénients des différentes stratégies d'expiration de la mise en cache de service worker 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:
- Cache du service worker : le service worker vérifie si la ressource se trouve dans son cache et décide de 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 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 est trouvée dans le cache HTTP et qu'elle n'a pas encore expiré, le navigateur utilise automatiquement la ressource à 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, la requête doit remonter jusqu'au serveur d'origine.
Mise 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 du service worker et le cache HTTP ont la même finalité générale, mais le cache du service worker offre davantage de fonctionnalités de mise en cache, telles qu'un contrôle précis de ce qui est mis en cache et de 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 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 et cas d'utilisation de la mise en cache des services workers
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 est défaillant ou instable, il est acceptable de diffuser du contenu légèrement ancien. |
|
| Obsolète pendant la revalidation | Vous pouvez diffuser du contenu mis en cache immédiatement, mais vous devriez utiliser du contenu mis en cache mis à jour à l'avenir. |
|
| Cacher d'abord, puis utiliser le 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 vérifier de temps en temps les mises à jour. |
|
| Mettre en 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 du service worker fournit également :
- Plus de mémoire et d'espace de stockage pour votre origine : le navigateur alloue des ressources de cache HTTP 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. qui déclenche une actualisation forcée 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. Voir la section Persistant stockage pour en savoir plus.
- Flexibilité accrue 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 le stockage en cache du service worker, vous pouvez atténuer les petits "à-coups" beaucoup plus facilement (avec la stratégie "stale-while-revalidate"), proposer une expérience hors connexion complète (avec la stratégie "Cache only") ou même quelque chose entre les deux, comme des UI personnalisées avec des parties de la page provenant du cache du service worker et d'autres parties exclues (avec la stratégie "Set catch handler") 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 les stocke dans son cache HTTP. Le cache HTTP est généralement activé automatiquement par les navigateurs, sauf s'il a été désactivé explicitement par l'utilisateur final.
L'utilisation de la mise en cache HTTP signifie que vous devez vous fier au serveur pour déterminer quand mettre en cache une ressource et pendant combien de temps.
Contrôler l'expiration du cache HTTP avec les 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. Pour en savoir plus, consultez En-têtes de réponse : configurer votre serveur Web.
Stratégies et cas d'utilisation de la mise en cache HTTP
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). Pour en savoir plus sur les stratégies de mise en cache HTTP, consultez les pages Quelles valeurs d'en-tête de réponse devez-vous utiliser ? et Récapitulatif.
Concevoir votre logique d'expiration du cache
Cette section explique les avantages et les inconvénients d'utiliser une logique d'expiration cohérente entre les couches de cache du service worker et de cache HTTP, ainsi que les avantages et les inconvénients d'une logique d'expiration distincte entre ces 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 du service worker | Cache, puis 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 immédiatement la ressource mise en cache sans accéder au 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, le cache HTTP est moins utile, car le navigateur transmettra toujours la requête côté serveur lorsque le cache expirera dans le service worker.
Scénario : Mise en cache à moyen terme (obsolète pendant la validation)
- 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 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 n'a pas de 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 une suppression de cache supplémentaire pour remplacer le cache HTTP afin de tirer le meilleur parti de l'étape "révalidation".
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 dispose d'une copie de la ressource dans son cache HTTP. Il la renvoie donc au service worker sans passer côté 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 récupère 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 de suppression de cache supplémentaire pour remplacer le cache HTTP afin d'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 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 en panne.
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 allons à nouveau examiner 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, puis 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 worker renvoie immédiatement la ressource mise en cache.
- Lorsqu'une ressource mise en cache expire dans le cache du service worker (> 90 jours) : le service worker accède au réseau pour récupérer la ressource. 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, 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 de ressources.
- Inconvénient: une stratégie bien définie de mise en cache de service worker est requise.
Scénario : Mise en cache à moyen terme (obsolète pendant la validation)
- 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 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, 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 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 du service worker bien définie 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 réseau, car la version mise en cache dans son cache HTTP est expirée.
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 suppression de cache supplémentaire pour remplacer le cache HTTP et effectuer des requêtes "Network first".
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 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 service worker fournit sa valeur, sans entrer en conflit avec le cache HTTP.