Passer au contenu principal

Avantages et inconvénients de l'utilisation d'une logique d'expiration différente ou cohérente dans le cache du service worker et les couches de cache HTTP.

Il apparaît dans:
Fiabilité du réseau

Alors que les techniciens de service et les PWA deviennent la norme pour les applications Web modernes, la mise en cache des ressources est devenue plus complexe que jamais. Cet article couvre la présentation de la mise en cache du navigateur, notamment:

  • Les cas d'utilisation et les différences entre la mise en cache du service worker et la mise en cache HTTP.
  • Avantages et inconvénients des différentes stratégies d'expiration de la mise en cache du service worker par rapport aux stratégies de mise en cache HTTP classiques

Présentation du flux de mise en cache

À un niveau élevé, un navigateur suit l'ordre de mise en cache suivant lors de la demande d'une ressource:

  1. Cache du service worker: Le service worker vérifie si la ressource est 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 planifiées. Veuillez noter que cela ne se produit pas automatiquement. Vous devez créer un gestionnaire d'événements de récupération sur votre service worker et intercepter les demandes réseau afin que les demandes soient servies à partir du cache du service worker au lieu du réseau.
  2. Cache HTTP (également appelé cache du navigateur): Si la ressource est dans le cache HTTP et n'a pas encore expiré, le navigateur utilise automatiquement la ressource du cache HTTP.
  3. Du côté serveur: Si rien n'est trouvé dans le cache de l'agent de service ou dans le cache HTTP, le navigateur se rend sur le réseau pour demander la ressource. Si la ressource n'est pas mise en cache sur un CDN, la demande doit revenir au serveur d'origine.

mise en cache-flow-2211747

igraal_fr-fr

Notez que certains navigateurs comme Chrome ont un Cache couche devant le cache du service worker. Les détails du cache dépendent de l'implémentation de chaque navigateur. Malheureusement, il n'y a toujours pas de spécification claire pour cette partie.

Mise en cache des couches

Mise en cache du service worker

Un technicien de service 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 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 granulaire sur exactement ce qui est mis en cache et comment la mise en cache est effectuée. Cache.

Contrôler le cache du service worker

Un service worker intercepte les requêtes HTTP avec auditeurs d'événements (généralement le aller chercher un événement). Est
extrait de code démontre la logique d'un
Mettre en cache d'abord
stratégie de mise en cache.

boîte de travail-4152333

Il est fortement recommandé d'utiliser Boîte de travail pour éviter de réinventer la roue. Par exemple, vous pouvez
enregistrer les chemins d'URL des ressources avec une seule ligne de code regex.

importer { registerRoute } depuis 'workbox-routing' ;

registerRoute ( new RegExp ( 'styles /.*. css' ) , callbackHandler ) ;

Stratégies de mise en cache et cas d'utilisation de Service Worker

Le tableau suivant décrit les stratégies de mise en cache des agents de service courants et indique à quel moment chaque stratégie est utile.

Stratégies Justification de la fraîcheur Cas d'utilisation
Réseau uniquement Le contenu doit être mis à jour à tout moment.
  • Paiements et paiements
  • Relevés de solde
Réseau recourant au cache Il est préférable de servir le contenu frais. Cependant, si le réseau est en panne ou instable, il est acceptable de proposer un contenu légèrement ancien.
  • Données en temps opportun
  • Prix et frais (nécessite une clause de non-responsabilité)
  • Statuts de commande
Passé en cours de revalidation Il est normal de publier du contenu mis en cache tout de suite, mais le contenu mis à jour en cache devrait être utilisé à l'avenir.
  • Nouvelles
  • Pages de liste de produits
  • messages
Cachez d'abord, allez sur le net Le contenu n'est pas critique et peut être servi à partir du cache pour améliorer les performances, mais le technicien de service doit parfois rechercher des mises à jour.
  • Shell d'application
  • Ressources communes
Cache uniquement Le contenu change rarement.

Avantages supplémentaires de la mise en cache du service worker

En plus du contrôle granulaire 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 source: Le navigateur alloue les ressources de cache HTTP par origine. En d'autres termes, si vous avez plusieurs sous-domaines, ils partagent tous le même cache HTTP. Il n'y a aucune garantie que le contenu de votre origine / domaine restera longtemps dans le cache HTTP. Par exemple, un utilisateur peut purger le cache en effaçant manuellement l'interface utilisateur de configuration d'un navigateur ou en déclenchant un rechargement complet 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. Regarder Stockage persistant Apprendre encore plus.
  • Une plus grande flexibilité avec des réseaux instables ou des expériences hors ligne: Avec le cache HTTP, vous n'avez qu'une seule option binaire: la ressource est mise en cache ou non. Avec la mise en cache des techniciens de service, vous pouvez atténuer les petits «hoquets» beaucoup plus facilement (avec la stratégie «obsolète lors de la revalidation»), offrir une expérience hors ligne complète (avec la stratégie «Cache uniquement»), ou même quelque chose. Intermédiaire, tel que personnalisé UI avec des parties de la page provenant du cache du service worker et certaines parties exclues (à l'aide de la stratégie «Set Capture Handler»), 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, à moins que l'utilisateur final ne l'ait explicitement désactivé.

Utiliser la mise en cache HTTP signifie compter sur le serveur pour déterminer quand mettre en cache une ressource et pendant combien de temps.

Lorsqu'un serveur répond à une demande du navigateur pour une ressource, le serveur utilise des en-têtes de réponse HTTP pour indiquer au navigateur combien de temps mettre en cache la ressource. Voir En-têtes de réponse: configurez votre serveur Web pour plus d'informations.

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 du service worker, car la mise en cache HTTP ne traite que de la logique d'expiration des ressources basée sur le temps (TTL). Voir Quelles valeurs d'en-tête de réponse dois-je utiliser? et Résumé pour plus d'informations sur les stratégies de mise en cache HTTP.

Conception de 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 dans le cache du service worker et les couches de cache HTTP, ainsi que les avantages et les inconvénients d'une logique d'expiration distincte dans ces couches.

L'erreur suivante montre comment la mise en cache du service worker et la mise en cache HTTP fonctionnent dans différents scénarios:

Logique d'expiration cohérente pour toutes les couches de cache

Pour démontrer les avantages et les inconvénients, nous examinerons 3 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, se tournant vers le réseau Passé en cours de revalidation Réseau recourant au cache
Cache TTL 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, aller sur le réseau)

  • Lorsqu'une ressource mise en cache est valide (<= 30 días): el trabajador del servicio devuelve el recurso almacenado en caché inmediatamente sin ir a la red.
  • Lorsqu'une ressource mise en cache expire (> 30 jours): le technicien de service se rend sur le réseau pour trouver la ressource. Le navigateur n'a pas de copie de la ressource dans son cache HTTP, il passe donc au côté serveur pour la ressource.

Inconvénient: dans ce scénario, la mise en cache HTTP fournit moins de valeur car le navigateur transmettra toujours la demande au côté serveur lorsque le cache expirera sur le service worker.

Scénario: mise en cache à moyen terme (obsolète lors de la revalidation)

  • Lorsqu'une ressource mise en cache est valide (<= 1 día): el trabajador del servicio devuelve el recurso en caché inmediatamente y va a la red para buscar el recurso. El navegador tiene una copia del recurso en su caché HTTP, por lo que devuelve esa copia al trabajador del servicio.
  • Lorsqu'une ressource mise en cache expire (> 1 jour): le service worker retourne immédiatement la ressource mise en cache et se rend sur le réseau pour trouver la ressource. Le navigateur n'a pas de copie de la ressource dans son cache HTTP, il va donc côté serveur pour trouver la ressource.

Inconvénient: le service worker nécessite un effacement supplémentaire du cache pour remplacer le cache HTTP afin de tirer pleinement parti de l'étape de «revalidation».

Scénario: mise en cache à court terme (le réseau utilise le cache)

  • Lorsqu'une ressource mise en cache est valide (<= 10 minutos): el trabajador del servicio va a la red para buscar el recurso. El navegador tiene una copia del recurso en su caché HTTP, por lo que se lo devuelve al trabajador del servicio sin pasar al lado del servidor.
  • Lorsqu'une ressource mise en cache expire (> 10 minutes): le service worker retourne immédiatement la ressource mise en cache et se rend sur le réseau pour trouver la ressource. Le navigateur n'a pas de copie de la ressource dans son cache HTTP, il va donc côté serveur pour trouver la ressource.

Inconvénient: similaire au scénario de mise en cache à moyen terme, le service worker a besoin d'une logique de suppression de cache supplémentaire pour remplacer le cache HTTP afin d'obtenir le dernier recours du 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. D'autre part, le cache HTTP n'est pas fiable lorsque le réseau est instable ou en panne.

Différentes logiques d'expiration du cache dans le cache du service worker et les couches HTTP

Pour démontrer les avantages et les inconvénients, nous examinerons à 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, se tournant vers le réseau Passé en cours de revalidation Réseau recourant au cache
Cache TTL 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, aller sur le réseau)

  • Lorsqu'une ressource mise en cache est valide dans le cache du service worker (<= 90 días): el trabajador del servicio devuelve el recurso almacenado en caché inmediatamente.
  • Lorsqu'une ressource mise en cache expire dans le cache du service worker (> 90 jours): le service worker se rend sur le réseau pour trouver la ressource. Le navigateur n'a pas de copie de la ressource dans son cache HTTP, il passe donc du côté serveur.

Avantages et les inconvénients:

  • Avantage: les utilisateurs reçoivent une réponse instantanée lorsque le technicien de service renvoie immédiatement les ressources mises en cache.
  • Avantage: le technicien de service a un contrôle plus granulaire du moment où il doit utiliser son cache et du moment où il doit demander de nouvelles versions de ressources.
  • Inconvénient: une stratégie de mise en cache du service worker bien définie est requise.

Scénario: mise en cache à moyen terme (obsolète lors de la revalidation)

  • Lorsqu'une ressource mise en cache est valide dans le cache du service worker (<= 30 días): el trabajador del servicio devuelve el recurso almacenado en caché inmediatamente.
  • Lorsqu'une ressource mise en cache expire dans le cache du service worker (> 30 jours): le service worker se rend sur le réseau pour la ressource. Le navigateur n'a pas de copie de la ressource dans son cache HTTP, il passe donc du côté serveur.

Avantages et les inconvénients:

  • Avantage: les utilisateurs reçoivent une réponse instantanée lorsque le technicien de service renvoie immédiatement les ressources mises en cache.
  • Avantage: le technicien de service peut s'assurer que Suivant La demande d'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 (réseau recourant à la mise en cache)

  • Lorsqu'une ressource mise en cache est valide dans le cache du service worker (<= 1 día): el trabajador del servicio va a la red en busca del recurso. El navegador devuelve el recurso de la caché HTTP si está allí. Si la red no funciona, el trabajador del servicio devuelve el recurso de la caché del trabajador del servicio.
  • Lorsqu'une ressource mise en cache expire dans le cache du service worker (> 1 jour): le service worker se rend sur le réseau pour trouver la ressource. Le navigateur récupère les ressources sur le réseau lorsque la version mise en cache dans son cache HTTP a expiré.

Avantages et les 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 effacement supplémentaire du cache pour remplacer le cache HTTP et effectuer des requêtes «Network First».

conclusion

Compte tenu de la complexité de la combinaison de scénarios de mise en cache, il n'est pas possible de concevoir une règle qui couvre tous les cas. Cependant, sur la base des résultats des sections précédentes, il y a quelques conseils à garder à l'esprit 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 sur le technicien de service pour lui donner plus de contrôle.
  • La mise en cache HTTP joue toujours un rôle, mais elle n'est pas fiable lorsque le réseau est instable ou en panne.
  • Passez en revue vos stratégies de mise en cache pour chaque ressource pour vous assurer que votre stratégie de mise en cache du service worker fournit sa valeur, sans entrer en conflit avec le cache HTTP.

Apprendre encore plus

Erreur: Attention: Contenu protégé.