Les utilisateurs s'attendent à ce que les applications démarrent de manière fiable lorsque la connexion réseau est lente ou instable. même hors connexion. Ils s'attendent au contenu avec lequel ils ont interagi le plus récemment, tels que les pistes multimédias, les billets et les itinéraires, afin qu'ils soient disponibles et utilisables. Lorsqu'une requête n'est pas possible, ils s'attendent à ce que l'application leur fasse part une défaillance ou un plantage silencieux. Et ils veulent que tout cela se produise rapidement. En tant que que l'on peut voir en Des millisecondes, des millions, même une amélioration de 0,1 seconde du temps de chargement peut améliorer le taux de conversion de 10%. Les service workers permettent à votre progressive web app (PWA) de fonctionner jusqu'à de vos utilisateurs à vos attentes.
<ph type="x-smartling-placeholder">
Lorsqu'une application demande une ressource couverte par le champ d'application du service worker, un service worker intercepte la requête et agit comme un proxy réseau, même si le service l'utilisateur est hors connexion. Il peut ensuite décider s'il doit diffuser ou non la ressource à l'aide de l'API Cache Storage, diffusez-les à partir du réseau comme s'il n'existait un service worker actif, ou le créer à partir d'un algorithme local. Cela vous permet offrent une expérience de qualité, comme celle d'une application de plate-forme, l'application est hors connexion.
Enregistrer un service worker
Pour qu'un service worker prenne le contrôle de votre page, vous devez l'enregistrer auprès de votre PWA. Ainsi, la première fois qu'un utilisateur ouvre votre PWA, l'intégralité de son réseau sont envoyées directement à votre serveur, car le service worker n'a pas un contrôle total sur vos pages.
Après avoir vérifié si le navigateur est compatible avec l'API Service Worker, votre PWA peut pour enregistrer un service worker. Une fois le chargement terminé, le service worker se configure entre votre PWA et le réseau, en interceptant les requêtes et en diffusant des réponses correspondantes.
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register("/serviceworker.js");
}
Vérifier si un service worker est enregistré
Pour vérifier si un service worker est enregistré, utilisez les outils pour les développeurs dans votre votre navigateur favori.
Dans les navigateurs Firefox et Chromium (Microsoft Edge, Google Chrome ou Samsung Internet):
- Ouvrez les outils pour les développeurs, puis cliquez sur l'onglet Application.
- Dans le volet de gauche, sélectionnez Service workers.
- Vérifier que l'URL de script du service worker s'affiche avec l'état "Activé". (Pour en savoir plus, consultez Cycle de vie.) Sur Firefox, l'état peut être "En cours d'exécution" ou "Arrêté".
Dans Safari:
- Cliquez sur Développer > Service workers.
- Recherchez dans ce menu une entrée avec l'origine actuelle. En cliquant sur cette entrée ouvre un outil d'inspection sur le contexte du service worker.
Champ d'application
Le dossier dans lequel se trouve votre service worker détermine son champ d'application. Un service worker
qui se trouve dans example.com/my-pwa/sw.js peut contrôler toute navigation dans
chemin d'accès my-pwa, tel que example.com/my-pwa/demos/. Les service workers peuvent
contrôler uniquement les éléments (pages, nœuds de calcul, collectivement "clients") compris dans son champ d'application.
Ce champ d'application s'applique aux onglets de navigateur et aux fenêtres de PWA.
Un seul service worker par champ d'application est autorisé. Lorsqu'un service worker est actif et en cours d'exécution, une seule instance est généralement disponible, quel que soit le nombre (fenêtres PWA ou onglets de navigateur) sont en mémoire.
Safari propose une gestion plus complexe des champs d'application, appelée partitions, qui affecte la façon dont les champs d'application fonctionnent avec les iFrames interdomaines. Pour en savoir plus sur WebKit mise en œuvre, consultez leur article de blog.
Cycle de vie
Les service workers ont un cycle de vie qui détermine leur mode d'installation, séparément de votre installation PWA.
Le cycle de vie d'un service worker commence par son enregistrement. La
le navigateur tente alors de télécharger et
d'analyser le fichier Service Worker. Si l'analyse
réussit, l'événement install du service worker est déclenché. L'événement install
ne se déclenche qu'une seule fois.
L'installation d'un service worker s'effectue en mode silencieux, sans nécessiter l'autorisation de l'utilisateur. même si l'utilisateur n'installe pas la PWA. L'API Service Worker est disponible même sur les plates-formes qui ne sont pas compatibles avec l'installation de PWA, comme Safari et Firefox sur les ordinateurs
Après l'installation, vous devez activer le service worker
contrôler ses clients, y compris votre PWA. Lorsque le service worker est prêt à
contrôler ses clients, l'événement activate se déclenche. Toutefois, par défaut,
ne peut pas gérer la page qui l'a enregistrée avant le
chaque fois que vous accédez à cette page en la renouvelant ou en rouvrant la PWA.
Vous pouvez écouter des événements dans le champ d'application global du service worker à l'aide de l'self
objet:
serviceworker.js
// This code executes in its own worker or thread
self.addEventListener("install", event => {
console.log("Service worker installed");
});
self.addEventListener("activate", event => {
console.log("Service worker activated");
});
Mettre à jour un service worker
Les service workers sont mis à jour lorsque le navigateur détecte qu'ils ont été définis. qui contrôle le client et la nouvelle version du fichier de service worker à partir du sont différentes en octets.
Après une installation réussie, le nouveau service worker attend jusqu'à ce que l'ancien service worker ne contrôle plus aucun client. Cet état s'appelle "en attente", et c'est ainsi que le navigateur s'assure qu'une seule version un service worker s'exécute à un moment donné.
Le nouveau service worker ne prend pas en compte l'actualisation d'une page ou la réouverture de la PWA. le contrôle. L'utilisateur doit fermer ou quitter tous les onglets et toutes les fenêtres en utilisant au service worker actuel, puis revenez en arrière pour attribuer au nouveau service worker le contrôle. Pour en savoir plus, consultez la section Cycle de vie d'un service worker.
Durée de vie d'un service worker
Un service worker installé et enregistré peut gérer toutes les requêtes réseau dans son champ d'application. Il s'exécute sur son propre thread, avec activation et fin par le navigateur, ce qui lui permet de fonctionner avant même que votre PWA soit ouverte ou après sa fermeture. Les service workers s'exécutent sur leur propre thread, mais à l'état en mémoire peuvent ne pas persister entre les exécutions d'un service worker. Par conséquent, assurez-vous que tout ce que vous à réutiliser pour chaque exécution est disponible dans IndexedDB ou dans une autre stockage persistant.
S'il n'est pas déjà en cours d'exécution, un service worker démarre chaque fois qu'une requête réseau est envoyé dans son champ d'application, ou lorsqu'il reçoit un événement déclencheur tel qu'un événement en arrière-plan ou un message push.
Les service workers sont arrêtés après quelques secondes d'inactivité, il est occupé depuis trop longtemps. Le délai nécessaire à cette opération varie d'un navigateur à l'autre. Si un un service worker a été arrêté et un événement qui le démarre. il redémarre.
Fonctionnalités
Un service worker enregistré et actif utilise un thread avec un service à partir du thread principal de votre PWA. Toutefois, le paramètre par défaut le fichier de service worker lui-même n'a aucun comportement. Il ne met en cache ni ne diffuse les ressources, voici ce que votre code doit faire. Vous découvrirez comment dans les chapitres suivants.
Les capacités des service workers ne concernent pas uniquement le proxy ou la diffusion de requêtes HTTP. D'autres fonctionnalités sont disponibles à d'autres fins, comme la lecture en arrière-plan, l'exécution de code, les notifications push Web et le traitement des paiements. Nous discuterons ces ajouts dans la section Fonctionnalités.