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

Service Workers & Offline Caching

Frontend ES2015 Intermediate
debt(d7/e5/b5/t7)
d7 Detectability Operational debt — how invisible misuse is to your safety net

Closest to 'only careful code review or runtime testing' (d7) — Lighthouse can flag missing PWA features, but stale HTML caching and bad strategies typically only surface after deployment when users report stale content.

e5 Effort Remediation debt — work required to fix once spotted

Closest to 'touches multiple files / significant refactor in one component' (e5) — quick_fix says swap to Workbox with network-first for HTML and cache-first for assets, which involves rewriting the SW registration, strategies, and cache versioning logic.

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

Closest to 'persistent productivity tax' (b5) — service worker lifecycle and cache invalidation shape every deploy and asset-versioning decision in the web frontend context.

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

Closest to 'serious trap' (t7) — misconception suggests it's easy with Workbox, but the SW update lifecycle (waiting for old tabs, stale HTML, opaque responses, caching authenticated APIs) contradicts intuitive caching behavior.

About DEBT scoring →

Also Known As

service worker Workbox cache strategies offline caching

TL;DR

A JavaScript worker that intercepts network requests and serves responses from cache — enabling offline access, faster loads, and background sync.

Explanation

Service Workers run in a separate thread, intercept fetch events, and implement caching strategies: Cache First (serve from cache, fall back to network — ideal for static assets), Network First (try network, fall back to cache — for fresh content), Stale While Revalidate (serve cache immediately, update in background — balance of speed and freshness), Cache Only, and Network Only. Workbox (Google) simplifies service worker patterns. Lifecycle: install (precache static assets), activate (clean old caches), fetch (intercept requests). Service workers require HTTPS (or localhost).

Common Misconception

Service workers are complex to implement from scratch — Workbox provides high-level caching strategies with two lines of configuration, abstracting the complex service worker lifecycle.

Why It Matters

A site without a service worker re-downloads static assets on every visit — a service worker with Cache First for assets reduces repeat visit load time to near-zero for cached resources.

Common Mistakes

  • Cache First for HTML pages — users see stale content after deploys.
  • No cache versioning — old caches never cleaned, storage grows indefinitely.
  • Caching third-party resources without CORS headers — cached responses may be opaque.
  • Not handling service worker update lifecycle — new service worker waits for old tabs to close.

Code Examples

✗ Vulnerable
// Cache everything forever — stale content after deploy:
self.addEventListener('fetch', e => {
    e.respondWith(
        caches.match(e.request).then(r => r || fetch(e.request))
    );
    // HTML pages cached forever — users see old version after deploy!
});
✓ Fixed
// Workbox — strategy per resource type:
import { registerRoute } from 'workbox-routing';
import { CacheFirst, NetworkFirst, StaleWhileRevalidate } from 'workbox-strategies';

// Static assets: cache forever (content-hashed filenames):
registerRoute(({url}) => url.pathname.match(/\.(js|css|woff2)$/),
    new CacheFirst({ cacheName: 'assets-v1' }));

// HTML pages: network first, cache fallback:
registerRoute(({request}) => request.mode === 'navigate',
    new NetworkFirst({ cacheName: 'pages-v1', networkTimeoutSeconds: 3 }));

// API: stale while revalidate:
registerRoute(({url}) => url.pathname.startsWith('/api/'),
    new StaleWhileRevalidate({ cacheName: 'api-v1' }));

Added 16 Mar 2026
Edited 22 Mar 2026
Views 123
Rate this term
No ratings yet
🤖 AI Guestbook educational data only
| |
Last 30 days
0 pings T 2 pings F 0 pings S 1 ping S 0 pings M 1 ping T 0 pings W 0 pings T 0 pings F 2 pings S 0 pings S 0 pings M 2 pings T 1 ping W 0 pings T 0 pings F 1 ping S 2 pings S 0 pings M 0 pings T 0 pings W 0 pings T 2 pings F 2 pings S 2 pings S 0 pings M 0 pings T 0 pings W 0 pings T 0 pings F
No pings yet today
No pings yesterday
ChatGPT 16 Amazonbot 10 Google 10 Scrapy 7 PetalBot 7 Ahrefs 6 Perplexity 5 Bing 4 SEMrush 4 Unknown AI 3 Claude 3 Brave Search 2 Applebot 2 Meta AI 1 Twitter/X 1
crawler 77 crawler_json 3 pre-tracking 1
🧱 FUNDAMENTALS — new to this? Start with the ground floor.
Frontend frontend The frontend is the part of a website or application that users see and interact with directly in their browser—buttons, text, images, and forms.

Every user interaction starts at the frontend. Understanding this layer helps you build interfaces people actually want to use and debug issues that only appear in the browser.

💡 If you can see it or click it, it's frontend; if it stores data or makes decisions you shouldn't expose, that belongs on the backend.

Ask Codex about Frontend →
DEV INTEL Tools & Severity
🟡 Medium ⚙ Fix effort: High
⚡ Quick Fix
Use Workbox with a network-first strategy for HTML (always fresh) and cache-first for versioned assets (always fast) — don't cache API responses that include user data
📦 Applies To
javascript ES2015 web
🔗 Prerequisites
🔍 Detection Hints
Service worker caching all responses including authenticated API responses; no offline fallback page; stale HTML served after deployment
Auto-detectable: ✓ Yes lighthouse workbox chrome-devtools
⚠ Related Problems
🤖 AI Agent
Confidence: Medium False Positives: Medium ✗ Manual fix Fix: Medium Context: File Tests: Update


✓ schema.org compliant