Service Worker Activate Event

The `activate` event runs when a newly installed service worker becomes the active worker. It is commonly used to remove obsolete caches, migrate stored data, and perform other one-time activation tasks before the worker handles events.

A service worker progresses through installation and activation before it can become the active worker for a scope. The browser dispatches an `activate` event when the worker enters the activating state, making this the appropriate lifecycle point for cleanup and migration work.

An `activate` handler receives an `ExtendableEvent`. Because cleanup or migration can be asynchronous, call `event.waitUntil()` with a promise representing that work. This tells the browser to keep the activation process alive until the promise settles.

A common pattern is cache versioning: define the cache names needed by the current worker, then delete older cache entries during activation. This prevents outdated cached assets from accumulating across service-worker versions.

Activation does not automatically mean every currently open page is immediately controlled by the new worker. Existing clients may remain under the previous controller until they are navigated or otherwise become controlled; `clients.claim()` can request control of uncontrolled clients after activation.

For migrations, keep activation work reliable and reasonably small. If a promise passed to `waitUntil()` rejects, activation can fail, so error handling and migration ordering matter.

Key points

• `activate` runs when a service worker is being activated.
• Use `event.waitUntil()` for asynchronous cleanup or migration.
• Deleting obsolete caches is a common activation task.
• `clients.claim()` can let an activated worker take control of existing uncontrolled clients.
• Activation and client control are related but distinct lifecycle concepts.

Interview questions

What is the purpose of the service worker `activate` event?

The `activate` event runs when a newly installed service worker is transitioning to active status. It is commonly used to clean up resources belonging to older worker versions, especially outdated caches. It can also be used for data migrations or other initialization that belongs to the active version. Asynchronous work should be connected to `event.waitUntil()`.

Why should cache cleanup in an `activate` handler use `event.waitUntil()`?

Cache deletion is asynchronous, so the handler needs to tell the browser that the work is part of activation. `event.waitUntil()` extends the lifetime of the activation event until the supplied promise settles. Without it, the browser is not required to wait for that asynchronous operation as part of the event. A rejection also indicates that the activation work failed.

Does an activated service worker immediately control all open pages?

No. Activation and client control are separate concepts. Existing clients may not be controlled by the newly activated worker until a navigation or another control transition occurs. A worker can call `clients.claim()` after activation to request control of uncontrolled clients within its scope. Whether this is desirable depends on the application's update behavior.

How would you safely remove old service-worker caches during activation?

I would give each worker version a distinct cache name and define which names belong to the current version. During `activate`, I would enumerate cache names and delete only those not recognized as current. I would wrap the complete cleanup promise in `event.waitUntil()`. This makes the cleanup part of activation and avoids deleting caches that the current worker still needs.