Service Worker lifecycle traps
Slap yourself if
You assume a Service Worker stays alive, think install/activate run once, or rely on in-memory state between events.
Why this exists
Because most production Service Worker bugs come from incorrect lifecycle assumptions that only fail under real-world timing, tab churn, or browser restarts.
Mental model
A Service Worker is an event-driven, ephemeral execution context owned by the browser. It wakes for events, does work, and is killed aggressively. Persistence is external or it doesn’t exist.
- A Service Worker is registered, then installed and activated asynchronously.
- After activation, the worker is started on-demand for events.
- The browser may terminate the worker immediately after an event completes.
- State in memory is lost between events and restarts.
- Keeping state in globals and expecting it to persist.
- Assuming fetch handlers always run on the latest version.
- Forgetting to handle waiting/active version coordination.
- Treating the worker as a long-lived background process.
Service Workers are short-lived, event-driven scripts whose lifecycle is controlled by the browser; any state must be persisted explicitly and version transitions must be handled.
- Calls it a background thread.
- Assumes continuous execution.
- Ignores waiting vs active states.
- Mentions caching without lifecycle coordination.
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.