Service Worker

A service worker is a small script that a web browser runs in the background, separate from the web page itself. Ordinary JavaScript runs inside a page and dies when the tab closes; a service worker lives outside any single page and can keep working even when no tab is open. Its defining power is that it acts as a programmable network proxy: it can intercept the requests a site makes, for pages, images, or data, and decide how to answer them, serving a cached copy, fetching from the network, or combining both. That interception is what unlocks offline behavior. Once a service worker has cached the core files of a web app, the app can load and function without a connection, because the service worker answers the requests locally instead of failing. It is the engine underneath progressive web apps, or PWAs, which are websites that behave more like installed applications.

Service workers are event-driven, meaning they wake up to handle specific events and go dormant otherwise, which keeps them light. Two of those events matter most to marketers. The first is fetch, where the worker intercepts network requests and applies a caching strategy, making pages load fast and work offline. The second is push, which lets the worker receive a message from a server and show a notification even when the user is not on the site, the mechanism behind web push notifications. Because a service worker runs in the background and persists beyond the page, it can also power silent updates, syncing data or refreshing caches without the user doing anything. That persistence is exactly what makes it useful and what makes it worth understanding: it is code that keeps running when the page is gone.

A service worker is easy to confuse with a web worker, and the names do not help, but they do different jobs. A web worker is a background thread whose purpose is to run heavy computation off the main thread so the page stays responsive, crunching numbers, parsing large files, or processing images without freezing the interface. It has no special relationship to the network and no life beyond the page that created it; close the page and the web worker is gone. A service worker is a specialized kind of background script whose whole point is to sit between the app and the network as a proxy, handling requests, caching, and push. One is about computation; the other is about the network and persistence.

The practical differences follow from that. A web worker cannot intercept network requests or serve content offline; a service worker can, and that is its main reason to exist. A web worker lives and dies with its page; a service worker outlives the page, which is what lets it receive push notifications and run background sync when no tab is open. So if the goal is to keep a busy interface smooth during a big calculation, reach for a web worker. If the goal is to make a site load offline, cache assets intelligently, or send push notifications, you need a service worker. They can coexist in the same app doing their separate jobs, but treating one as a substitute for the other leads straight to disappointment, since a web worker will never make your site work offline, and a service worker is the wrong place to run pure number-crunching.

Service workers are powerful precisely because they intercept the network, which is also why they demand care. They only run over HTTPS, with localhost as the exception, a deliberate security requirement, since a script that can rewrite every network response could be dangerous over an insecure connection. The trickiest part is caching strategy: decide clearly what to serve from cache, what to fetch fresh, and how to update stale content, or users will see outdated pages long after you have shipped new ones. A stale or buggy service worker is a classic hard-to-diagnose problem, because it can keep serving old files from cache while you wonder why your changes are not appearing. Versioning caches and cleaning up old ones on update is essential discipline, not an afterthought.

For marketers, the value is concrete: faster repeat visits, resilient offline experiences, installable web apps, and, used honestly, web push as a re-engagement channel. Note the honesty point. Because a service worker can show push notifications even when the user is not on your site, it is easy to abuse, and browsers and users push back hard against sites that beg for notification permission on arrival or spam alerts. Ask for push permission in context, after you have earned it, and send notifications people actually want. The failures to avoid are caching that serves stale content, requesting push permission too aggressively, assuming support everywhere when older or restricted environments differ, and confusing a service worker with a web worker. Treated as the careful, offline-and-push proxy it is, a service worker meaningfully improves speed and re-engagement.

The name reuses the software idea of a worker, a background process, and service, its role standing between an app and the network.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where service worker is a core concern: