← Home ← Codex ← DEBT ← Engine
Browse by Category
+ added · updated 7d
← Back to glossary

Service Worker

Mobile Intermediate
debt(d8/e5/b6/t7)
d8 Detectability Operational debt — how invisible misuse is to your safety net

Closest to 'silent in production until users hit it' (d9), slightly better at d8 because Lighthouse/PWA audits can flag missing or misconfigured service workers, but most issues (wrong scope, stale cache, missing activate cleanup) only surface when users report broken offline behaviour or stale assets.

e5 Effort Remediation debt — work required to fix once spotted

Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix shows a non-trivial implementation: sw.js at root, install/fetch/activate handlers, cache versioning. Fixing a scope mistake requires moving the file and re-registering; fixing stale-cache requires versioning strategy across the worker.

b6 Burden Structural debt — long-term weight of choosing wrong

Closest to 'strong gravitational pull' (b7), scored b6 because while it shapes asset deployment, cache-busting strategy, and update flow across the whole frontend, it's contained to the client-side layer. Every static asset change must consider cache versioning.

t7 Trap Cognitive debt — how counter-intuitive correct behaviour is

Closest to 'serious trap' (t7). The misconception (registering a SW gives automatic offline support) directly contradicts reality — an empty SW does nothing. Scope rules (subdirectory placement silently limiting control) and cache versioning gotchas compound this; the 'obvious' mental model is wrong.

About DEBT scoring →

Also Known As

SW service-worker fetch interceptor background worker sw.js

TL;DR

A JavaScript file that runs in the background separate from the web page, intercepting network requests to enable offline support, background sync, and push notification delivery.

Explanation

A service worker is a type of web worker registered against an origin and scope. It runs in its own thread, has no DOM access, and persists beyond the page lifecycle. Its primary power is the fetch event — every network request from pages in its scope passes through the service worker, allowing it to serve cached responses, fall back to the network, or return custom responses. The service worker lifecycle has three states: installing (downloading and caching assets), waiting (ready but not yet active), and active (controlling pages). Cache strategies implemented in service workers include: cache-first (serve from cache, fall back to network), network-first (try network, fall back to cache), and stale-while-revalidate (serve cache immediately, update in background).

Common Misconception

Service workers cache everything automatically once registered. A service worker only caches what you explicitly tell it to cache in your install event or fetch handler. An empty service worker registration does nothing — you must implement the caching strategy in JavaScript. Many developers register a service worker expecting automatic offline support and are confused when it does not appear.

Why It Matters

Service workers are the technical foundation of offline-capable web apps, background sync, and push notifications. Without a service worker, a PHP application is completely unavailable when the user is offline. With a simple cache-first service worker caching the app shell, the application loads instantly on repeat visits and remains functional without a network connection. This is the highest-impact performance optimisation available for repeat visitors — cached assets load from disk in under 50ms versus 200–2000ms over the network.

Common Mistakes

  • Placing the service worker script in a subdirectory — a service worker at /app/sw.js only controls pages under /app/; place it at /sw.js to control the entire origin.
  • Not versioning the cache name — when you update assets, increment the cache version string to trigger installation of a new worker and deletion of the old cache.
  • Caching API responses that should never be stale — use network-first or stale-while-revalidate for dynamic data, not cache-first.
  • Not handling the activate event to delete old caches — old cache versions accumulate and consume disk space if not cleaned up.

Code Examples

✗ Vulnerable
// Empty service worker — does nothing
self.addEventListener('install', () => {});
self.addEventListener('fetch', () => {});
// User gets no offline support despite registration
✓ Fixed
const CACHE = 'app-v1';
const ASSETS = ['/', '/style.css', '/app.js', '/offline.html'];

// Cache assets on install
self.addEventListener('install', e => {
    e.waitUntil(caches.open(CACHE).then(c => c.addAll(ASSETS)));
});

// Delete old caches on activate
self.addEventListener('activate', e => {
    e.waitUntil(caches.keys().then(keys =>
        Promise.all(keys.filter(k => k !== CACHE).map(k => caches.delete(k)))
    ));
});

// Cache-first with network fallback
self.addEventListener('fetch', e => {
    e.respondWith(
        caches.match(e.request)
            .then(cached => cached || fetch(e.request))
            .catch(() => caches.match('/offline.html'))
    );
});

Added 23 Mar 2026
Views 145
Rate this term
No ratings yet
🤖 AI Guestbook educational data only
| |
Last 30 days
0 pings S 1 ping M 0 pings T 0 pings W 2 pings T 0 pings F 2 pings S 0 pings S 2 pings M 0 pings T 1 ping W 1 ping T 0 pings F 0 pings S 1 ping S 0 pings M 0 pings T 0 pings W 2 pings T 0 pings F 0 pings S 3 pings S 0 pings M 0 pings T 0 pings W 1 ping T 1 ping F 0 pings S 2 pings S 0 pings M
No pings yet today
Amazonbot 2
Amazonbot 23 Scrapy 12 Ahrefs 10 PetalBot 10 Google 9 Perplexity 7 Bing 4 Meta AI 3 Brave Search 3 ChatGPT 2 Twitter/X 2 Applebot 2 SEMrush 2 Sogou 1 Baidu 1
crawler 90 crawler_json 1
DEV INTEL Tools & Severity
🔵 Info ⚙ Fix effort: Medium
⚡ Quick Fix
Place sw.js at the root, version your cache name ('v2'), cache static assets in install event, serve from cache with network fallback in fetch event, delete old caches in activate event


✓ schema.org compliant