The primary difference is control. Browser cache is driven off Cache-Control headers, which is good, until its not. There are all sorts of strategies to manage how network addressable resources are cached; private, public; time to live, etc. With service worker caching you can programmatically control how those assets are persisted. But that means the … Read more
There are conceptually two kinds of updates, and it isn’t clear from your question which we’re talking about, so I’ll cover both. Updating content Eg: The text of a blog post The schedule for an event A social media timeline These will likely be stored in the cache API or IndexedDB. These stores live independently … Read more
The problem was that the service-worker.js file was stored in an assets sub-directory. Don’t do that: store the service-worker.js in the root of your app (or higher). That way your app can access the service-worker. See HTML5Rocks article — One subtlety with the register method is the location of the service worker file. You’ll notice … Read more
Service workers are basically a proxy between your web application and the internet, so it can intercept calls to the network if so desired. Scope in this instance refers to the path that the service worker will be able to intercept network calls from. The scope property can be used explicitly define the scope it … Read more
Many thanks to Mattias Buelens who pointed me in the right direction. Here’s a working example. The project structure is: dist src generic-tsconfig.json main (typescript files) tsconfig.json dedicated-worker (typescript files) tsconfig.json service-worker (typescript files) tsconfig.json src/generic-tsconfig.json This contains the config common to each project: { “compilerOptions”: { “target”: “esnext”, “module”: “esnext”, “strict”: true, “moduleResolution”: “node”, … Read more
Applying this change: ‘/service-worker.js’ // ❌ ‘./service-worker.js’ // ✅ fixed my issue. (in navigator.serviceWorker.register(‘/service-worker.js’)) Or maybe you need: ‘%PUBLIC_URL%/serviceworker.js’ Thank @DanielLord for his comment.
Service Workers give you complete control over network requests. You can return anything you want for the fetch event, it does not need to be the past or current contents of that particular file. However, if the HTTP cache handles your needs, you are under no obligation to use Service Workers. They are also used … Read more
If you know the cache name you can simply call caches.delete() from anywhere you like in the worker: caches.delete(/*name*/); And if you wanted to wipe all caches (and not wait for them, say this is a background task) you only need to add this: caches.keys().then(function(names) { for (let name of names) caches.delete(name); });
Serve your page over HTTPS or use localhost. Service workers require a Secure Context. (MDN page, Chromium page). The value of window.isSecureContext indicates whether [SecureContext] features are visible or hidden. (This is true on a file:// URL and the serviceWorker API will be visible, but it won’t work, of course.)
Note: As of Firefox 57, and Chrome 68, as well as the versions of Safari and Edge that support service workers, the default behavior has changed to account for the updated service worker specification. In those browsers, HTTP cache directives will, by default, be ignored when checking the service worker script for updates. The description … Read more