Please enable JavaScript.
Coggle requires JavaScript to display documents.
Service Worker - Coggle Diagram
Service Worker
Lifecycle
Install
- first event a service worker gets
- triggered as soon as the worker executes
- called once per service worker (browser considers service worker updates as a different service worker, and it'll get its own install even)
- the best moment to cache everything needed before being able to control clients
- promise passed to event.waitUntil() lets the browser know when your install completes, and if it was successful
- if promise rejects, this signals the install failed, and the browser throws the service worker away
Activate
- the service worker is ready to control clients and handle functional events like push and sync, but that doesn't mean the page that called .register() will be controlled immediately after having called .register
- it's possible to take control of uncontrolled clients by calling clients.claim() within your service worker once it's activated (rarely needed)
- if updating the service worker, this is the ideal time to do stuff that you couldn't do while the old worker was still in use, such as migrating databases and clearing caches
Download, parse, and execute
- navigator.serviceWorker.register is responsible for register the service worker (downloading, parsing and executing)
- if it fails download, parse, or throws an error in its initial execution, the register promise rejects, and the service worker is discarded
Waiting (only when it's been updating)
- after it's successfully installed, the updated service worker delays activating until the existing service worker is no longer controlling clients
- it's how the browser ensures that only one version of your service worker is running at a time
skip waiting phase
The waiting phase means you're only running one version of your site at once, but if you don't need that feature, you can make your new service worker activate sooner by calling self.skipWaiting().
This causes your service worker to kick out the current active worker and activate itself as soon as it enters the waiting phase (or immediately if it's already in the waiting phase). It doesn't cause your worker to skip installing, just waiting.
It doesn't really matter when you call skipWaiting(), as long as it's during or before waiting. It's pretty common to call it in the install event. But you may want to call it as a results of a postMessage() to the service worker. As in, you want to skipWaiting() following a user interaction.
-
Cache
-
Precaching
One feature of service workers is the ability to save a set of files to the cache when the service worker is installing. This is often referred to as "precaching", since you are caching content ahead of the service worker being used.
workbox-precaching
- it uses URLs version information (like a content hash) as cache keys without any further modification. URLs that don't include versioning information have an extra URL query parameter appended to their cache key (all of this during the service worker's install event.)
- it’s in the activate event that workbox-precaching will check for any cached assets that are no longer present in the list of current URLs, and remove those from the cache
-
Scope and control
Scope
The default scope of a service worker registration is ./. It means the file responsible for registering the service worker will determine its scope.
e.g.
site.com/index.js - scope is site.com
site.com/foo/index.js - scope is site.com/foo
site.com/foo/bar/index.js - scope is site.com/foo/bar
Control
client same of pages/workers/shared workers
Your service worker can only control clients that are in-scope. Once a client is "controlled", its fetches go through the in-scope service worker. You can detect if a client is controlled via navigator.serviceWorker.controller which will be null or a service worker instance.
Updating the service worker
- the service worker is considered updated if it's byte-different to the one the browser already has. (We're extending this to include imported scripts/modules too.)
- the updated service worker is launched alongside the existing one, and gets its own install event
- if the new worker has a non-ok status code (for example, 404), fails to parse, throws an error during execution, or rejects during install, the new worker is thrown away, but the current one remains active
- once successfully installed, the updated worker will wait until the existing worker is controlling zero clients. (Note that clients overlap during a refresh.)
- self.skipWaiting() prevents the waiting, meaning the service worker activates as soon as it's finished installing.
-
-
What is it?
A service worker is a type of web worker. It's essentially a JavaScript file that runs separately from the main browser thread, intercepting network requests, caching or retrieving resources from the cache, and delivering push messages.Features
- cache / offline
- push notification
- background sync
Because workers run separately from the main thread, service workers are independent of the application they are associated with. This has some consequences, for example, the service worker can not access local storage, cookies, or DOM. The solution is to use the postMessage feature to communicate with the page.