Que permet un service worker, et à quoi feriez-vous attention avant d'en ajouter un ?

Un service worker est un proxy entre la page et le réseau, donc il peut servir des réponses en cache, fonctionner hors ligne, préremplir le cache d'une coquille et gérer la synchronisation en arrière-plan ou le push. La prudence porte sur le cycle de vie : il ne contrôle les pages qu'après activation, un ancien worker continue de servir d'anciens assets jusqu'à son remplacement, et une mauvaise règle de cache peut bloquer les utilisateurs sur un build cassé. Versionnez toujours vos caches et livrez un chemin de mise à jour clair.

Il se place entre la page et le réseau comme un worker séparé, donc il peut intercepter les fetchs et décider de répondre depuis un cache. Ça me donne le support hors ligne, une coquille instantanée aux visites répétées, la synchronisation en arrière-plan pour les actions en file et les notifications push. Ce à quoi je fais attention, c'est le cycle de vie, parce que c'est de là que viennent les incidents. Un nouveau worker s'installe, puis attend que tous les onglets contrôlés soient fermés avant de s'activer, donc les utilisateurs peuvent rester sur de l'ancien code bien plus longtemps qu'on ne l'imagine. Et si je mets le HTML en cache avec une règle cache first et que je livre ensuite un worker cassé, j'ai de fait bloqué les visiteurs qui reviennent, puisqu'ils ne récupèrent jamais le correctif. Donc je versionne les noms de cache et je supprime les anciens à l'activation, je garde le HTML en network first et le cache first seulement pour les assets hachés, et je garde toujours un chemin coupe-circuit qui désinscrit le worker et vide les caches. Si le besoin est seulement la vitesse aux visites répétées et pas un vrai usage hors ligne, je préfère obtenir ça avec des en-têtes de cache et un CDN et éviter toute cette classe de problèmes.