Service Workers in a PWA: What They Do and Why You Need One

What a Service Worker Is and Where It Runs

A service worker is a JS file the browser runs on a separate thread from the page itself, one that keeps running even after the tab closes. It has no access to the DOM, but it can intercept network requests, cache responses, and receive events from a push server. It's a hard requirement for a PWA — without a registered service worker, a browser won't treat a site as installable.

Offline Mode: Cache Instead of a Blank Screen

Through the Cache API, a service worker stores static assets — icons, fonts, UI shell — and can serve them even without a network connection or on flaky mobile data. Users don't see a blank screen or a load error; the app opens instantly, which matters a lot on geos with slow or expensive mobile internet. It's not full offline functionality, it's a buffer against a bad connection at launch.

Push Only Works Through a Service Worker

The Web Push API delivers push events straight to the service worker, not to an open page — so a user can get a push even with the PWA closed or in the background. The service worker decides how the notification looks (title, body, icon, click action) and where the tap should land. Without an active, registered service worker, a push engine has no way to deliver anything to the device at all.

Lifecycle: Install, Activate, Updates

A service worker moves through install (first registration, initial cache fill), activate (switching to a new version), and then sits in the background listening for fetch and push events. When the worker's code changes, the browser holds the new version in waiting and only activates it once every tab running the old version is closed — which is why PWA updates sometimes don't apply right away. Cache versioning is how you avoid getting stuck on stale logic for weeks.

What You Don't Need to Configure by Hand in APEX

A buyer doesn't need to write caching logic, handle fetch events, or manage push-subscription retries manually — APEX generates and maintains the service worker for every PWA under the hood, including version bumps when the prelander changes. Manual service worker work only comes up if you're building a PWA outside the platform and wiring up your own push provider.

Common Issues to Watch For

The most frequent issue is a service worker registered with the wrong scope, so it never intercepts the pages it should. The second is HTTPS: a service worker simply won't register over plain HTTP, aside from localhost. The third is a stale worker version stuck in a user's browser cache, so prelander updates don't land until an activate cycle finally runs.

FAQ

Is a service worker the same thing as a regular page script?

No. A regular script only runs while the page is open and can touch the DOM. A service worker runs on a separate background thread with no DOM access, and it can keep working even after the tab closes.

Can a PWA receive push notifications without a service worker?

No — that's architecturally impossible. The Web Push API delivers notifications specifically to the service worker; there's no other way for a browser to receive a push in the background.

Why do users still see an old version after I update the prelander?

That's the standard lifecycle at work: a new service worker version waits for every old tab to close before activating. A fresh visit or reinstall usually resolves it.

Do I need to write service worker code myself when using APEX?

No — APEX generates and updates the service worker automatically for every PWA, no manual code required.

Does a service worker behave the same on iOS as on Android?

It's supported, but historically with tighter limits on offline caching and push — worth factoring in when you're estimating push-base reach on iOS traffic.

Read also

• Что такое PWA в арбитраже трафика
• Клоака для Facebook в PWA