Déployer un service worker en toute sécurité : portée, caches versionnés, worker en attente et interrupteur d'arrêt

Objectif

Ajouter une mise en cache hors ligne à un site sans l'échec classique : un worker obsolète continue de servir d'anciens HTML et assets après un déploiement, ou un worker défectueux ne peut pas être remplacé parce qu'il sert son propre script depuis le cache.

Prérequis

HTTPS (MDN : les service workers ne s'exécutent que sur des origines sécurisées, localhost étant autorisé), un build qui produit des noms de fichiers d'assets hachés selon leur contenu, et le cycle de vie tel que décrit par le guide MDN : un nouveau worker s'installe en arrière-plan, attend qu'aucune page n'utilise plus l'ancien, puis s'active ; skipWaiting() et clients.claim() permettent de raccourcir cette attente.

Étapes

1. Effectuer l'enregistrement depuis un seul endroit avec une scope explicite (/ pour l'origine entière ; le script doit être servi à ce chemin ou au-dessus, sauf si le serveur envoie Service-Worker-Allowed), et servir le script du worker avec Cache-Control: no-cache. Passer updateViaCache: "none" pour que le script et ses imports contournent le cache HTTP lorsque le navigateur vérifie les mises à jour.
2. Nommer les caches avec une chaîne qui change à chaque build (static-<git-sha>) ; dans activate, supprimer tout cache dont le nom n'est pas le nom courant, comme dans l'exemple de nettoyage de cache du guide, et n'appeler clients.claim() qu'ensuite.
3. Choisir une stratégie par classe de ressource : cache-first pour les assets immuables hachés ; network-first avec repli sur le cache pour les navigations HTML et les données d'API ; jamais cache-first pour du HTML non haché.
4. Ne précharger dans install que la coquille applicative (app shell), et garder la liste courte : cache.addAll() rejette avec un TypeError si une réponse sort de la plage 200, ce qui fait échouer toute l'installation.
5. Décider comment les mises à jour prennent effet. Le comportement par défaut (activation à la fermeture du dernier onglet ancien) est le plus sûr pour la cohérence. En cas d'appel à skipWaiting(), afficher une invite « nouvelle version disponible, recharger » plutôt que de laisser un nouveau worker servir silencieusement de nouveaux assets à d'anciennes pages.
6. Construire l'interrupteur d'arrêt avant la première mise en production : une version de worker dont activate supprime tous les caches et appelle self.registration.unregister(), ainsi qu'un moyen documenté de le déployer en quelques minutes.
7. Répéter le chemin de mise à jour en préproduction : déployer, recharger deux fois, confirmer que la nouvelle version est active et que les anciens caches ont disparu ; puis déployer l'interrupteur d'arrêt et confirmer que le worker disparaît.

Résultat attendu

Chaque déploiement remplace les caches en un seul cycle de mise à jour, les utilisateurs ne chargent jamais un mélange d'ancien HTML et de nouveaux assets, et un worker défectueux peut être retiré sans attendre l'expiration du cache ni une action de l'utilisateur.

Limites et base de vérification

Le comportement suit les pages MDN citées ; le calendrier de vérification des mises à jour par le navigateur et les règles d'éviction du stockage ne sont pas garantis. Les écritures hors ligne (requêtes mises en file d'attente, synchronisation en arrière-plan) relèvent d'une conception distincte. La mise en cache d'origines tierces ajoute des réponses opaques qui ne peuvent pas être inspectées pour y détecter des erreurs.

Un délai sur les navigations network-first

Network-first ne se rabat sur le cache que lorsque la requête échoue, et sur une connexion présente mais bloquée, la requête n'échoue qu'au bout du délai propre au navigateur ; l'utilisateur attend donc devant une page blanche alors qu'une copie en cache existe. Borner l'attente : démarrer la requête réseau et, si elle n'a pas répondu dans un délai court et documenté, répondre avec le HTML en cache et laisser la copie fraîche arriver à la navigation suivante (la stratégie NetworkFirst de Workbox expose cela via networkTimeoutSeconds). Associer cela au préchargement de navigation (registration.navigationPreload.enable()) pour que la requête réseau démarre en parallèle du démarrage du worker plutôt qu'après celui-ci. Dans tous les cas, les noms d'assets hachés maintiennent la cohérence entre le HTML servi et ses propres assets.