--- title: Service Worker API slug: Web/API/Service_Worker_API tags: - API - Chargement - Service Workers - Workers - hors-ligne translation_of: Web/API/Service_Worker_API ---
{{ServiceWorkerSidebar}}
{{ SeeCompatTable() }}
Les service workers jouent essentiellement le rôle de serveurs proxy placés entre une application web, et le navigateur ou le réseau (lorsque disponible.) Ils sont destinés (entre autres choses) à permettre la création d'expériences de navigation déconnectée efficaces, en interceptant les requêtes réseau et en effectuant des actions appropriées selon que le réseau est disponible et que des ressources mises à jour sont à disposition sur le serveur. Ils permettront aussi d'accéder aux APIs de notifications du serveur (push) et de synchronisation en arrière-plan.
Un service worker est un worker événementiel enregistré auprès d'une origine et d'un chemin. Il prend la forme d'un fichier JavaScript qui peut contrôler la page ou le site web auquel il est associé, en interceptant et en modifiant la navigation et les requêtes de ressources, et en mettant en cache les ressources selon une granularité très fine pour vous donner une maîtrise complète de la manière dont doit se comporter votre application dans certaines situations (l'une des plus évidentes étant l'indisponibilité du réseau.)
Un service worker fonctionne dans le contexte d'un worker : il n'a donc pas d'accès au DOM, et s'exécute dans une tâche différente de celle du script principal de votre application, ainsi il est non-bloquant. Il est conçu pour être totalement asynchrone; en conséquence, des APIs telles que XHR en synchrone et localStorage ne peuvent pas être utilisées au sein d'un service worker.
Les service workers fonctionnent uniquement sur HTTPS, pour des raisons de sécurité. Laisser des requêtes réseau modifiées sans défense face aux attaques de l'homme du milieu est une bien mauvaise chose.
Note : les service workers ont rallié à eux des tentatives précédemment effectuées dans les mêmes domaines comme l'API AppCache parce qu'ils ne présument pas de ce que vous essayez de faire et ainsi s'interrompent quand ces suppositions ne sont pas tout à fait exactes; tout peut faire l'objet d'un contrôle d'une granularité très fine.
Note : les service workers font un usage intensif des promesses, comme généralement ils sont en attente de réponses, auxquelles ils réagissent alors différemment en cas de succès ou en cas d'erreur. L'architecture des promesses est idéale dans ces situations.
Un service worker est d'abord enregistré en utilisant la méthode {{domxref("ServiceWorkerContainer.register()")}}. En cas de succès, votre service worker sera téléchargé par le client et tentera l'installation/l'activation (voir ci-dessous) des URLs accédées par l'utilisateur au sein du domaine complet, ou bien au sein d'un sous-ensemble spécifié par vos soins.
A cette étape, votre service worker observera le cycle de vie suivant :
Le service worker est immédiatement téléchargé lorsqu'un utilisateur accède pour la première fois à une page ou à un site contrôlé par un service worker.
Après cela, il est téléchargé toutes les 24 heures environ. Il *peut* être téléchargé plus fréquemment, mais il doit être téléchargé toutes les 24 heures pour s'assurer que des scripts défectueux ne constitueraient pas une nuisance durable.
Une tentative d'installation a lieu lorsque le fichier téléchargé se trouve être nouveau — soit qu'il est différent d'un service worker existant (comparaison bit à bit), soit qu'il s'agit du premier service worker rencontré pour cette page ou ce site.
Si c'est la première fois qu'un service worker est rendu disponible, une tentative d'installation a lieu, puis en cas d'installation avec succès il est activé.
S'il existait déjà un service worker, la nouvelle version est installée en arrière-plan, mais pas encore activée — à cette étape, on parle de worker en attente. Il n'est activé que lorsqu'il n'y a plus aucune page chargée faisant encore usage de l'ancien service worker. Aussitôt qu'il n'y a plus de telles pages chargées, le nouveau service worker est activé (devenant le active worker.)
Vous pouvez guetter l'événement {{domxref("InstallEvent")}}; une action standard consiste à préparer l'usage de votre service worker quand cet événement est lancé, par exemple en créant un cache au moyen de l'API de stockage native, et en y plaçant les ressources dont vous avez besoin pour faire fonctionner de manière déconnectée votre application.
Il y a aussi un événement activate
. Lorsque cet événement se produit, c'est généralement le bon moment pour nettoyer les vieux caches et toutes les autres choses associées avec la version précédente de votre service worker.
Votre service worker peut répondre aux requêtes en utilisant l'événement {{domxref("FetchEvent")}}. Vous pouvez modifier la réponse à ces requêtes de la manière que vous souhaitez, en utilisant la méthode {{domxref("FetchEvent.respondWith") }}.
Note : Parce que oninstall
/onactivate
pourraient prendre du temps à s'exécuter, la spec service worker fournit une méthode waitUntil
qui, lorsque oninstall
ou onactivate
sont appelées, passe une promesse. Les événements fonctionnels ne sont pas envoyés au service worker tant que la promesse n'a pas été résolue avec succès.
Pour un tutoriel complet qui montre comment réaliser un premier exemple basique, il est conseillé de lire Utiliser les Services Workers.
Les service workers sont aussi destinés à être utilisés pour des choses telles que :
À l'avenir, les service workers seront capables de réaliser nombre d'autres tâches utiles au sein d'une plate-forme web, ce qui les rapprochera de la viabilité des applications natives. Il est intéressant de noter que d'autres spécifications peuvent ou commencent à faire usage du contexte des service workers, par exemple :
install
et activate
envoyés au {{domxref("ServiceWorkerGlobalScope")}} comme partie du cycle de vie d'un service worker. Cela garantit que tout événement fonctionnel (comme {{domxref("FetchEvent")}}) n'est pas envoyé au {{domxref("ServiceWorker")}} avant qu'il ne mette à jour des schémas de base de données, supprime des entrées de cache obsolètes, etc.FetchEvent
représente une action de recherche qui est envoyée au {{domxref("ServiceWorkerGlobalScope")}} d'un {{domxref("ServiceWorker")}}. Il contient des informations à propos de la requête et de la réponse résultante, et fournit la méthode {{domxref("FetchEvent.respondWith", "FetchEvent.respondWith()")}}, qui nous permet de produire une réponse arbitraire en retour à la page contrôlée.InstallEvent
représente une action d'installation qui est envoyée au {{domxref("ServiceWorkerGlobalScope")}} d'un {{domxref("ServiceWorker")}}. En tant qu'enfant de {{domxref("ExtendableEvent")}}, il garantit que les événements fonctionnels tels que {{domxref("FetchEvent")}} ne sont pas envoyés pendant l'installation. NotificationEvent
représente un événement de notification au clic qui est envoyé au {{domxref("ServiceWorkerGlobalScope")}} d'un {{domxref("ServiceWorker")}}.Le paramètre passé au gestionnaire sync, l'interface SyncEvent représente une action de synchronisation périodique qui est envoyée au {{domxref("ServiceWorkerGlobalScope")}} d'un ServiceWorker.
ServiceWorker
.Le paramètre passé au gestionnaire sync, l'interface SyncEvent représente une action de synchronisation qui est envoyée au {{domxref("ServiceWorkerGlobalScope")}} d'un ServiceWorker.
Spécification | Statut | Commentaire |
---|---|---|
{{SpecName('Service Workers', '')}} | {{Spec2('Service Workers')}} | Définition initiale. |