title: Service Workers

> A service worker is a script that is run by your browser in the background, separate from a web page, opening the door to features which don’t need a web page or user interaction. Today, they already include features like [push notifications](https://developers.google.com/web/updates/2015/03/push-notifications-on-the-open-web) and in the future it will include other things like, background sync, or geofencing. The core feature discussed in this tutorial is the ability to intercept and handle network requests, including programmatically managing a cache of responses.
>
> The reason this is such an exciting API is that it allows you to support offline experiences, giving developers complete control over what exactly that experience is.
> 
> <cite>*[Introduction to Service Worker](http://www.html5rocks.com/en/tutorials/service-worker/introduction/)* ([cache](/david/cache/64fd51915364724e3489270d05a68907/))</cite>

[Il y a quinze jours](/david/stream/2015/11/08/) je commençais à m’intéresser sérieusement aux *Service Workers* et depuis [Jeremy Keith](https://adactio.com/journal/9775) ([cache](/david/cache/c730e6d1352203b60f954d9850a0dfce/)) puis [Brandon Rozek](https://brandonrozek.com/2015/11/service-workers/) ([cache](/david/cache/8bd7ed4d765d27a4455c9979db78f203/)) ont implémenté leurs premières itérations suivis de près par [une annonce de David Walsh](https://hacks.mozilla.org/2015/11/offline-service-workers/) ([cache](/david/cache/855debdfdc494d53ccf8e1939ea85362/)) sur le lancement de [serviceworke.rs](https://serviceworke.rs/) par Mozilla. Au-delà de l’aspect *offline* [décrit par le Guardian](https://www.theguardian.com/info/developer-blog/2015/nov/04/building-an-offline-page-for-theguardiancom) ([cache](/david/cache/6123a07505f79305c1a46f13131917af/)) et [CSS Tricks](https://css-tricks.com/serviceworker-for-offline/) ([cache](/david/cache/cafe9b16715f3da507547bbde95f89ac/)), on peut aller plus loin comme faire du [chargement dynamique d’images en fonction du support par le navigateur](https://www.aaron-gustafson.com/notebook/speeding-things-up-with-service-worker-resource-hints-and-more/) ([cache](/david/cache/3d972c32b16f08bca1aec9f23c059ed0/)) ! Même si c’est [peu supporté pour l’instant](http://caniuse.com/#feat=serviceworkers), ça donne envie d’essayer pour ceux qui en ont la capacité (sans effets de bords pour les autres).

**Les Service Workers ouvrent clairement une autre dimensions dans le développement web.** Et pourtant, je ne peux m’empêcher de voir les risques associés. Peu de contrôle est laissé à l’utilisateur pour gérer son cache — cette responsabilité étant [laissée aux développeurs](https://adactio.com/journal/9844) ([cache](/david/cache/dfe747a193bf51d2fa8680797ab29d7f/)) — ce qui signifie que chaque requête coûte potentiellement beaucoup plus que le contenu affiché. Aucun article sus-cité ne mentionne le surcoût en terme de bande passante de télécharger des pages dans le dos de l’utilisateur et pourtant cette pratique va se généraliser. Bientôt des extensions pour limiter un tel usage ?

Si je vais au bout de mon implémentation, je ferais en sorte de laisser le choix au visiteur concernant la taille et le nombre de requêtes à effectuer via les *Service Workers*. C’est la moindre des choses. **Asynchrone ne veut pas dire gratuit, l’anticipation d’une déconnexion doit rester un choix explicite.** Au passage, j’ai découvert [upup](https://www.talater.com/upup/).