A service worker can make a chatbot load quickly on repeat visits. It can also keep an old model alive long after a new release if caching rules treat mutable files as immutable.
The safe design starts with asset identity. Ask which URLs represent fixed content and which URLs are reused whenever a file changes.
Separate model bytes from policy revisions
An embedding model that does not change between releases can live in a persistent model cache. If its content changes, give the resource a new versioned identity. Otherwise a cache-first strategy has no reason to request the new bytes.
Policy manifests and weights are different when deployment reuses their URLs. They need revalidation or network-first fetching, plus a consistency check. A new manifest paired with old weights should trigger a recoverable fallback rather than unchecked inference.
Remember the HTTP cache
Service-worker Cache Storage and the browser HTTP cache are separate layers. Missing a response in Cache Storage does not necessarily force a transfer from the origin.
For mutable release assets, use request and response cache rules that permit fresh validation. For versioned, stable model resources, long reuse can be appropriate. Do not apply one lifetime to every JSON file merely because the extension matches.
Download only what is needed
Preloading every WASM runtime variant during service-worker activation can spend bandwidth before a visitor opens a chatbot. It may also fetch alternatives the browser will never select.
A lightweight page shell can install without downloading the embedding model. Load enhanced matching when the person chooses it, and let the runtime request the compatible binary. Basic keyword retrieval can remain available while the optional enhancement prepares.
Keep writes and partial responses out
An API POST must not enter a public asset cache. Likewise, a 206 Partial Content response is not a complete model file. Caching it under the full resource key can break later requests in confusing ways.
Handle or bypass range requests deliberately. Cache successful complete GET responses only, and leave unrelated origins and sensitive endpoints outside the service worker’s asset path.
Test a real update sequence
Visit with release A, then deploy release B and reload. Check both first and subsequent navigations. Next disconnect the network and revisit a cached page. Finally open an uncached route offline: it should explain that the page is unavailable, not masquerade as the home page.
Keep cache cleanup scoped to the application’s own prefix. A website can host other tools whose caches must survive your activation event.
See MDN’s service-worker guide and ask Web Platform Chat about cache strategies.