The Service Worker (Documentation Index
Fetch the complete documentation index at: https://mintlify.com/Miguelcds/App_AsignadorZonasBilbao/llms.txt
Use this file to discover all available pages before exploring further.
sw.js) handles pre-caching, cache invalidation, and offline fetch interception. Understanding how it works helps you deploy updates reliably.
Lifecycle events
The Service Worker has three lifecycle events: install, activate, and fetch.Install
On install, the Service Worker pre-caches every asset in theASSETS array:
cache.addAll(ASSETS) fetches and stores all listed resources atomically — if any single request fails, the install fails. After caching, self.skipWaiting() activates the new Service Worker immediately without waiting for existing tabs to close.
Activate
On activate, the Service Worker deletes every cache whose key does not match the currentCACHE name:
zonas-bilbao-v6.0.0) is removed. This keeps storage clean and ensures stale assets from old deployments cannot be served.
Fetch
The Service Worker uses a cache-first strategy:- A request comes in.
- The Service Worker checks the cache.
- If the resource is found in the cache, it is returned immediately — no network request.
- If the resource is not in the cache, the request is forwarded to the network.
Updating the app
When you deploy a new version of the app, you must bump theCACHE constant in sw.js:
zonas-bilbao-v6.2.0. This triggers the full update flow:
User visits the app
The browser detects that
sw.js has changed and installs the new Service Worker in the background.New Service Worker installs
The new Service Worker fetches and caches all assets under the new cache name.
skipWaiting() activates it immediately.Old caches are deleted
The activate event runs and removes all caches with keys that do not match the new
CACHE name.Service Worker registration
The registration code inindex.html handles the update detection and automatic reload:
onupdatefoundfires when the browser detects a newsw.js.onstatechangewatches the installing worker’s state.- When the new worker reaches
'installed'and a previous controller exists, the page reloads automatically to activate the fresh cache.
Troubleshooting
Users are still seeing the old version after deployment
Users are still seeing the old version after deployment
You most likely forgot to bump the
CACHE constant in sw.js. Update it and redeploy. The Service Worker compares the cache key on each load — if the key is unchanged, it considers the cache valid and serves old files.The Service Worker is not registering
The Service Worker is not registering
Check that the app is served over HTTPS (or
localhost). The Service Worker API is blocked on plain HTTP and file:// URLs. Verify in DevTools under Application → Service Workers.An asset fails to cache on install
An asset fails to cache on install
cache.addAll() is atomic — if one request fails, the entire install fails and the Service Worker does not activate. Check the browser console for network errors. Common causes: a CDN URL has changed, or a file path in ASSETS is incorrect.How do I force a cache clear manually?
How do I force a cache clear manually?
In Chrome DevTools, go to Application → Storage and click Clear site data. This removes all caches and unregisters the Service Worker. The next page load will reinstall it from scratch.
The app installed as a PWA is not updating
The app installed as a PWA is not updating
Installed PWAs use the same Service Worker update flow. Make sure you bumped the
CACHE version and redeployed. If the installed app still shows stale content, open it in the browser (not the standalone window) and hard-refresh, or clear site data from DevTools.