Service Workers : Créer des Applications Web Offline-First

Dans le monde d'aujourd'hui, les utilisateurs s'attendent à ce que les applications web soient rapides, fiables et accessibles, même lorsque la connectivité réseau est limitée ou indisponible. C'est là que le concept de conception "offline-first" (priorité à l'hors-ligne) entre en jeu. Les service workers sont une technologie puissante qui permet aux développeurs de créer des applications web qui fonctionnent de manière transparente hors ligne, offrant une expérience utilisateur supérieure.

Que sont les Service Workers ?

Un service worker est un fichier JavaScript qui s'exécute en arrière-plan, séparé du thread principal du navigateur. Il agit comme un proxy entre l'application web et le réseau, interceptant les requêtes réseau et gérant la mise en cache. Les service workers peuvent gérer des tâches telles que :

La mise en cache des ressources statiques (HTML, CSS, JavaScript, images)
La diffusion de contenu mis en cache en mode hors ligne
Les notifications push
La synchronisation en arrière-plan

Il est important de noter que les service workers sont contrôlés par le navigateur, et non par la page web. Cela leur permet de fonctionner même lorsque l'utilisateur a fermé l'onglet ou la fenêtre du navigateur.

Pourquoi l'approche Offline-First ?

Créer une application web offline-first offre de nombreux avantages :

Performance améliorée : En mettant en cache les ressources statiques et en les servant directement depuis le cache, les service workers réduisent considérablement les temps de chargement, ce qui se traduit par une expérience utilisateur plus rapide et plus réactive.
Fiabilité accrue : Même lorsque le réseau est indisponible, les utilisateurs peuvent toujours accéder au contenu mis en cache, garantissant que l'application reste fonctionnelle.
Engagement accru : La fonctionnalité hors ligne rend l'application plus utile et accessible, ce qui entraîne un engagement et une rétention accrus des utilisateurs.
Consommation de données réduite : En mettant en cache les ressources, les service workers réduisent la quantité de données à télécharger sur le réseau, ce qui est particulièrement avantageux pour les utilisateurs avec des forfaits de données limités ou des connexions internet lentes dans des zones aux infrastructures moins développées. Par exemple, dans de nombreuses régions d'Afrique et d'Amérique du Sud, le coût des données peut être un obstacle important à l'accès à internet pour les utilisateurs. La conception offline-first aide à atténuer ce problème.
SEO amélioré : Les moteurs de recherche favorisent les sites web rapides et fiables, donc la création d'une application offline-first peut améliorer votre classement dans les moteurs de recherche.

Comment fonctionnent les Service Workers

Le cycle de vie d'un service worker se compose de plusieurs étapes :

Enregistrement (Registration) : Le service worker est enregistré auprès du navigateur, en spécifiant la portée de l'application qu'il contrôlera.
Installation : Le service worker est installé, phase durant laquelle il met généralement en cache les ressources statiques.
Activation : Le service worker est activé et prend le contrôle de l'application web. Cela peut impliquer de désenregistrer les anciens service workers et de nettoyer les anciens caches.
Inactif (Idle) : Le service worker reste inactif, en attente de requêtes réseau ou d'autres événements.
Récupération (Fetch) : Lorsqu'une requête réseau est effectuée, le service worker l'intercepte et peut soit servir le contenu mis en cache, soit récupérer la ressource depuis le réseau.

Mettre en œuvre l'Offline-First avec les Service Workers : Un guide étape par étape

Voici un exemple de base sur la manière de mettre en œuvre la fonctionnalité offline-first à l'aide des service workers :

Étape 1 : Enregistrer le Service Worker

Dans votre fichier JavaScript principal (par ex., `app.js`) :


if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/service-worker.js')
    .then(function(registration) {
      console.log('Service Worker enregistré avec la portée :', registration.scope);
    })
    .catch(function(error) {
      console.log('Échec de l'enregistrement du Service Worker :', error);
    });
}

Ce code vérifie si le navigateur prend en charge les service workers et enregistre le fichier `service-worker.js`. La portée définit les URL que le service worker contrôlera.

Étape 2 : Créer le fichier Service Worker (service-worker.js)

Créez un fichier nommé `service-worker.js` avec le code suivant :


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

self.addEventListener('install', function(event) {
  // Effectuer les étapes d'installation
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(function(cache) {
        console.log('Cache ouvert');
        return cache.addAll(urlsToCache);
      })
  );
});

self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request)
      .then(function(response) {
        // Ressource trouvée dans le cache - retourner la réponse
        if (response) {
          return response;
        }

        // IMPORTANT : Cloner la requête.
        // Une requête est un flux et ne peut être consommée qu'une seule fois. Comme nous la consommons
        // une fois par le cache et une fois par le navigateur pour la récupération, nous devons cloner la réponse.
        var fetchRequest = event.request.clone();

        return fetch(fetchRequest).then(
          function(response) {
            // Vérifier si nous avons reçu une réponse valide
            if(!response || response.status !== 200 || response.type !== 'basic') {
              return response;
            }

            // IMPORTANT : Cloner la réponse.
            // Une réponse est un flux et ne doit être consommée qu'une seule fois.
            var responseToCache = response.clone();

            caches.open(CACHE_NAME)
              .then(function(cache) {
                cache.put(event.request, responseToCache);
              });

            return response;
          }
        );
      })
    );
});

self.addEventListener('activate', function(event) {

  var cacheWhitelist = [CACHE_NAME];

  event.waitUntil(
    caches.keys().then(function(cacheNames) {
      return Promise.all(
        cacheNames.map(function(cacheName) {
          if (cacheWhitelist.indexOf(cacheName) === -1) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

Ce code effectue les actions suivantes :

Définit un `CACHE_NAME` et un tableau de `urlsToCache`.
Pendant l'événement `install`, il ouvre le cache et y ajoute les URL spécifiées.
Pendant l'événement `fetch`, il intercepte les requêtes réseau. Si la ressource demandée se trouve dans le cache, il renvoie la version mise en cache. Sinon, il récupère la ressource sur le réseau, la met en cache et renvoie la réponse.
Pendant l'événement `activate`, il supprime les anciens caches pour maintenir une taille de cache gérable.

Étape 3 : Tester votre fonctionnalité hors ligne

Pour tester votre fonctionnalité hors ligne, vous pouvez utiliser les outils de développement du navigateur. Dans Chrome, ouvrez les DevTools, allez dans l'onglet "Application", et sélectionnez "Service Workers". Vous pouvez ensuite simuler le mode hors ligne en cochant la case "Offline".

Techniques avancées de Service Worker

Une fois que vous avez une compréhension de base des service workers, vous pouvez explorer des techniques plus avancées pour améliorer votre application offline-first :

Stratégies de mise en cache

Il existe plusieurs stratégies de mise en cache que vous pouvez utiliser, en fonction du type de ressource et des exigences de votre application :

Cache First (Cache d'abord) : Toujours servir le contenu depuis le cache, et ne récupérer sur le réseau que si la ressource n'est pas trouvée dans le cache.
Network First (Réseau d'abord) : Toujours essayer de récupérer le contenu depuis le réseau en premier, et n'utiliser le cache qu'en solution de secours.
Cache then Network (Cache puis Réseau) : Servir le contenu depuis le cache immédiatement, puis mettre à jour le cache avec la dernière version depuis le réseau. Cela permet un chargement initial rapide et garantit que l'utilisateur dispose toujours du contenu le plus à jour (à terme).
Stale-while-revalidate : Similaire à Cache then Network, mais met à jour le cache en arrière-plan sans bloquer le chargement initial.
Network Only (Réseau seulement) : Forcer l'application à toujours récupérer le contenu depuis le réseau.
Cache Only (Cache seulement) : Forcer l'application à n'utiliser que le contenu stocké dans le cache.

Le choix de la bonne stratégie de mise en cache dépend de la ressource spécifique et des exigences de votre application. Par exemple, les ressources statiques comme les images et les fichiers CSS sont souvent mieux servies avec la stratégie Cache First, tandis que le contenu dynamique pourrait bénéficier de la stratégie Network First ou Cache then Network.

Synchronisation en arrière-plan

La synchronisation en arrière-plan vous permet de différer des tâches jusqu'à ce que l'utilisateur dispose d'une connexion réseau stable. C'est utile pour des tâches telles que la soumission de formulaires ou le téléchargement de fichiers. Par exemple, un utilisateur dans une région reculée d'Indonésie pourrait remplir un formulaire en étant hors ligne. Le service worker peut alors attendre qu'une connexion soit disponible avant de soumettre les données.

Notifications Push

Les service workers peuvent être utilisés pour envoyer des notifications push aux utilisateurs, même lorsque l'application n'est pas ouverte. Cela peut être utilisé pour réengager les utilisateurs et fournir des mises à jour opportunes. Pensez à une application d'actualités fournissant des alertes de dernière minute aux utilisateurs en temps réel, que l'application soit activement en cours d'exécution ou non.

Workbox

Workbox est une collection de bibliothèques JavaScript qui facilitent la création de service workers. Il fournit des abstractions pour les tâches courantes telles que la mise en cache, le routage et la synchronisation en arrière-plan. L'utilisation de Workbox peut simplifier votre code de service worker et le rendre plus facile à maintenir. De nombreuses entreprises utilisent désormais Workbox comme un composant standard lors du développement de PWA et d'expériences offline-first.

Considérations pour un public mondial

Lors de la création d'applications web offline-first pour un public mondial, il est important de prendre en compte les facteurs suivants :

Conditions de réseau variables : La connectivité réseau peut varier considérablement d'une région à l'autre. Certains utilisateurs peuvent avoir accès à un internet à haut débit, tandis que d'autres peuvent dépendre de connexions lentes ou intermittentes. Concevez votre application pour gérer avec élégance les différentes conditions de réseau.
Coûts des données : Le coût des données peut être un obstacle important à l'accès à internet dans certaines parties du monde. Minimisez la consommation de données en mettant agressivement les ressources en cache et en optimisant les images.
Support linguistique : Assurez-vous que votre application prend en charge plusieurs langues et que les utilisateurs peuvent accéder au contenu dans leur langue préférée, même hors ligne. Stockez le contenu localisé dans le cache et servez-le en fonction des paramètres de langue de l'utilisateur.
Accessibilité : Assurez-vous que votre application web est accessible aux utilisateurs handicapés, quelle que soit leur connexion réseau. Suivez les meilleures pratiques en matière d'accessibilité et testez votre application avec des technologies d'assistance.
Mises à jour du contenu : Planifiez comment gérer efficacement les mises à jour de contenu. Des stratégies comme `stale-while-revalidate` peuvent offrir aux utilisateurs une expérience initiale rapide tout en garantissant qu'ils voient à terme le contenu le plus récent. Envisagez d'utiliser le versionnage pour les ressources mises en cache afin que les mises à jour soient déployées en douceur.
Limitations du stockage local : Bien que le stockage local (Local Storage) soit utile pour de petites quantités de données, les service workers ont accès à l'API Cache, qui permet de stocker des fichiers plus volumineux et des structures de données plus complexes, ce qui est essentiel pour les expériences hors ligne.

Exemples d'applications Offline-First

Plusieurs applications web populaires ont mis en œuvre avec succès la fonctionnalité offline-first à l'aide de service workers :

Google Maps : Permet aux utilisateurs de télécharger des cartes pour une utilisation hors ligne, leur permettant de naviguer même sans connexion internet.
Google Docs : Permet aux utilisateurs de créer et de modifier des documents hors ligne, en synchronisant les modifications lorsqu'une connexion réseau est disponible.
Starbucks : Permet aux utilisateurs de parcourir le menu, de passer des commandes et de gérer leur compte de fidélité hors ligne.
AliExpress : Permet aux utilisateurs de parcourir les produits, d'ajouter des articles à leur panier et de consulter les détails de leur commande hors ligne.
Wikipédia : Offre un accès hors ligne aux articles et au contenu, rendant la connaissance accessible même sans internet.

Conclusion

Les service workers sont un outil puissant pour créer des applications web offline-first qui sont rapides, fiables et engageantes. En mettant en cache les ressources, en interceptant les requêtes réseau et en gérant les tâches en arrière-plan, les service workers peuvent offrir une expérience utilisateur supérieure, même lorsque la connectivité réseau est limitée ou indisponible. Comme l'accès au réseau reste inégal à travers le monde, se concentrer sur des conceptions offline-first est crucial pour garantir un accès équitable à l'information et aux services sur le web.

En suivant les étapes décrites dans ce guide et en tenant compte des facteurs mentionnés ci-dessus, vous pouvez créer des applications web qui fonctionnent de manière transparente hors ligne et offrent une expérience agréable aux utilisateurs du monde entier. Adoptez la puissance des service workers et construisez l'avenir du web – un avenir où le web est accessible à tous, partout, quelle que soit leur connexion réseau.