- Require HTTPS
- Doesn't have direct DOM access
- Can communicate with scripts on the pages though
- Can persist data with IndexedDB
- "programmable network proxy, allowing you to control how network requests from your page are handled"
- Scope: a service worker will see all requests under the directory it's fetched from. So for the entire domain, you'll need to load from
/sw.js
or similar. Loading from /example/sw.js
will result in it only having access under /example/
- Inspect service workers via chrome://inspect/#service-workers
- chrome://serviceworker-internals also contains some details
- Lifecycle notes
- If a page loads without a service worker, so will its subresources
- This can mean that a first page load will install and activate a service worker, and only on the second page load will it actually see fetches.
Updates
Updating a service worker can be a bit fiddly
- The new service worker will get installed but the old one will keep running - the new one will enter a
waiting
state
- Only when all site pages are closed will the old service worker be killed and the new service worker take control
- ❗ You can skip the waiting for activation by calling
self.skipWaiting()
in the install
eventListener.
- ‼️ Even better, in Chrome Devtools you can check "Update on Reload"
- Devtools also lets you Skip Waiting manually if you like
An update is triggered whenever you visit an in-scope page, though there are some other edge cases. It will check if the sw.js file is byte-identical to the loaded one.
Data to store
- A hash of the response, if the response isn't opaque
- The URL of the requesting page
- Hostname of the requesting page
- Hostname of the URL being fetched
- Path of the URL being fetched
- Whether cors was used
- Is there a clientID? What's that for? Just as a unique ID?