Cycle de vie d'un service worker
Les phases que traverse un service worker — installation, activation, puis actif (fetch) — avec un mécanisme d'« attente » volontaire : une nouvelle version ne prend la main qu'une fois tous les anciens onglets fermés. Réputé délicat, source classique du « pourquoi ma PWA ne se met-elle pas à jour ? ».
Les phases : install (préparer, par exemple mettre des ressources en cache), activate (nettoyer les anciens caches, prendre le contrôle), puis il tourne et intercepte les requêtes réseau (fetch). Le point délicat : quand on déploie un nouveau service worker, il s'installe mais reste en waiting — il n'est activé qu'une fois fermés tous les onglets contrôlés par l'ancien (pour ne pas remplacer le code sous les pieds d'une application en cours d'exécution). C'est pourquoi les utilisateurs voient souvent une ancienne version tant qu'ils n'ont pas fermé tous leurs onglets. Pour le piloter : skipWaiting() (activer tout de suite le nouveau) et clients.claim() (prendre le contrôle des onglets ouverts), souvent combinés à un message « nouvelle version disponible, recharger ? ». Bien comprendre tout cela est décisif pour des mises à jour de PWA fiables et un cache hors ligne cohérent. À rapprocher de l'API Cache Storage et de Broadcast Channel.