Les service workers permettent aux applications web de fonctionner sans connexion réseau, mais beaucoup de développeurs les implémentent de façon superficielle. Enregistrer un service worker et mettre en cache quelques ressources ne suffit pas : il faut une stratégie cohérente, testée, et maintenue.
Enregistrement et cycle de vie
Commencez par enregistrer le worker dans votre script principal, idéalement en production seulement. Utilisez navigator.serviceWorker.register() avec un chemin relatif à votre racine web. Le navigateur télécharge le fichier service-worker.js, l'exécute dans un contexte isolé, et attend les événements install et activate . Pendant install , précachez les ressources critiques (HTML shell, CSS, JS). Pendant activate , nettoyez les anciens caches. Ne bloquez pas sur install avec waitUntil() trop longtemps—préférez un préchargage progressif.
Stratégies de cache : au-delà du basique
La stratégie « cache first, network fallback » convient aux assets statiques (images, fonts) : le service worker sert d'abord le cache, puis demande le réseau en arrière-plan. Pour les API dynamiques, utilisez « network first » : tentez le réseau, replongez en cache si offline. Pour les documents HTML critiques, optez pour « stale-while-revalidate » : servez la version en cache immédiatement, rechargez en arrière-plan, mettez à jour au prochain chargement. Utilisez des caches nommés différemment (v1, v2) pour gérer les versions.
Synchronisation en arrière-plan et notifications
Les service workers supportent la Background Sync API : enregistrez une tâche avec registration.sync.register('sync-tag') quand l'utilisateur est offline, elle se rejoue automatiquement à la reconnexion. Parfait pour les formulaires, paiements, uploads. Combinez avec la Notifications API pour informer l'utilisateur du succès. Sur iOS, Safari ne supporte ni la Background Sync ni les notifications persistantes, prévoyez un fallback (polling, local storage).
Gestion des mises à jour et versioning
Versionnez vos caches (« assets-v1 », « api-v2 »). À chaque déploiement, créez une nouvelle version. Pendant activate , supprimez les anciens caches avec caches.delete() . Pour les mises à jour du service worker lui-même, utilisez skipWaiting() et clients.claim() si vous acceptez un redémarrage instant, sinon laissez l'ancien worker terminer les requêtes en cours (plus safe).
Débogage et monitoring en production
Chrome DevTools affiche l'état du service worker, les caches, et simule l'offline. Loggez les erreurs de cache vers un endpoint (avec fallback local storage). Mesurez les hit/miss rates : un ratio élevé d'offline requests réussies montre que votre stratégie fonctionne. Testez régulièrement sur réseau 3G/4G lent et vrai offline.
Cas concrets : Ionic et Angular
Avec Ionic, les service workers s'intègrent via ng build --prod . Précachez les pages principales de votre app mobile. Pour les images distantes, utilisez une stratégie « cache, expire après 7 jours ». Avec Angular, déclarez les routes statiques et les API dynamiques dans votre ngsw-config.json . Testez sur device réel avec Capacitor : débranchez le WiFi, vérifiez que l'app reste fonctionnelle.
Pièges courants
Ne stockez jamais les tokens d'auth dans le cache—utilisez sessionStorage ou une session serveur. Ne présumez pas que navigator.onLine est fiable. Ne précachez pas de données sensibles. Sur les anciens navigateurs (< 2015), les service workers ne sont pas disponibles—prévoyez un fallback gracieux. Attention aux CORS : le service worker ne peut servir que les ressources du même domaine ou explicitement autorisées.