Service Worker
A service worker is a background script registered in the browser that runs independently of an open web page. It can intercept network requests, cache data offline, and — most importantly for marketing — receive incoming push events and display notifications even when the browser tab is closed.
What is a service worker?
A service worker is a JavaScript script registered in the browser that runs as a worker completely separate from the web page. While a normal web page terminates when its tab is closed, the service worker continues running in the background — even without any open tabs. It is the technical foundation of modern Progressive Web Apps (PWAs) and the only way to receive push notifications in the browser.
Service workers were introduced by Google in 2014 and are today supported in all modern browsers (Chrome, Edge, Firefox, Safari, Samsung Internet, Opera). They replace the older and now deprecated Application Cache API.
Service worker lifecycle
- Registration: The web page calls
navigator.serviceWorker.register('/sw.js'). The browser fetches the script and parses it. - Installation: The service worker runs its
installevent. Resources are typically pre-cached here. - Activation: After successful installation the browser activates the service worker. Old versions are shut down if present.
- Idle / Active: The service worker rests in the background and is only woken when an event arrives (push, sync, fetch).
- Termination: Browsers can terminate inactive service workers at any time to save memory. On the next event the worker is restarted.
Service worker and push notifications
For browser push notifications, the service worker is mandatory: it is the only recipient of the push event. As soon as an encrypted push message arrives from the push service, the browser wakes the service worker and delivers the event:
self.addEventListener('push', event => {
const data = event.data.json();
event.waitUntil(
self.registration.showNotification(data.title, {
body: data.body,
icon: data.icon,
badge: data.badge,
data: { url: data.url }
})
);
});
self.addEventListener('notificationclick', event => {
event.notification.close();
event.waitUntil(
clients.openWindow(event.notification.data.url)
);
});The system notification appears even when the browser tab is closed. When the user clicks it, the browser opens the target URL.
Offline functionality and caching
A second main feature of the service worker: intercepting network requests via the fetch event. This allows web pages to be usable offline (PWA pattern) by caching static resources and API responses. For SMB websites without app ambitions, push is the primary use case; PWA features are optional.
HTTPS requirement and scope
Service workers work exclusively over HTTPS (exception: localhost for development). A service worker can only intercept requests within its scope — by default the path of its file. A service worker registered under /sw.js covers the entire domain; one registered under /blog/sw.js covers only /blog/*.
Debugging
Chrome DevTools provides an overview of all registered workers under 'Application → Service Workers' with status, source, push test, and manual unregister. Firefox has a similar tab under about:debugging. Push events can be simulated from DevTools without actually sending a message.
Best practice for SMBs
- One service worker file per domain. Different workers for different paths quickly leads to inconsistent behaviour.
- Avoid versioning in the filename. Service workers are identified by the browser via their URL; with version suffixes every update needs re-registration. Better to version the file content instead (e.g. a constant
const SW_VERSION = '1.4'). - Always implement a notification click handler, otherwise clicking the notification opens nothing and the user is frustrated.
- Subscription renewal: Browsers can invalidate subscriptions without warning. Check on the next website visit and re-register if necessary.
Service worker with SendSeven
SendSeven provides a pre-configured service worker for the browser push channel that covers the complete push lifecycle (subscribe, receive, click, unsubscribe). Embedding requires a single line of code — no custom JavaScript setup needed. Anyone wanting their own customisations receives the service worker source and can fork it. Every push message is delivered encrypted via the Web Push API — GDPR-compliant, EU hosting, DPA under Art. 28 GDPR.