Faites fonctionner votre application hors ligne avec les techniciens de service

Page 1 sur 2: Page 1: Chargement plus rapide

Les techniciens de service peuvent être utilisés pour améliorer les temps de chargement et la prise en charge hors ligne de vos sites et applications Web. Dans ce didacticiel, nous allons vous montrer comment améliorer progressivement une application Web avec un Service Worker. Nous aborderons d'abord ce qu'est un Service Worker et comment son cycle de vie fonctionne, puis nous vous montrerons comment l'utiliser pour accélérer votre site (cette page) et proposer du contenu hors ligne (page 2).

Ensuite, nous vous montrerons comment comment créer une application avec les travailleurs des services. Vous apprendrez à configurer un Worker simple qui mettra en cache et servira les actifs statiques (offrant une énorme amélioration des performances sur les charges suivantes), puis comment mettre en cache les réponses d'API dynamiques et offrir à notre application de démonstration une prise en charge hors ligne complète. Voyons d'abord ce que sont exactement les Service Workers et comment ils fonctionnent.

Construire un site Web? Rationalisez votre processus avec un excellent Générateur de site Web , et maintenez-le avec un décent hébergement Web un service. Et obtenez votre stockage trié avec ces stockage en ligne options.

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

Alors, qu'est-ce qu'un technicien de service? C'est un script, écrit en JavaScript, que votre navigateur exécute en arrière-plan. Cela n'affecte pas le thread principal (où JavaScript s'exécute généralement sur une page Web) et n'entrera pas en conflit avec le code de votre application ni n'affectera les performances d'exécution.

Un Service Worker n'a pas d'accès direct au DOM ou aux événements et à l'interaction de l'utilisateur se produisant dans la page Web elle-même. Considérez-le comme une couche qui se situe entre la page Web et le réseau, lui permettant d'intercepter et de manipuler les requêtes réseau (par exemple, les requêtes Ajax) faites par votre page. Cela le rend idéal pour gérer les caches et prendre en charge l'utilisation hors ligne.

Le cycle de vie du Service Worker

La vie d'un Service Worker suit un flux simple, mais cela peut être un peu déroutant lorsque vous êtes habitué aux scripts JS qui fonctionnent immédiatement:

Installation> En attente (installé)> Activation> Activé> Redondant

Lors du premier chargement de votre page, le code d'enregistrement que nous avons ajouté index.html démarre l'installation du Service Worker. Lorsqu'il n'y a pas de Worker existant, le nouveau Service Worker sera activé immédiatement après l'installation. Une page Web ne peut avoir qu'un seul Service Worker actif à la fois.

Si un Worker est déjà installé, le nouveau Service Worker sera installé, puis passera à l'étape d'attente jusqu'à ce que la page soit complètement fermée, puis rechargée. Il ne suffit pas de rafraîchir simplement car vous pourriez avoir d'autres onglets ouverts. Vous devez vous assurer que toutes les instances de la page sont fermées, sinon le nouveau Worker ne s'activera pas. Vous n'êtes pas obligé de fermer les onglets, vous pouvez simplement naviguer vers un autre site et revenir.

Tous les deux installer et Activer les événements ne se produiront qu'une seule fois par travailleur. Une fois activé, le Service Worker aura alors le contrôle de la page et pourra commencer à gérer des événements tels que la récupération pour manipuler les demandes.

Enfin, un Service Worker deviendra redondant si le navigateur détecte que le fichier worker lui-même a été mis à jour ou si l'installation ou l'activation échoue. Le navigateur recherchera une différence d'octet pour déterminer si un script de travail a été mis à jour.

Il est important de noter que vous ne devez jamais changer (ou révoquer) le nom de votre Service Worker. Vous ne devez pas non plus mettre en cache le fichier de travail lui-même sur le serveur, car vous ne pourrez pas le mettre à jour facilement, bien que les navigateurs soient maintenant suffisamment intelligents pour ignorer les en-têtes de mise en cache.

01. Cloner l'application de démonstration

D'accord, commençons à apprendre à créer une application Web avec l'aide de Service Workers. Pour ce didacticiel, vous aurez besoin de versions récentes de Node.js et npm installées sur votre ordinateur.

Nous avons créé une application de démonstration que nous utiliserons comme base pour ce tutoriel ( clonez l'application de démonstration ici ). L'application est un petit projet amusant qui récupère les prévisions météorologiques sur cinq jours en fonction de l'emplacement de l'utilisateur. Il vérifiera ensuite si de la pluie est prévue avant la fin de la journée et mettra à jour l'interface utilisateur en conséquence.

Il a été construit de manière inefficace (intentionnellement) en utilisant de grandes bibliothèques inutiles telles que jQuery et Bootstrap, avec de grandes images non optimisées pour démontrer la différence de performances lors de l'utilisation d'un Service Worker. Il pèse actuellement un ridicule 4,1 Mo.

02. Obtenez votre clé API

Afin de récupérer les données météorologiques de l'API, vous devrez vous procurer une clé API gratuite auprès de OpenWeatherMap :

Une fois que vous avez votre clé, ouvrez index.html et recherchez le window.API_KEY variable dans le . Collez votre clé dans la valeur:

window.API_KEY = 'paste-your-key-here';

03. Démarrez le serveur de développement

Nous sommes maintenant prêts à commencer à travailler sur le projet. Tout d'abord, installons les dépendances en exécutant:

npm install

Il existe deux tâches pour l'outil de création. Courir au-dessus du niveau de la mer pour démarrer le serveur de développement sur le port 3000. Exécutez npm run build pour préparer la version «production». Gardez à l'esprit que ce n'est qu'une démo, donc ce n'est pas vraiment une version de production - il n'y a pas de minification ou quoi que ce soit - les fichiers sont simplement `` accélérés ''.

Un algorithme est utilisé pour créer un hachage, tel que 9c616053e5, à partir du contenu du fichier. L'algorithme produira toujours le même hachage pour le même contenu, ce qui signifie que tant que vous ne modifiez pas le fichier, le hachage ne changera pas. Le hachage est ensuite ajouté au nom de fichier, ainsi par exemple styles.css peut devenir styles-9c616053e5.css. Le hachage représente la révision du fichier - d'où «revved».

Vous pouvez mettre en cache en toute sécurité chaque révision du fichier sur votre serveur sans jamais avoir à invalider votre cache, ce qui est coûteux, ou à vous soucier d'un autre cache tiers servant une version incorrecte.

04. Présentez votre technicien de service

Commençons maintenant avec notre Service Worker. Créez un fichier appelé sw.js à la racine du src annuaire. Ajoutez ensuite ces deux écouteurs d'événements pour enregistrer le installer et Activer événements:

self.addEventListener('install', (event) => { console.log(event); }); self.addEventListener('activate', (event) => { console.log(event); });

Le soi La variable ici représente la portée globale en lecture seule du Service Worker. C'est un peu comme le la fenêtre objet dans une page Web.

Ensuite, nous devons mettre à jour notre fichier index.html et ajouter les commandes pour installer le Service Worker. Ajoutez ce script juste avant la fermeture étiqueter. Il enregistrera notre travailleur et enregistrera son statut actuel.

if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js') .then(function(reg) { if (reg.installing) { console.log('SW installing'); } else if (reg.waiting) { console.log('SW waiting'); } else if (reg.active) { console.log('SW activated'); } }).catch(function(error) { // registration failed console.log('Registration failed with ' + error); }); }

Démarrez votre serveur de développement en exécutant au-dessus du niveau de la mer et ouvrez la page dans un navigateur moderne. Nous vous recommandons d'utiliser Google Chrome car il dispose d'un bon support technique dans ses DevTools, auquel nous ferons référence tout au long de ce didacticiel. Vous devriez voir trois choses enregistrées sur votre console; deux du Service Worker pour le installer et Activer événements, et l'autre sera le message de l'enregistrement.

05. Activer le travailleur

Nous allons dire à notre collaborateur de sauter l'étape d'attente et de l'activer maintenant. Ouvrez le fichier sw.js et ajoutez cette ligne n'importe où dans le installer écouteur d'événement:

self.skipWaiting();

Désormais, lorsque nous mettrons à jour le script Worker, il prendra le contrôle de la page immédiatement après l'installation. Il convient de garder à l'esprit que cela peut signifier que le nouveau Worker prendra le contrôle d'une page qui a peut-être été chargée par une version précédente de votre Worker - si cela pose des problèmes, n'utilisez pas cette option dans votre application.

Vous pouvez le confirmer en quittant la page, puis en revenant. Vous devriez voir le installer et Activer les événements se déclenchent à nouveau lorsque le nouveau Worker a été installé.

Chrome DevTools propose une option utile qui signifie que vous pouvez mettre à jour votre Worker simplement en le rechargeant. Ouvrez DevTools et accédez à l'onglet Application, puis choisissez Service Worker dans la colonne de gauche. En haut du panneau se trouve une case à cocher intitulée Mettre à jour lors du rechargement, cochez-la. Votre Worker mis à jour sera maintenant installé et activé lors de l'actualisation.

06. Confirmer les modifications

Confirmons cela en ajoutant console.log ('toto') appelez l'un des écouteurs d'événements et actualisez la page. Cela nous a surpris car nous nous attendions à voir le journal dans la console lors de l'actualisation, mais tout ce que nous voyions était le message «SW activé». Il s'avère que Chrome actualise la page deux fois lorsque l'option Mettre à jour lors du rechargement est cochée.

Vous pouvez le confirmer en cochant la case Conserver le journal dans le panneau des paramètres de la console et en actualisant à nouveau. Vous devriez voir les événements d'installation et d'activation enregistrés, ainsi que «toto», suivi de «Navigué vers http: // localhost: 3000 /» pour indiquer que la page a été rechargée, puis le message final «SW activé».

07. Suivre l'événement d'extraction

Il est temps d'ajouter un autre auditeur. Cette fois, nous suivrons le aller chercher événement déclenché chaque fois que la page charge une ressource, telle qu'un fichier CSS, une image ou même une réponse d'API. Nous allons ouvrir un cache, renvoyer la réponse de la requête à la page, puis - en arrière-plan - mettre en cache la réponse. Tout d'abord, ajoutons l'auditeur et actualisons afin que vous puissiez voir ce qui se passe. Dans la console, vous devriez voir de nombreux FetchEvent journaux.

self.addEventListener('fetch', (event) => { console.log(event); });

Notre mode de service utilise BrowserSync, qui ajoute son propre script à la page et effectue des requêtes websocket. Vous verrez également les FetchEvents pour ceux-ci, mais nous voulons les ignorer. Nous souhaitons également uniquement mettre en cache les requêtes GET de notre propre domaine. Ajoutons donc quelques éléments pour ignorer les demandes indésirables, notamment en ignorant explicitement le / chemin d'index:

self.addEventListener('fetch', (event) => { // Ignore crossdomain requests if (!event.request.url.startsWith(self.location.origin)) { return; } // Ignore non-GET requests if (event.request.method !== 'GET') { return; } // Ignore browser-sync if (event.request.url.indexOf('browser-sync') > -1) { return; } // Prevent index route being cached if (event.request.url === (self.location.origin + '/')) { return; } // Prevent index.html being cached if (event.request.url.endsWith('index.html')) { return; } console.log(event); });

Maintenant, les journaux devraient être beaucoup plus propres et il est sûr de commencer la mise en cache.

08. Mettez en cache les actifs

Nous pouvons maintenant commencer à mettre en cache ces réponses. Nous devons d'abord donner un nom à notre cache. Appelons le nôtre v1-actifs . Ajoutez cette ligne en haut du fichier sw.js:

const assetsCacheName = 'v1-assets';

Ensuite, nous devons détourner les FetchEvents afin de pouvoir contrôler ce qui est renvoyé à la page. Nous pouvons le faire en utilisant les répondre avec méthode. Cette méthode accepte une promesse afin que nous puissions ajouter ce code, en remplaçant le console.log :

// Tell the fetch to respond with this Promise chain event.respondWith( // Open the cache caches.open(assetsCacheName) .then((cache) => { // Make the request to the network return fetch(event.request) .then((response) => { // Cache the response cache.put(event.request, response.clone()); // Return the original response to the page return response; }); }) );

Cela transmettra la demande au réseau puis stockera la réponse dans le cache, avant de renvoyer la réponse d'origine à la page.

Il convient de noter ici que cette approche ne mettra pas en cache les réponses avant la deuxième fois que l'utilisateur charge la page. La première fois installera et activera le worker, mais au moment où le aller chercher l'auditeur est prêt, tout aura déjà été demandé.

Actualisez plusieurs fois et vérifiez le cache dans l'onglet DevTools> Application. Développez l'arborescence de stockage du cache dans la colonne de gauche et vous devriez voir votre cache avec toutes les réponses stockées.

09. Servir de la cache

Tout est mis en cache, mais nous n'utilisons pas encore le cache pour servir des fichiers. Accrochons ça maintenant. Nous allons d'abord chercher une correspondance pour la requête dans le cache et si elle existe, nous la servirons. S'il n'existe pas, nous utiliserons le réseau puis mettrons en cache la réponse.

// Tell the fetch to respond with this chain event.respondWith( // Open the cache caches.open(assetsCacheName) .then((cache) => { // Look for matching request in the cache return cache.match(event.request) .then((matched) => { // If a match is found return the cached version first if (matched) { return matched; } // Otherwise continue to the network return fetch(event.request) .then((response) => { // Cache the response cache.put(event.request, response.clone()); // Return the original response to the page return response; }); }); }) );

Enregistrez le fichier et actualisez-le. Vérifiez l'onglet DevTools> Réseau et vous devriez voir (à partir de ServiceWorker) répertorié dans la colonne Taille pour chacun des actifs statiques.

Ouf, nous avons terminé. Pour une si petite quantité de code, il y a beaucoup à comprendre. Vous devriez voir que l'actualisation de la page une fois que tous les actifs sont mis en cache est assez rapide, mais faisons une vérification rapide (non scientifique) des temps de chargement sur une connexion limitée (DevTools> onglet Réseau).

Sans le technicien de service, le chargement sur un réseau 3G rapide simulé prend près de 30 secondes pour que tout se charge. Avec le Service Worker, avec la même connexion limitée mais le chargement à partir du cache, cela prend un peu moins d'une seconde.

Cochez la case Hors ligne et actualisez et vous verrez également que la page se charge sans connexion, bien que nous ne puissions pas obtenir les données de prévision de l'API. À la page 2, nous y reviendrons et apprendrons également à mettre en cache la réponse de l'API.

Page suivante: utilisez Service Worker pour offrir un accès en ligne

  • 1
  • deux

Page actuelle: Page 1: Chargement plus rapide

Page suivante Page 2: Ajout d'un accès hors ligne