PWA Service Worker pour les nuls

Le fait est que le service worker a un rôle important à jouer dans les années à venir, et plus vite vous pourrez vous familiariser avec cette nouvelle technologie, mieux vous pourrez vous adapter à ce nouvel avenir du Web.

C'est pourquoi, afin de vous aider à mieux connaître cette nouvelle technologie, nous aurons ensemble une discussion sur les service workers, qu'est-ce que c'est, ce qu'elle apporte au Web, comment mieux se préparer à cette nouvelle technologie de la toile.

Qu'est-ce qu'un travailleur de service ?

Définitions

Universellement considéré comme la technologie qui fait ou défait les PWA, le service worker est une API qui s'exécute indépendamment du navigateur et qui est responsable de l'interception du réseau . De ce fait, il peut faire de nombreuses choses qui étaient auparavant impossibles sur le Web. Les sites Web (généralement des PWA) contrôlés par les techniciens de service peuvent avoir une intégration plus profonde avec l'appareil utilisé et, par conséquent, apporter plus de capacités matérielles et de fonctionnalités de type application sur le Web (par exemple, les notifications push, la synchronisation en arrière-plan, etc.).

Comment ça fonctionne

En un mot. service worker est essentiellement une couche basée sur les événements entre le navigateur et le serveur qui intercepte, modifie et gère les requêtes réseau sortantes :

Et comme le service worker est basé sur les événements , il ne répond et ne communique que par le biais d'événements, et utilise des promesses pour indiquer quand une opération est terminée. Cependant, toutes les réceptions d'événements (par exemple fetch et push ) ne sont possibles que lorsque le service worker est actif , ce qui indique quand le navigateur reconnaît et enregistre le service worker (et aussi quand le service worker lui-même a terminé l'installation avec succès) . De manière simplifiée, voici le cycle de vie typique d'un service worker :

Notez également tous ces événements disponibles dans service worker :

Tous les événements fonctionnels ( fetch , sync et push ) devraient être explicites pour vous, car ce sont les événements qui constituent la quasi-totalité des caractéristiques progressives de PWA (c'est-à-dire les capacités hors ligne, la synchronisation en arrière-plan, les notifications push).

 Lecture recommandée : Qu'est-ce qu'une PWA ? Tout ce que vous devez savoir sur les applications Web progressives

Contraintes pour les travailleurs des services

Comme il s'agit d'un script qui s'exécute indépendamment du navigateur, il y a certaines contraintes :

• Protocole HTTPS : les service workers doivent être exécutés sur des sites Web basés sur HTTPS

• Pas d'accès à localStorage , DOM et à la fenêtre.
• scope limitée : les service workers ne peuvent opérer que dans la scope du répertoire actuel (et des sous-répertoires) dans lequel se trouve le service-worker.js .
• Asynchrone : les service workers sont de nature asynchrone, s'appuyant donc sur des API basées sur Promise.

Ce que les travailleurs des services signifient pour les PWA

Comme indiqué précédemment, le travailleur de service est l'épine dorsale de PWA, sans lequel de nombreuses fonctionnalités révolutionnaires de PWA ne sont tout simplement pas possibles. Essentiellement, ce que fait le travailleur de service, c'est qu'il fournit les moyens de :

Meilleure performance

Les performances lors de visites répétées sont nettement meilleures sur une PWA, car les techniciens de service font énormément pour aider au processus de mise en cache. Par rapport au cache Web typique (cache HTTP) utilisé dans la majorité des sites Web, PWA excelle dans la diffusion de contenu même dans des conditions de réseau défavorables :

Tout cela est dû au fait que les service workers donnent aux développeurs une liberté totale sur exactement quoi et comment la mise en cache est effectuée. Pour voir à quel point les performances de mise en cache des techniciens de service sont meilleures, nous recommandons l'étude récente de Google : Mesurer l'impact des performances des techniciens de service dans le monde réel. L'étude a une méthodologie claire, centrée sur le temps de première peinture comme métrique pour déterminer la performance des travailleurs de service.

En moyenne, les pages se chargeaient un peu plus rapidement lorsqu'un agent de service contrôlait la page qu'elles ne le faisaient sans un agent de service, pour les nouveaux visiteurs et les visiteurs récurrents.

Philip Walton, Mesure de l'impact sur les performances réelles des travailleurs des services

Accès hors ligne

Une fois enregistrés, les techniciens de service mettent en cache le contenu nécessaire pour votre site PWA et le diffusent ensuite. Cela rend effectivement les sites Web alimentés par PWA hors ligne, car les utilisateurs peuvent toujours interagir avec le site et voir tout le contenu mis en cache.

Cela ne veut pas dire non plus que l'accès hors ligne est une fonctionnalité inédite sur le Web - il était possible de donner aux utilisateurs une expérience hors ligne sur le Web, c'est juste que l'expérience n'était pas optimale (voir Application Cache est un Douchebag) et le service Les travailleurs ont été inventés pour résoudre (ou plutôt éviter) les inconvénients d'AppCache.

 Lecture recommandée : Comment faire fonctionner votre PWA hors ligne

Fonctionnalités de l'application native

En plus d'offrir un accès hors ligne et des performances améliorées, les techniciens de service servent également de base à davantage de fonctionnalités de type application telles que les notifications push et la synchronisation en arrière-plan (et dans un avenir proche, le géorepérage et la synchronisation périodique). La fonctionnalité de notifications push de PWA, par exemple, est assemblée à l'aide de deux API : l'API Notifications et l'API Push, toutes deux construites au-dessus de l'API Service Worker.

Cycle de vie d'un service worker

La durée de vie d'un service se compose de trois parties : l'enregistrement, l'installation et l'activation, que nous détaillerons ci-dessous :

Inscription

La première étape que nous devons faire est d'enregistrer le travailleur de service. Sans cette étape, le navigateur ne saura pas où se trouve votre technicien de service et, par conséquent, il sera impossible d'installer le technicien de service en arrière-plan.
Nous pouvons enregistrer le travailleur de service en utilisant le code suivant :

 if('serviceWorker' dans le navigateur) {
    navigator.serviceWorker.register('./pwa-examples/simicart/sw.js', {scope : './sw-scope/'})
.then((reg) => {
   // l'enregistrement a fonctionné
       console.log('Enregistrement réussi. La portée est ' + reg.scope);
} ;

Le code ci-dessus commencera d'abord à rechercher l'API Service Worker dans le navigateur et, si le navigateur prend en charge ladite API, il enregistre un nouveau service worker à l'aide de la méthode serviceworkerContainer.register() et donne une scope du service worker. Par exemple, dans le code ci-dessus, notre scope d'application est /pwa-examples/simicart/ ce qui signifie que notre agent de service ne fonctionnera que pour les pages commençant par /pwa-examples/simicart/ . Nous appelons ces pages ' pages contrôlées '.

Installation

Maintenant que le navigateur sait où se trouve notre agent de service - et quelle est sa portée - il tentera d'installer l'agent de service. Vous pouvez choisir de ne rien faire pendant cette phase, mais nous aimerions tout de même noter qu'il s'agit de la phase où se déroule la majeure partie du processus de mise en cache. Par exemple, voici comment se déroule généralement le processus de mise en cache de l'actif :

 const cacheName = 'site-cache-v1'
const assetsToCache = [
    '/pwa-exemples/',
    '/pwa-examples/index.html',
    '/pwa-examples/css/styles.css',
    '/pwa-examples/js/app.js',
]

self.addEventListener('installer', ( événement ) => {
    event.waitUntil(  
        caches.open(cacheName).then((cache) => {
              renvoie cache.addAll(assetsToCache);
        })
      );
});

Comme vous pouvez le voir dans l'exemple ci-dessus, nous utilisons l'API Cache pour mettre en cache nos actifs que nous utiliserons plus tard pour rendre notre PWA compatible hors ligne. Ce processus de mise en cache se produit pendant l'événement d'installation.

Activation

Après l'étape d'installation, nous pouvons maintenant activer le service worker. Cependant, cette étape d'activation ne se produit normalement pas automatiquement, et pour que l'agent de service s'active, vous devez vous assurer qu'aucun agent de service ne contrôle actuellement les pages.

Alternativement, vous pouvez également automatiser le processus d'activation de votre service worker en utilisant la méthode skipWaiting() .

 const cacheName = 'site-cache-v1'
const assetsToCache = [
    '/pwa-exemples/',
    '/pwa-examples/index.html',
    '/pwa-examples/css/styles.css',
    '//exemples-pwa/js/app.js',
]
self.addEventListener('installer', ( événement ) => {
    self.skipWaiting(); // saute l'attente
    event.waitUntil(  
        caches.open(cacheName).then((cache) => {
              renvoie cache.addAll(assetsToCache);
        })
      );
});

Le Web a besoin d'un service worker

À ce stade, nous pouvons tous convenir que le service worker est presque une étape éventuelle que le Web doit franchir. Les utilisateurs sont de plus en plus exigeants pour les fonctionnalités de type application, et combiné au fait que PWA devient l'avenir de la livraison de logiciels, il semble que le Web ait beaucoup de potentiel dans les années à venir.

Pour les marchands Magento qui cherchent à transformer leur vitrine, nous fournissons une solution PWA sans tête rentable et complète pour votre entreprise.