Comment utiliser les service workers pour la performance : guide complet pour optimiser votre site

Pourquoi les service workers sont essentiels à la performance web

Les service workers agissent comme un proxy réseau entre votre navigateur et le serveur. Ils permettent de gérer les requêtes, de mettre en cache les ressources et d’offrir une expérience hors ligne. En les utilisant correctement, vous pouvez réduire les temps de chargement, améliorer la réactivité et même garantir l’accès à votre site en l’absence de connexion.

Ce guide vous montre pas à pas comment tirer parti des service workers pour booster la performance de votre site, avec des exemples concrets et des bonnes pratiques.

Qu’est-ce qu’un service worker ?

Un service worker est un script JavaScript qui s’exécute en arrière-plan, indépendamment de la page web. Il intercepte les requêtes réseau, gère le cache et peut envoyer des notifications push. Contrairement à un script classique, il ne peut pas accéder directement au DOM. Il fonctionne comme un intermédiaire entre le client et le serveur.

Pour qu’un service worker soit efficace, il doit être enregistré, installé et activé. Voici les étapes clés.

Cycle de vie d’un service worker

• Enregistrement : le navigateur télécharge le fichier JavaScript du service worker.
• Installation : idéal pour précharger les ressources essentielles (pages, styles, scripts).
• Activation : supprime les anciens caches et prend le contrôle des pages.
• Phase de veille : le service worker écoute les événements (fetch, push, sync).

Comment enregistrer un service worker

L’enregistrement se fait depuis votre page JavaScript principale. Assurez-vous que le navigateur le supporte (tous les navigateurs modernes sauf Safari partiel).

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js')
    .then(registration => {
      console.log('Service Worker enregistré avec succès');
    })
    .catch(error => {
      console.log('Échec de l'enregistrement : ', error);
    });
}

Placez ce code dans votre fichier JavaScript principal, de préférence après le chargement de la page pour ne pas bloquer l’affichage.

Stratégies de cache pour la performance

Le choix de la stratégie de cache a un impact direct sur la performance. Voici les plus courantes :

Cache First (puis réseau)

Idéal pour les ressources statiques (images, CSS, polices). Le service worker sert la ressource depuis le cache si elle existe, sinon il la récupère sur le réseau et la met en cache.

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

Network First (puis cache)

Pour les contenus dynamiques (API, pages fréquemment mises à jour). On tente d’abord le réseau ; si ça échoue, on sert le cache.

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

Stale-While-Revalidate

Compromis intéressant : on sert immédiatement la version en cache, puis on met à jour le cache avec la version réseau. Idéal pour les ressources qui changent rarement.

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(cached => {
        const fetchPromise = fetch(event.request).then(response => {
          caches.open('mon-cache').then(cache => cache.put(event.request, response));
          return response.clone();
        });
        return cached || fetchPromise;
      })
  );
});

Mettre en cache les ressources statiques à l’installation

Lors de l’événement install, préchargez les fichiers essentiels pour que le site fonctionne hors ligne.

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open('v1').then(cache => {
      return cache.addAll([
        '/',
        '/index.html',
        '/styles.css',
        '/app.js',
        '/logo.png'
      ]);
    })
  );
});

Attention à ne pas inclure trop de fichiers, sinon l’installation peut échouer. Limitez-vous aux ressources critiques.

Gérer les mises à jour du service worker

Quand vous modifiez le fichier sw.js, le navigateur détecte le changement et installe la nouvelle version. Mais il faut gérer la transition pour éviter les conflits.

• Utilisez un numéro de version dans le nom du cache (ex: ‘v1’, ‘v2’).
• Dans l’événement activate, supprimez les anciens caches.
• Appelez self.clients.claim() pour prendre le contrôle des pages ouvertes.

self.addEventListener('activate', event => {
  const cacheWhitelist = ['v2'];
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.map(cacheName => {
          if (cacheWhitelist.indexOf(cacheName) === -1) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

Pièges à éviter avec les service workers

Une mauvaise configuration peut dégrader les performances ou provoquer des erreurs. Voici les erreurs fréquentes :

• Mettre en cache trop de ressources : risque de dépassement de quota. Préférez une sélection minutieuse.
• Ignorer les en-têtes de cache : certains CDN envoient des en-têtes qui peuvent entrer en conflit avec votre stratégie.
• Ne pas gérer les erreurs réseau : si le réseau échoue, votre service worker doit renvoyer une page de secours ou un contenu en cache.
• Oublier de mettre à jour les caches : les anciennes versions peuvent rester et causer des bugs.
• Utiliser le service worker pour des ressources dynamiques sans précaution : les données utilisateur ou les sessions peuvent être obsolètes.

Exemple complet : site vitrine avec service worker

Voici un exemple de service worker pour un site vitrine simple. Il utilise la stratégie Cache First pour les ressources statiques et Network First pour les pages.

const CACHE_NAME = 'site-vitrine-v1';
const urlsToCache = [
  '/',
  '/index.html',
  '/css/style.css',
  '/js/app.js',
  '/images/logo.png'
];

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(cache => cache.addAll(urlsToCache))
  );
});

self.addEventListener('fetch', event => {
  const requestUrl = new URL(event.request.url);
  if (requestUrl.pathname === '/') {
    // Network First pour la page d'accueil
    event.respondWith(
      fetch(event.request)
        .catch(() => caches.match(event.request))
    );
  } else {
    // Cache First pour les ressources
    event.respondWith(
      caches.match(event.request)
        .then(response => response || fetch(event.request))
    );
  }
});

self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.filter(name => name !== CACHE_NAME)
          .map(name => caches.delete(name))
      );
    })
  );
});

Mesurer l’impact des service workers sur la performance

Utilisez les outils de développement Chrome (onglet Application > Service Workers) pour inspecter l’état. Le panneau Network montre si les requêtes sont servies depuis le service worker. Vous pouvez aussi utiliser Lighthouse pour évaluer le temps de chargement et la réactivité.

Un bon indicateur est le Time to First Byte (TTFB) : avec un service worker bien configuré, il peut passer de 200 ms à 0 ms pour les ressources en cache. Le First Contentful Paint (FCP) peut aussi être réduit de manière significative.

Checklist pour une implémentation réussie

• ✅ Le service worker est enregistré uniquement sur HTTPS (ou localhost).
• ✅ Le fichier sw.js est à la racine du domaine pour couvrir toutes les pages.
• ✅ Les ressources critiques sont préchargées à l’installation.
• ✅ La stratégie de cache est adaptée à chaque type de ressource.
• ✅ Les caches obsolètes sont supprimés à l’activation.
• ✅ Une page de secours est prévue en cas d’absence de connexion.
• ✅ Les tests sont effectués en mode navigation privée et avec le cache désactivé.

Questions fréquentes sur les service workers

Les service workers fonctionnent-ils en mode navigation privée ?

Oui, mais le cache est isolé par session. Les données ne persistent pas entre les sessions privées.

Puis-je utiliser un service worker avec un site statique ?

Absolument, c’est même recommandé. Un site statique profite pleinement du cache pour une expérience ultra-rapide.

Quelle est la limite de stockage du cache ?

Le navigateur alloue un quota variable (environ 50 Mo sur mobile, plus sur desktop). Surveillez l’utilisation via navigator.storage.estimate().

Comment déboguer un service worker ?

Utilisez les DevTools : onglet Application > Service Workers. Vous pouvez voir l’état, forcer l’update, ou simuler la déconnexion.

Recommandations pour aller plus loin

Les service workers ne sont qu’un élément de la performance. Combinez-les avec d’autres techniques :

• Code splitting pour ne charger que le JavaScript nécessaire.
• Lazy loading des images et des iframes.
• Compression Gzip ou Brotli sur le serveur.
• CDN pour réduire la latence.
• Preload et prefetch des ressources critiques.

Enfin, testez régulièrement votre site avec des outils comme PageSpeed Insights ou WebPageTest pour valider l’impact de vos optimisations.

En maîtrisant les service workers, vous offrez à vos utilisateurs une expérience rapide, fiable et agréable, même en cas de réseau instable.

Photo by Jimmy Liao on Pexels