Qu'est-ce qu'un Service Worker ?

Qu'est-ce qu'un service worker ?

Un service worker est un fichier JavaScript qui s'exécute en arrière-plan d'une page web, séparé du thread principal du navigateur. Son pouvoir central est d'intercepter et modifier les requêtes réseau faites par la page. Cette seule capacité débloque support offline, push notifications, background sync et performance de chargement répété dramatiquement plus rapide — des fonctionnalités qui requéraient auparavant des apps natives.

Les service workers ont été standardisés en 2015 et expédiés dans Chrome 40, Firefox 44, Safari 11.1 (avec des retards) et Edge depuis le début. Ils sont la fondation des Progressive Web Apps (PWAs) : apps web qui s'installent à l'écran d'accueil, fonctionnent offline et se sentent natives. Même les sites qui ne visent pas à être des PWAs utilisent des service workers pour la performance — cacher des réponses coûteuses, précharger des assets critiques, dédupliquer des appels API.

Ce que les service workers peuvent faire (et ne peuvent pas)

Les service workers s'exécutent dans un contexte spécial avec des capacités et limitations strictes :

Peuvent :

• Intercepter les requêtes réseau. L'événement fetch se déclenche pour chaque requête que la page fait — HTML, CSS, JS, images, appels API. Le worker décide : servir depuis le cache, modifier la requête, aller au réseau ou fallback si offline.
• Cacher des réponses programmatiquement. Les service workers ont accès à la Cache API — un stockage de cache séparé du cache HTTP du navigateur, avec contrôle programmatique explicite.
• Push notifications. Recevoir des messages push d'un serveur même quand la page est fermée, puis afficher des notifications à l'utilisateur.
• Background sync. Différer le travail jusqu'à ce que l'utilisateur ait de la connectivité. Mettre en file les appels API offline, envoyer quand le réseau revient.
• Background fetch. Téléchargements de longue durée qui continuent même après la fermeture de la page.

Ne peuvent pas :

• Accéder au DOM directement. Les service workers s'exécutent dans un contexte séparé. Ils communiquent avec les pages via postMessage uniquement.
• Utiliser des APIs synchrones (XHR sync, localStorage). Environnement async-only. Utilisez fetch et IndexedDB à la place.
• Persister l'état à travers les redémarrages arbitrairement. Le navigateur peut terminer le worker à tout moment où il est idle. Utilisez IndexedDB ou Cache pour l'état, pas les variables de module.
• S'exécuter sur des origines non sécurisées. Les service workers requièrent HTTPS (sauf localhost pour le développement).

Le cycle de vie du service worker (5 étapes)

1. Register. La page appelle navigator.serviceWorker.register('/sw.js'). Le navigateur télécharge le fichier du worker.
2. Install. Le navigateur déclenche l'événement install. Le worker pré-cache typiquement les assets critiques ici.
3. Activate. Le navigateur déclenche l'événement activate. Le worker prend le contrôle des pages à la prochaine navigation (utilisez clients.claim() pour prendre le contrôle immédiatement).
4. Run / gérer les événements. Le worker gère fetch, push, sync, etc. lorsqu'ils se déclenchent. Le navigateur peut terminer le worker entre les événements pour économiser de la mémoire.
5. Update. Quand l'utilisateur revisite, le navigateur vérifie si sw.js a changé (octet par octet). Si oui, la nouvelle version installe mais attend que toutes les pages de l'ancienne version soient fermées avant d'activer. Force-update avec skipWaiting().

Patterns courants de service worker

Cache-first pour les assets statiques

Pour CSS, JS, fonts, images qui changent peu : servir depuis le cache, fallback au réseau, mettre à jour le cache en arrière-plan. La page charge instantanément lors des visites répétées.

Network-first avec fallback cache pour HTML

Pour les pages HTML dynamiques qui doivent être fraîches : essayer le réseau d'abord (avec timeout court), fallback au cache si offline ou lent. L'utilisateur voit du contenu frais en ligne, du contenu caché sinon.

Stale-while-revalidate pour les appels API

Servir la réponse API cachée immédiatement, puis chercher fraîche en arrière-plan et mettre à jour le cache. L'utilisateur voit des données instantanées avec cohérence éventuelle.

Network-only pour les mutations

Les requêtes POST/PUT/DELETE contournent le cache entièrement — elles doivent frapper le réseau ou se mettre en file pour background sync.

Offline-first avec shell + contenu dynamique

Pré-cacher le shell de l'app (HTML, CSS, bundle JS) à l'install. Récupérer le contenu dynamique du réseau avec fallback cache. Le site fonctionne entièrement offline pour le contenu caché, dégrade gracieusement pour le contenu nouveau.

Service workers et Core Web Vitals

Les service workers peuvent dramatiquement améliorer les Core Web Vitals lors des visites répétées — mais à la première visite, ils ajoutent un petit overhead (enregistrer le worker, charger sw.js). Implications :

• LCP s'améliore dramatiquement aux visites répétées. Les images hero pré-cachées et le CSS critique chargent instantanément.
• FCP s'améliore aux visites répétées. Le shell HTML pré-caché rend avant le roundtrip réseau.
• Le coût de la première visite est réel. Enregistrer et installer le worker, pré-cacher des assets, parser du JavaScript additionnel — tout ajoute du coût lors de la première session. Ne sur-ingénierez pas.
• CLS non affecté. Les service workers n'impactent pas la stabilité du layout dans aucun sens.
• INP peut s'améliorer. Les réponses interactives pré-cachées (ex. suggestions de recherche cachées) réduisent la latence de roundtrip serveur lors des interactions utilisateur.

Service workers vs autres couches de cache

Les apps web modernes ont plusieurs couches de cache. Les service workers se placent à un endroit spécifique :

• Cache HTTP du navigateur : Implicite, contrôlé par les headers Cache-Control. Le navigateur décide quoi cacher et quand. Pas de contrôle JavaScript.
• Cache API du Service Worker : Explicite, contrôlé par JS. Survit aux rechargements de page. Contrôle programmatique sur quoi cacher et servir.
• Cache CDN : Serveurs edge. Rapide mais partagé entre tous les utilisateurs. Mises à jour via invalidation de cache.
• HTTP/2 push (déprécié) : Le serveur push des ressources. Retiré de Chrome en 2022 parce qu'il ne surpassait pas les service workers.

FAQ : Service Workers

Ai-je besoin d'un service worker pour mon site ?

Si votre site est content-heavy et les utilisateurs reviennent souvent, oui — les gains de performance en visite répétée sont importants. Si les utilisateurs visitent une fois et ne reviennent jamais, l'overhead de première visite peut ne pas compenser. Les sites purement marketing avec faibles taux de retour ne bénéficient pas nécessairement.

Quelle est la différence entre un service worker et un web worker ?

Les deux s'exécutent dans des threads en arrière-plan. Les web workers gèrent du travail CPU-bound en parallèle du thread principal (traitement d'image, calcul). Les service workers interceptent spécifiquement les requêtes réseau et persistent à travers les chargements de page. APIs différentes, cycles de vie différents.

Pourquoi les mises à jour de service worker prennent-elles si longtemps à déployer ?

Par défaut, une nouvelle version de worker installe mais attend que TOUTES les pages exécutant l'ancienne version soient fermées avant d'activer. Pour les utilisateurs avec le site ouvert dans un onglet pour toujours, cela peut être des jours. Force-update avec skipWaiting() dans le handler install — mais attention, peut causer des mismatchs d'assets et de code en milieu de session.

Comment déboguer un service worker ?

Chrome DevTools → Application → Service Workers montre les workers enregistrés, l'état actuel, les erreurs. L'onglet Network montre quelles requêtes ont été servies depuis le cache du SW (cherchez la petite icône de roue dentée). Les audits Lighthouse incluent les vérifications PWA / service worker.

Les service workers fonctionnent-ils dans Safari ?

Oui, depuis iOS 11.3 / Safari 11.1. L'implémentation a été plus faible historiquement (background sync retardé, push notifications limitées jusqu'à iOS 16.4). Testez toujours les fonctionnalités PWA sur du vrai Safari, pas seulement Chrome.

Un service worker peut-il casser mon site ?

Oui, facilement. Un worker buggy qui retourne toujours des réponses cachées (même obsolètes) crée une UX cassée en permanence dont il est difficile de récupérer — les utilisateurs ne verront pas les fixes jusqu'à ce que le worker se mette à jour. Incluez toujours un kill switch : une vérification qui désactive le worker sur un flag que votre serveur contrôle.

Comment LoadFocus mesure l'impact du service worker

LoadFocus exécute des tests de vitesse de page basés sur Lighthouse depuis de vraies instances Chrome dans 25+ régions, capturant les métriques de première visite et visite répétée séparément. L'efficacité du service worker se manifeste comme un grand écart entre le LCP de chargement froid et chargement chaud. Planifiez des audits pour valider que le worker fonctionne réellement en production — les enregistrements de service worker cassés sont un tueur silencieux qui n'apparaît pas dans les runs Lighthouse de page unique.