--- title: Service Worker API slug: Web/API/Service_Worker_API tags: - API - Landing - NeedsTranslation - Offline - Overview - Reference - Service Workers - TopicStub - Workers translation_of: Web/API/Service_Worker_API ---
{{ServiceWorkerSidebar}}
{{ SeeCompatTable() }}
Service workers essentially act as proxy servers that sit between web applications, and the browser and network (when available). They are intended to (amongst other things) enable the creation of effective offline experiences, intercepting network requests and taking appropriate action based on whether the network is available and updated assets reside on the server. They will also allow access to push notifications and background sync APIs.
A service worker is an event-driven worker registered against an origin and a path. It takes the form of a JavaScript file that can control the web page/site it is associated with, intercepting and modifying navigation and resource requests, and caching resources in a very granular fashion to give you complete control over how your app behaves in certain situations (the most obvious one being when the network is not available.)
A service worker is run in a worker context: it therefore has no DOM access, and runs on a different thread to the main JavaScript that powers your app, so it is not blocking. It is designed to be fully async; as a consequence, APIs such as synchronous XHR and localStorage can't be used inside a service worker.
Service workers only run over HTTPS, for security reasons. Having modified network requests wide open to man in the middle attacks would be really bad.
Note: Service Workers win over previous attempts in this area such as AppCache because they don't make assumptions about what you are trying to do and then break when those assumptions are not exactly right; you have granular control over everything.
Note: Service workers make heavy use of promises, as generally they will wait for responses to come through, after which they will respond with a success or failure action. The promises architecture is ideal for this.
A service worker is first registered using the {{domxref("ServiceWorkerContainer.register()")}} method. If successful, your service worker will be downloaded to the client and attempt installation/activation (see below) for URLs accessed by the user inside the whole origin, or inside a subset specified by you.
At this point, your service worker will observe the following lifecycle:
The service worker is immediately downloaded when a user first accesses a service worker–controlled site/page.
After that it is downloaded every 24 hours or so. It *may* be downloaded more frequently, but it must be downloaded every 24h to prevent bad scripts from being annoying for too long.
Installation is attempted when the downloaded file is found to be new — either different to an existing service worker (byte-wise compared), or the first service worker encountered for this page/site.
If this is the first time a service worker has been made available, installation is attempted, then after a successful installation it is activated.
If there is an existing service worker available, the new version is installed in the background, but not yet activated — at this point it is called the worker in waiting. It is only activated when there are no longer any pages loaded that are still using the old service worker. As soon as there are no more such pages still loaded, the new service worker activates (becoming the active worker).
You can listen out for the {{domxref("InstallEvent")}}; a standard action is to prepare your service worker for usage when this fires, for example by creating a cache using the built in storage API, and placing assets inside it that you'll want for running your app offline.
There is also an activate
event. The point where this event fires is generally a good time to clean up old caches and other things associated with the previous version of your service worker.
Your service worker can respond to requests using the {{domxref("FetchEvent")}} event. You can modify the response to these requests in any way you want, using the {{domxref("FetchEvent.respondWith") }} method.
Note: Because oninstall
/onactivate
could take a while to complete, the service worker spec provides a waitUntil
method that, when called oninstall
or onactivate
, passes a promise. Functional events are not dispatched to the service worker until the promise successfully resolves.
For a complete tutorial to show how to build up your first basic example, read Using Service Workers.
Service workers are also intended to be used for such things as:
In the future, service workers will be able to do a number of other useful things for the web platform that will bring it closer towards native app viability. Interestingly, other specifications can and will start to make use of the service worker context, for example:
install
and activate
events dispatched on the {{domxref("ServiceWorkerGlobalScope")}} as part of the service worker lifecycle. This ensures that any functional events (like {{domxref("FetchEvent")}}) are not dispatched to the {{domxref("ServiceWorker")}} until it upgrades database schemas, deletes outdated cache entries, etc.FetchEvent
represents a fetch action that is dispatched on the {{domxref("ServiceWorkerGlobalScope")}} of a {{domxref("ServiceWorker")}}. It contains information about the request and resulting response, and provides the {{domxref("FetchEvent.respondWith", "FetchEvent.respondWith()")}} method, which allows us to provide an arbitrary response back to the controlled page.InstallEvent
interface represents an install action that is dispatched on the {{domxref("ServiceWorkerGlobalScope")}} of a {{domxref("ServiceWorker")}}. As a child of {{domxref("ExtendableEvent")}}, it ensures that functional events such as {{domxref("FetchEvent")}} are not dispatched during installation. NotificationEvent
interface represents a notification click event that is dispatched on the {{domxref("ServiceWorkerGlobalScope")}} of a {{domxref("ServiceWorker")}}.ServiceWorker
object.The SyncEvent interface represents a sync action that is dispatched on the {{domxref("ServiceWorkerGlobalScope")}} of a ServiceWorker.
Specification | Status | Comment |
---|---|---|
{{SpecName('Service Workers')}} | {{Spec2('Service Workers')}} | Initial definition. |
Feature | Chrome | Firefox (Gecko) | Internet Explorer | Opera | Safari (WebKit) |
---|---|---|---|---|---|
Basic support | {{CompatChrome(40.0)}} | {{ CompatGeckoDesktop("44.0") }}[1] | {{ CompatNo() }} | 24 | {{ CompatNo() }} |
install/activate events | {{ CompatChrome(40.0) }} | {{ CompatGeckoDesktop("44.0") }}[1] | {{ CompatNo() }} | {{ CompatVersionUnknown() }} | {{ CompatNo() }} |
fetch event/request/respondWith() |
{{CompatChrome(40.0)}} | {{ CompatGeckoDesktop("44.0") }}[1] | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
caches/cache |
{{CompatChrome(42.0)}} |
{{ CompatGeckoDesktop("39.0") }}[1] | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
Feature | Android | Chrome for Android | Firefox Mobile (Gecko) | Firefox OS | IE Phone | Opera Mobile | Safari Mobile |
---|---|---|---|---|---|---|---|
Basic support | {{CompatChrome(40.0)}} | {{ CompatGeckoMobile("44.0") }} | {{ CompatVersionUnknown }} | {{ CompatNo() }} | {{ CompatVersionUnknown() }} | {{ CompatNo() }} | |
install/activate events | {{ CompatNo() }} | {{CompatChrome(40.0)}} | {{ CompatGeckoMobile("44.0") }} | {{ CompatVersionUnknown }} | {{ CompatNo() }} | {{ CompatVersionUnknown() }} | {{ CompatNo() }} |
fetch event/request/respondWith() |
{{ CompatNo() }} | {{CompatChrome(40.0)}} | {{ CompatGeckoMobile("44.0") }} | {{ CompatVersionUnknown }} | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
caches/cache | {{ CompatNo() }} | {{CompatChrome(40.0)}} | {{ CompatGeckoMobile("39.0") }} | {{ CompatVersionUnknown }} | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
[1] Service workers (and Push) have been disabled in the Firefox 45 Extended Support Release (ESR.)