Fréquence de mise à jour JavaScript du technicien (toutes les 24 heures?)
Selon ce document sur MDN :
Après cela, il est téléchargé toutes les 24 heures environ. Il peut être téléchargé plus fréquemment, mais il doit être téléchargé toutes les 24 heures pour éviter que les mauvais scripts ne soient gênants trop longtemps.
Est-ce la même chose pour Firefox et Chrome? OR La mise à jour vers JavaScript du service worker ne se produit-elle que lorsque l'utilisateur navigue sur le site?
Remarque: à partir de Firefox 57 , et Chrome 68 , ainsi que les versions de Safari et Edge prenant en charge les opérateurs de service, le comportement par défaut a été modifié pour prendre en compte pour le spécification de prestataire de services mise à jour . Dans ces navigateurs, les directives de cache HTTP seront, par défaut, ignorées lors de la recherche de mises à jour dans le script de l'agent de service. La description ci-dessous s’applique toujours aux versions antérieures de Chrome et Firefox.
Chaque lorsque vous accédez à une nouvelle page se trouvant sous la portée d'un agent de service, Chrome créera une requête HTTP standard pour la ressource JavaScript transmise au serveur navigator.serviceWorker.register() call. Supposons qu'il s'appelle service-worker.js. Cette demande est uniquement faite en conjonction avec une navigation ou lorsqu'un agent du service clientèle est réveillé via, par exemple, un événement Push. Il y a pas un processus d'arrière-plan qui redéfinit chaque script de technicien de maintenance toutes les 24 heures, ou quelque chose d'automatisé de la sorte.
Cette requête HTTP obéira à la norme directives de cache HTTP , à une exception près (voir le paragraphe suivant). Par exemple, si votre serveur a défini les en-têtes de réponse HTTP appropriés indiquant que la réponse en cache doit être utilisée pendant une heure, la requête du navigateur vous demandant service-worker.js sera rempli par le cache du navigateur. Notez que nous ne parlons pas de API de stockage du cache , ce qui n'est pas pertinent dans cette situation, mais plutôt - mise en cache HTTP du navigateur standard .
La seule exception aux règles de mise en cache HTTP standard, et c’est là que l’importance des 24 heures, est que les navigateurs iront toujours vers le réseau si l’âge de la service-worker.js entrée dans le cache HTTP est supérieure à 24 heures. Donc, fonctionnellement, il n'y a aucune différence dans l'utilisation d'un max-age de 1 jour ou 1 semaine ou 1 an - ils seront tous traités comme si le max-age était 1 jour.
Les fournisseurs de navigateurs veulent s'assurer que les développeurs ne déploient pas accidentellement un "cassé" ou un buggy service-worker.js qui est servi avec un max-age sur un an, laissant aux utilisateurs ce qui pourrait être une expérience Web persistante et interrompue pendant une longue période. (Vous ne pouvez pas vous fier à ce que vos utilisateurs sachent effacer les données de leur site ou recharger le site par décalage.)
Certains développeurs préfèrent explicitement servir leur service-worker.js avec des en-têtes de réponse entraînant la désactivation de toute la mise en cache HTTP, ce qui signifie qu'une requête réseau pour service-worker.js est fait pour chaque navigation. Une autre approche pourrait consister à utiliser un très, très court max-age— disons une minute - pour fournir un certain degré de limitation dans le cas où il y aurait un très grand nombre de navigations rapides à partir d'un seul utilisateur. Si vous voulez vraiment minimiser les demandes et êtes certain de ne pas mettre à jour votre service-worker.js à tout moment, vous êtes libre de définir un max-age sur 24 heures, mais je vous conseillerais de prendre quelque chose de plus court au cas où vous auriez inopinément besoin d’un redéploiement.