Service Worker

After a page registers a service worker, the browser manages its installation, activation and lifecycle separately from the page’s main JavaScript. A service worker does not directly access the page’s DOM. It can respond to supported fetch events, use Cache Storage and coordinate with pages through messages to implement resilient application behavior. These capabilities are useful in progressive web applications but are not required for every website.

A practical example is an appointment portal that caches essential interface files so the customer sees a useful offline screen if connectivity fails. The development team must choose which responses may be cached and for how long. Caching authenticated account pages or out-of-date pricing without careful controls can create security and accuracy problems; testing should cover first visits, updates and returning users.

Service workers normally require secure contexts such as HTTPS, with localhost treated specially during development. They differ from server-side Cloudflare Workers, which execute at a network edge rather than within a visitor’s browser. They also differ from Web Workers used mainly for background computation without the same network-proxy lifecycle.