Service workers enable web sites to work offline using the Cache API. Developers need to design the logic to manage how site assets are persisted in storage.
This can lead to many challenges for developers to solve when planning their caching strategies.
How much is too much? And what is the minimum my application needs?
Page assets come in many forms, HTML, CSS, JavaScript, images and font files are obvious. These are all classified as URL addressable. This means you can type a URL in the browser address bar and retrieve the file.
Your origin (domain name) is given a certain amount of free space to do what it wants with. That free space is shared between all origin storage: LocalStorage, IndexedDB, Filesystem, and of course Caches. The amount available to service worker caching isn’t defined in the specification. The amount varies by browser depending on device and storage conditions.
Files are not the only content that can be cached. localStorage is great to persist key value pairs where the values are strings. IndexedDB is more robust and can store many more types of data efficiently. I think of it a a light weight document database in the browser. appCache and service worker cache persist files, URL addressable resources to be technically correct.
But service worker cache is not the only browser storage medium you need to monitor. In addition to the service worker cache size limit you should also ask the following questions:
- What is the IndexedDB size limit?
- What is the localStorage size limit?
You could add appCache to the mix, but of course that is moot when a service worker is registered. Plus appCache is being deprecated by all browsers today.
How much space do you get and what happens when that space runs out?
#progressive web app
