• 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?