Qu’est-ce qu’un Service Worker et votre site en a-t-il besoin ?

Un Service Worker est un script JavaScript que le navigateur installe pour un site et exécute en arrière-plan, séparément de la page. Il se place entre le site et le réseau, comme un proxy programmable : il intercepte les requêtes, peut répondre depuis un cache local, et permet ainsi le fonctionnement hors ligne, des visites répétées plus rapides, les notifications push et l’installation d’un site comme une application (PWA). Il n’est disponible qu’en HTTPS et il est pris en charge par tous les navigateurs majeurs depuis 2018.

Les Service Workers sont au cœur des applications web progressives, mais ils sont aussi une source classique de bugs de cache quand ils sont mal configurés. On explique ici ce qu’est un worker, le cycle de vie d’un Service Worker, les stratégies de cache à connaître, ce qu’ils permettent aujourd’hui selon les navigateurs, et dans quels cas un site d’entreprise en a réellement besoin.

• Qu’est-ce qu’un Service Worker ?
• Qu’est-ce qu’un worker, et en quoi le Service Worker est-il différent ?
• Comment fonctionne un Service Worker ?
• Quelles stratégies de cache utiliser ?
• À quoi sert un Service Worker concrètement ?
• Quels navigateurs prennent en charge les Service Workers ?
• Votre site a-t-il besoin d’un Service Worker ?
• Quelles erreurs éviter ?
• Questions fréquentes
• Sources

Qu’est-ce qu’un Service Worker ?

La documentation de référence MDN (Mozilla) décrit les Service Workers comme des serveurs proxy placés entre l’application web, le navigateur et le réseau. Concrètement, c’est un fichier JavaScript (souvent nommé sw.js) que votre site demande au navigateur d’enregistrer. Une fois installé, il reçoit un événement à chaque requête émise par les pages qu’il contrôle, et décide quoi en faire : laisser passer la requête vers le serveur, répondre avec une copie en cache, ou construire une réponse lui-même.

Ses caractéristiques principales, telles que les décrit MDN :

• il s’exécute dans un fil d’exécution séparé de la page et n’a pas accès au DOM (il ne peut pas modifier directement le contenu affiché) ;
• il est entièrement asynchrone : les API synchrones comme localStorage lui sont interdites ;
• il ne fonctionne que dans un contexte sécurisé, c’est-à-dire en HTTPS, avec une exception pour http://localhost afin de faciliter le développement. La raison est simple : un script capable d’intercepter toutes les requêtes serait une arme redoutable entre les mains d’un attaquant placé sur le réseau. Notre article sur le HTTPS explique ce que garantit ce protocole ;
• il ne tourne pas en permanence : le navigateur le réveille quand un événement le concerne et l’arrête quand il est inactif.

Qu’est-ce qu’un worker, et en quoi le Service Worker est-il différent ?

En informatique, un worker est un processus ou un fil d’exécution qui travaille pour le compte d’un autre. Dans le navigateur, JavaScript s’exécute par défaut sur le fil principal, celui qui gère aussi l’affichage et les clics : un calcul lourd y bloque toute la page. Les workers permettent de déporter du travail ailleurs. Il en existe trois familles :

Type	Rôle	Durée de vie
Web Worker (dedicated worker)	Exécuter un calcul lourd sans figer la page	Celle de la page qui l’a créé
Shared Worker	Partager un même traitement entre plusieurs onglets du même site	Tant qu’un onglet l’utilise
Service Worker	Intercepter les requêtes réseau, gérer le cache, recevoir des notifications	Indépendante des pages : il reste installé et se réveille sur événement

C’est cette indépendance qui rend le Service Worker particulier : il peut agir alors qu’aucun onglet du site n’est ouvert, par exemple pour afficher une notification push.

Comment fonctionne un Service Worker ?

Un Service Worker suit un cycle de vie précis, en quatre temps.

1. L’enregistrement

La page demande au navigateur d’enregistrer le script :

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

Le Service Worker contrôle alors les pages situées dans sa portée (scope). Par défaut, c’est le dossier où se trouve le script : placé à la racine (/sw.js), il contrôle tout le site ; placé dans /boutique/sw.js, seulement cette section. Un en-tête HTTP Service-Worker-Allowed permet d’élargir la portée si besoin.

2. L’installation

Le navigateur télécharge le script et déclenche l’événement install. C’est le moment de mettre en cache les fichiers indispensables (page hors ligne, feuilles de style, logo) :

const CACHE = 'site-v1';

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE).then((cache) =>
      cache.addAll(['/', '/hors-ligne.html', '/style.css'])
    )
  );
});

3. L’attente puis l’activation

Si une ancienne version du Service Worker contrôle encore des onglets ouverts, la nouvelle reste en attente (état « waiting ») jusqu’à ce qu’aucun onglet n’utilise plus l’ancienne. Ce mécanisme évite que deux versions du site cohabitent. La méthode self.skipWaiting() permet de sauter cette attente, et clients.claim() de prendre immédiatement le contrôle des pages ouvertes, mais le guide de Google sur le cycle de vie prévient qu’une page chargée avec l’ancienne version peut alors se retrouver servie par la nouvelle, avec des incohérences. L’événement activate sert en général à supprimer les anciens caches.

4. L’interception des requêtes

Une fois actif, le Service Worker reçoit un événement fetch pour chaque requête des pages qu’il contrôle, et y répond avec event.respondWith() :

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((reponse) =>
      reponse || fetch(event.request)
    )
  );
});

Côté mises à jour, le navigateur vérifie le script lorsque l’utilisateur navigue sur une page de la portée, avec au plus une vérification toutes les 24 heures déclenchée par des événements en arrière-plan. Le Service Worker n’est réinstallé que si le fichier a changé, ne serait-ce que d’un octet.

Quelles stratégies de cache utiliser ?

Le code ci-dessus applique une seule stratégie à tout le site, ce qui est rarement une bonne idée. On choisit plutôt une stratégie par type de ressource. Ce sont les cinq stratégies proposées par Workbox, la bibliothèque de Google qui simplifie l’écriture des Service Workers :

Stratégie	Principe	Pour quoi
Cache first	Le cache d’abord, le réseau si absent	Polices, images, fichiers versionnés qui ne changent jamais
Network first	Le réseau d’abord, le cache en secours hors ligne	Pages HTML, contenus qui doivent être à jour
Stale while revalidate	Réponse immédiate depuis le cache, mise à jour en arrière-plan pour la prochaine fois	Avatars, fichiers CSS et JS non versionnés, réponses d’API peu sensibles
Network only	Toujours le réseau, jamais de cache	Panier, paiement, espace connecté, formulaires
Cache only	Toujours le cache	Fichiers mis en cache à l’installation (page hors ligne)

Le cache du Service Worker (l’API Cache Storage) s’ajoute au cache HTTP du navigateur et au cache côté serveur. Pour une vue d’ensemble de ces niveaux, voir notre article sur le cache d’un site internet.

À quoi sert un Service Worker concrètement ?

• Fonctionner hors ligne ou sur un réseau instable : afficher les pages déjà consultées, une page « vous êtes hors ligne » soignée plutôt que l’erreur du navigateur, ou une application métier utilisable sur un chantier sans réseau.
• Accélérer les visites répétées : les ressources servies depuis le cache local n’attendent pas le réseau. Le gain concerne surtout les visiteurs qui reviennent, pas la toute première visite, qui dépend toujours des optimisations classiques mesurées par les Core Web Vitals.
• Recevoir des notifications push, même quand le site n’est pas ouvert. Sur iPhone et iPad, c’est possible depuis iOS et iPadOS 16.4, uniquement pour une application web ajoutée à l’écran d’accueil, avec un manifeste et une demande d’autorisation déclenchée par l’utilisateur, d’après l’annonce de WebKit en février 2023.
• Différer un envoi jusqu’au retour du réseau, avec l’API Background Synchronization. MDN la signale toutefois comme non « Baseline » : elle ne fonctionne pas dans tous les navigateurs courants, il faut donc prévoir une solution de repli.
• Rendre un site installable comme une application : c’est l’une des briques des Progressive Web Apps, avec le manifeste web.

Quels navigateurs prennent en charge les Service Workers ?

La question qui se posait en 2020 est réglée. Chrome et Firefox les géraient depuis plusieurs années quand Apple les a activés par défaut dans Safari 11.1, sorti le 29 mars 2018 ; depuis, tous les navigateurs majeurs les prennent en charge, sur ordinateur comme sur mobile. Les différences portent désormais sur les fonctions annexes (synchronisation en arrière-plan, conditions des notifications push), pas sur le Service Worker lui-même.

Pour voir les Service Workers installés sur un site, ouvrez les outils de développement de Chrome ou Edge (F12), onglet « Application », rubrique « Service workers » : vous pouvez y forcer une mise à jour, simuler le mode hors ligne ou désinscrire le script. La page chrome://serviceworker-internals liste tous ceux installés dans le navigateur.

Votre site a-t-il besoin d’un Service Worker ?

Pas forcément, et c’est une réponse qu’on donne souvent. Un Service Worker ajoute une couche de cache à maintenir, et un bug dans ce script peut servir une version périmée du site à vos visiteurs pendant des jours. Il se justifie quand il apporte une fonction réelle :

• Oui pour une application web utilisée au quotidien (outil métier, espace client, application terrain), une PWA que les utilisateurs installent, un média qui veut envoyer des notifications, ou un service utilisé dans des zones mal couvertes.
• Rarement pour un site vitrine consulté une ou deux fois par visiteur : le gain de performance est faible, et le cache HTTP bien réglé, un CDN et des images optimisées font l’essentiel du travail.
• Avec prudence pour une boutique en ligne : les pages produits peuvent en profiter, mais panier, compte et paiement doivent toujours passer par le réseau.

Sur WordPress, certaines extensions de performance ou de PWA installent un Service Worker à votre insu : vérifiez dans l’onglet « Application » des outils de développement ce qui tourne réellement sur votre site. Quand on conçoit des applications web sur mesure, le Service Worker fait partie des choix d’architecture qu’on arbitre au cas par cas, en fonction des usages hors ligne réels.

Quelles erreurs éviter ?

• Mettre en cache sans versionner : sans nom de cache versionné (site-v1, site-v2) et sans nettoyage à l’activation, les anciens fichiers s’accumulent et peuvent être servis indéfiniment.
• Mettre en cache des pages personnalisées : un panier, un compte client ou une page contenant un jeton de sécurité ne doivent jamais être servis depuis le cache.
• Abuser de skipWaiting : activer la nouvelle version en plein milieu d’une session peut mélanger ancien HTML et nouveaux scripts.
• Donner une portée trop large : un Service Worker placé à la racine contrôle tout le domaine, y compris des sections qui n’ont rien à voir (back-office, sous-dossiers d’autres applications).
• Oublier le plan de retrait : pour supprimer un Service Worker, il ne suffit pas d’effacer le fichier. Il faut publier une version qui se désinscrit ou appeler unregister() depuis les pages, sinon les navigateurs déjà équipés le garderont.

Questions fréquentes

Quelle différence entre un Service Worker et une PWA ?

Le Service Worker est une technologie, la PWA un type d’application. Une Progressive Web App s’appuie généralement sur un Service Worker (pour le hors ligne et les notifications) et sur un manifeste web (pour l’installation et l’icône).

Un Service Worker améliore-t-il le référencement ?

Pas directement. Il peut accélérer les visites répétées, donc l’expérience des visiteurs fidèles, mais il n’intervient pas dans la première visite ni dans l’exploration par les robots des moteurs de recherche. Le contenu doit rester accessible sans lui.

Pourquoi le HTTPS est-il obligatoire ?

Parce qu’un Service Worker peut intercepter et modifier toutes les requêtes du site. En HTTP simple, un attaquant présent sur le réseau pourrait injecter son propre script. Seul localhost est exempté, pour le développement.

Comment supprimer un Service Worker de mon navigateur ?

Dans Chrome ou Edge, ouvrez les outils de développement (F12), onglet « Application », rubrique « Service workers », puis cliquez sur « Unregister ». Effacer les données du site dans les paramètres du navigateur le supprime aussi.

Faut-il écrire son Service Worker à la main ?

Pour un besoin simple, quelques dizaines de lignes suffisent. Dès qu’il faut combiner plusieurs stratégies de cache et gérer les mises à jour proprement, une bibliothèque comme Workbox évite beaucoup d’erreurs.

Sources

• MDN : API Service Worker
• MDN : ServiceWorkerContainer.register() et portée
• web.dev (Google) : le cycle de vie d’un Service Worker
• Chrome for Developers : Workbox
• WebKit : nouveautés de Safari 11.1
• WebKit : Web Push pour les applications web sur iOS et iPadOS (février 2023)
• MDN : Background Synchronization API