FRONT END

Home › Glossary › Front End· 373 ·

Service Workers

\\sur-vis wur-kers\\n.

Filed underFront EndSoftware Engineering

In brief · quick answer

Service Workers are JavaScript files that run in the background, separate from the web page, intercepting network requests and enabling offline functionality, push notifications, and background sync.

§ 1 Definition

A Service Worker is a type of web worker that acts as a programmable network proxy between the browser and the network. It is a JavaScript file that the browser runs in the background, on a separate thread from the web page, and can intercept, modify, or cache network requests. Service Workers enable offline web experiences, push notifications, background data synchronization, and custom cache management. They are the foundational technology behind Progressive Web Apps. Service Workers have a distinct lifecycle: installation (where you typically pre-cache static assets), activation (where you clean up old caches), and fetch events (where you implement caching strategies for each request). They operate only over HTTPS to prevent man-in-the-middle attacks on the caching layer.

§ 2 Lifecycle

A Service Worker progresses through three stages. Install fires when the browser downloads the Service Worker file. You listen for this event to pre-cache static assets (HTML shell, JavaScript bundles, CSS, images). Activate fires after installation completes and the old Service Worker is no longer controlling clients. This is where you clean up old caches. The Fetch event fires for every network request made by pages the Service Worker controls. You implement caching strategies here (Cache First, Network First, Stale While Revalidate). The Service Worker is updated by checking for a new script file; if the file differs byte-by-byte, the new version installs but waits until all pages using the old version are closed.

§ 3 Cache Storage API

Service Workers work with the Cache Storage API, which provides a programmable cache for Request/Response pairs. Unlike the browser's HTTP cache (controlled by Cache-Control headers), the Cache Storage API gives developers explicit control over what is cached, when it is cached, and when it is invalidated. Caches are named and versioned, allowing cache-busting on Service Worker updates. The Cache API is also available from the main thread, allowing pages to prime the cache before the Service Worker activates.

§ 4 Note

Common misunderstanding: Service Workers are not a caching tool for faster page loads in general. They are designed for offline resilience and background operations. For first-time visitors who have never cached content, the Service Worker does nothing. Another mistake: assuming a Service Worker speeds up the initial page load. It can slow it down if not implemented correctly, because the browser must start the worker before deciding whether to serve cached or fresh content. Service Workers should only be added when offline capability or background features are needed.

§ 5 In code

```javascript
// service-worker.js
const CACHE_NAME = 'my-app-v1';
const STATIC_ASSETS = ['/', '/index.html', '/app.js', '/style.css'];

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => cache.addAll(STATIC_ASSETS))
  );
});

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cached) => {
      return cached || fetch(event.request);
    })
  );
});
```

§ 6 Common questions

Q. Do Service Workers run when the browser is closed?: A. It depends. On Android, Service Workers can run periodically (background sync, push events) even when the browser is closed. On iOS, Service Worker lifecycle is tied to the browser process.
Q. Can Service Workers access the DOM?: A. No. Service Workers run on a separate thread and cannot access the DOM, window, or document objects. They can only communicate with pages via the postMessage API.

Key takeaways

Service Workers are programmable network proxies that enable offline and background capabilities.
They have a distinct lifecycle: install, activate, and fetch events.
Service Workers require HTTPS and cannot access the DOM. They run on a separate thread.

How Atomic Glue helps

Atomic Glue implements Service Workers strategically for clients who need offline capability, push notifications, or background syncing. We design caching strategies that match your content type and user behavior, ensuring your app works reliably on unreliable networks. Our team also builds Service Worker update workflows that prevent the common 'stale cache' problems that plague poorly implemented PWAs. This is part of our website development and mobile app services.

Get in touch

# Service Workers

Service Workers are JavaScript files that run in the background, separate from the web page, intercepting network requests and enabling offline functionality, push notifications, and background sync.

Category: Front End (also: Software Engineering)

Author: Atomic Glue Development Team

## Definition

## Lifecycle

## Cache Storage API

## Note

## In code

## Common questions
Q: Do Service Workers run when the browser is closed?
A: It depends. On Android, Service Workers can run periodically (background sync, push events) even when the browser is closed. On iOS, Service Worker lifecycle is tied to the browser process.
Q: Can Service Workers access the DOM?
A: No. Service Workers run on a separate thread and cannot access the DOM, window, or document objects. They can only communicate with pages via the postMessage API.

## Key takeaways

Service Workers are programmable network proxies that enable offline and background capabilities.
They have a distinct lifecycle: install, activate, and fetch events.
Service Workers require HTTPS and cannot access the DOM. They run on a separate thread.

## Related entries

Last updated June 2026. Permalink: atomicglue.co/glossary/service-workers