Service Workers : Plongée en profondeur

Service Workers : Les scripts en arrière-plan qui animent les applications Web modernes

Les service workers sont un type spécial de fichier JavaScript qui s'exécute en arrière-plan, séparé de votre page Web. Ils agissent comme un proxy réseau programmable, interceptant les requêtes et décidant comment répondre. C'est ce qui rend possibles des fonctionnalités Web modernes comme le support hors ligne, les notifications push et la synchronisation en arrière-plan.

Comment fonctionnent les Service Workers

Un service worker est enregistré par votre page Web, puis installé dans le navigateur. Une fois installé, il peut intercepter chaque requête réseau effectuée par votre page. Lorsque votre page demande un fichier, le service worker peut le servir à partir du cache, le récupérer depuis le réseau, ou une combinaison des deux. Il peut même créer des réponses personnalisées.

Les service workers s'exécutent dans leur propre thread, complètement séparé de la page principale. Ils n'ont pas accès au DOM, mais ils peuvent communiquer avec la page via des messages. Ils ont également un cycle de vie bien défini : install, activate et fetch. L'événement install est l'endroit où vous mettez en cache les fichiers de votre application. L'événement activate est l'endroit où vous nettoyez les anciens caches. Et l'événement fetch est l'endroit où vous gérez les requêtes.

Stratégies de mise en cache

Le modèle le plus courant consiste à mettre en cache le shell de votre application — le HTML, le CSS et le JavaScript — lors de l'installation. Lorsque l'utilisateur visite, le service worker sert le shell depuis le cache instantanément, puis récupère le contenu frais en arrière-plan. Cela donne à l'utilisateur quelque chose à voir immédiatement, tout en mettant à jour la page lorsque le nouveau contenu arrive.

Pour les images et les réponses API, vous pouvez utiliser une stratégie cache-first : vérifiez le cache, et si le fichier s'y trouve, servez-le immédiatement. Sinon, récupérez-le depuis le réseau et mettez-le en cache pour la prochaine fois. Pour les données critiques qui doivent être fraîches, utilisez une stratégie network-first : essayez d'abord le réseau, et repliez-vous sur le cache si le réseau est indisponible.

Cycle de vie et mises à jour

Les service workers ont un cycle de vie qui peut être délicat à comprendre au début. Lorsqu'un utilisateur visite votre site, si le service worker a changé (ne serait-ce que d'un seul octet), la nouvelle version est installée en arrière-plan. Mais elle ne prend le contrôle que lorsque toutes les pages utilisant l'ancienne version sont fermées. Cela évite les incohérences entre les anciennes et nouvelles versions.

Vous pouvez forcer le nouveau service worker à prendre le contrôle immédiatement en utilisant skipWaiting, et lui demander de réclamer toutes les pages ouvertes avec clients.claim. Mais soyez prudent — cela peut causer des problèmes si la nouvelle version s'attend à des structures de données différentes de l'ancienne.

Au-delà de la mise en cache : Push et Sync

Les service workers permettent deux autres fonctionnalités importantes. Les notifications push permettent au serveur d'envoyer des messages à l'utilisateur même lorsque le site Web n'est pas ouvert. Le service worker reçoit l'événement push, crée une notification, et l'utilisateur la voit. La synchronisation en arrière-plan (background sync) permet au service worker de différer des actions jusqu'à ce que l'utilisateur ait une connexion Internet stable — utile pour des choses comme l'envoi d'un formulaire ou la sauvegarde de modifications.

Les service workers sont une technologie fondamentale pour les applications Web modernes. C'est ce qui donne au Web l'impression d'être une plateforme, et non pas seulement un visualiseur de documents.