Cette page a été traduite par l'API Cloud Translation.

Service workers plus récents par défaut

Jeff Posnick

Résumé

À partir de Chrome 68, les requêtes HTTP qui recherchent les mises à jour du script de service worker ne seront plus ne peut plus être traitée par le cache HTTP par défaut. Cela permet de contourner une difficulté courante des développeurs, En définissant un en-tête Cache-Control par inadvertance dans votre script de service worker, aux mises à jour retardées.

Si vous avez déjà désactivé la mise en cache HTTP pour votre script /service-worker.js en le diffusant avec Cache-Control: max-age=0, vous ne devriez constater aucun changement en raison de la nouvelle valeur par défaut comportemental.

De plus, à partir de Chrome 78, la comparaison octet par octet sera aux scripts chargés dans un service worker via importScripts() Toute modification apportée à un script importé déclenche l'événement flux de mise à jour d'un service worker, comme le ferait un service worker de premier niveau.

Contexte

Chaque fois que vous accédez à une nouvelle page relevant du champ d'application d'un service worker, appelez explicitement registration.update() depuis JavaScript, ou lorsqu'un service worker est activé via un événement push ou sync, le navigateur demande en parallèle la ressource JavaScript qui a été initialement transmise à la navigator.serviceWorker.register(), pour rechercher des mises à jour du script de service worker.

Pour les besoins de cet article, supposons que son URL est /service-worker.js et qu'elle contient un seul appel à importScripts(), qui charge le code supplémentaire exécuté à l'intérieur du service worker:

// Inside our /service-worker.js file:
importScripts('path/to/import.js');

// Other top-level code goes here.

Ce qui change

Avant Chrome 68, la requête de mise à jour de /service-worker.js était effectuée via le cache HTTP (comme la plupart des récupérations). Autrement dit, si le script était initialement envoyé avec Cache-Control: max-age=600, les mises à jour effectuées dans les 600 secondes (10 minutes) suivantes n'étaient pas transmises au réseau. il se peut que l'utilisateur ne reçoive pas la version la plus récente du service worker. Toutefois, si max-age était supérieure à 86 400 (24 heures), elle est traitée comme s'il s'agissait de 86 400, pour éviter que les utilisateurs soient bloqués toujours avec une version particulière.

À partir de 68, le cache HTTP sera ignoré lors de la demande de mises à jour du service worker Il est donc possible que les applications Web existantes augmentent la fréquence des requêtes script de service worker. Les requêtes destinées à importScripts seront toujours traitées par le cache HTTP. Mais c'est Seulement la valeur par défaut : une nouvelle option d'enregistrement (updateViaCache) est disponible et vous permet de contrôler ce comportement.

updateViaCache

Les développeurs peuvent désormais transmettre une nouvelle option lors de l'appel de navigator.serviceWorker.register(): le paramètre updateViaCache. Il accepte l'une des trois valeurs suivantes: 'imports', 'all' ou 'none'.

Les valeurs déterminent si et comment le cache HTTP standard du navigateur entre en jeu lors de la requête HTTP pour vérifier les ressources de service worker mises à jour.

Si la valeur est 'imports', le cache HTTP n'est jamais consulté lors de la recherche de mises à jour du /service-worker.js, mais sera consulté lors de la récupération de scripts importés (path/to/import.js, dans notre exemple). Il s'agit du comportement par défaut, qui correspond au comportement dans Chrome 68.
Si la valeur est 'all', le cache HTTP est consulté lors des requêtes pour les le script /service-worker.js de premier niveau, ainsi que tous les scripts importés à l'intérieur du service, , comme path/to/import.js. Cette option correspond au comportement précédent dans Chrome, antérieures à Chrome 68.
Si la valeur est 'none', le cache HTTP n'est pas consulté lors des requêtes pour les /service-worker.js de premier niveau ou pour tout script importé, comme le scénario path/to/import.js

Par exemple, le code suivant enregistre un service worker et garantit que le cache HTTP est n'a jamais été consulté lors de la recherche de mises à jour du script /service-worker.js ou de toute scripts référencés via importScripts() dans /service-worker.js:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/service-worker.js', {
    updateViaCache: 'none',
    // Optionally, set 'scope' here, if needed.
  });
}

Recherche de mises à jour des scripts importés

Avant Chrome 78, tout script de service worker chargé via importScripts() sont récupérées une seule fois (en commençant par les vérifications dans le cache HTTP ou via le en fonction de la configuration updateViaCache). Après cette date, sont stockées en interne par le navigateur et ne sont jamais récupérées.

Le seul moyen de forcer un service worker déjà installé à récupérer les modifications d'un script importé consistait à modifier son URL, généralement en ajoutant un élément semver value (par exemple, importScripts('https://example.com/v1.1.0/index.js')) ou en incluant un hachage de le contenu (par exemple, importScripts('https://example.com/index.abcd1234.js')). A Si vous modifiez l'URL importée, cela signifie que le service worker de premier niveau du contenu du script change, ce qui déclenche flux de mise à jour d'un service worker.

À partir de Chrome 78, chaque fois qu'une recherche de mise à jour est effectuée pour un fichier de service worker, les vérifications seront effectuées en même temps pour déterminer si ou non, le contenu des scripts importés a changé. En fonction du Cache-Control en-têtes utilisés, ces vérifications de script importé peuvent être effectuées par le cache HTTP si updateViaCache est défini sur 'all' ou 'imports' (qui est la valeur par défaut), ou les vérifications peuvent aller directement au réseau La valeur de updateViaCache est 'none'.

Si une vérification de mise à jour d'un script importé entraîne une différence octet par octet par rapport à ce qui était précédemment stocké par le service worker, qui à son tour déclencher le flux complet de mise à jour du service worker, même si le service de niveau supérieur le fichier de nœud de calcul reste le même.

Le comportement de Chrome 78 correspond à celui implemented par Firefox. il y a plusieurs années, dans Firefox 56. Safari implémente déjà ce comportement bien.

Que doivent faire les développeurs ?

Si vous avez désactivé la mise en cache HTTP pour votre script /service-worker.js en le diffusant avec Cache-Control: max-age=0 (ou une valeur similaire), vous ne devriez constater aucun changement dû à le nouveau comportement par défaut.

Si vous diffusez votre script /service-worker.js avec la mise en cache HTTP activée, de manière intentionnelle ou parce qu'il s'agit simplement de la valeur par défaut de votre environnement d'hébergement, il se peut que vous constatiez une augmentation des requêtes HTTP supplémentaires pour /service-worker.js effectuées sur de votre serveur : il s'agit de requêtes qui étaient traitées par le cache HTTP. Si vous souhaitez continuez, en autorisant la valeur d'en-tête Cache-Control à influencer l'actualisation /service-worker.js, vous devez commencer par définir explicitement updateViaCache: 'all' lorsque à l'enregistrement de votre service worker.

Étant donné qu'il peut y avoir une longue traîne d'utilisateurs sur d'anciennes versions de navigateur, il est toujours judicieux continuez à définir l'en-tête HTTP Cache-Control: max-age=0 sur les scripts de service worker, même si les navigateurs plus récents pourraient les ignorer.

Les développeurs peuvent profiter de cette opportunité pour décider s'ils souhaitent explicitement activer sortir de la mise en cache HTTP et ajouter updateViaCache: 'none' à son service worker l'enregistrement si nécessaire.

Diffuser des scripts importés

À partir de Chrome 78, les développeurs verront peut-être plus de requêtes HTTP entrantes pour de ressources chargées via importScripts(), car elles seront désormais vérifiées mises à jour.

Si vous souhaitez éviter ce trafic HTTP supplémentaire, définissez En-têtes Cache-Control lors de l'inférence de scripts incluant le code semver ou des hachages dans leurs URL et reposent sur le comportement updateViaCache par défaut de 'imports'.

Si vous souhaitez que les scripts importés soient vérifiés des mises à jour, puis veillez à les diffuser avec Cache-Control: max-age=0, ou que vous utilisez updateViaCache: 'none'.

Documentation complémentaire

"Cycle de vie des service workers" et "Mise en cache des meilleures pratiques et max-age Pièges", par Jake Archibald, sont recommandés pour tous les développeurs qui déploient quelque chose sur le Web.