Developer

Service Worker Generator

Produce vanilla service-worker.js code using the Cache API: precache URLs on install, pick a fetch strategy (network-first, cache-first, stale-while-revalidate, and more), optionally wire an offline fallback page, and copy a matching registration snippet. Generation stays in your browser — nothing is uploaded.

Ad placement — top banner

Bump this when you change precache or breaking cache logic.

Must match where you deploy the generated file.

Passed to cache.addAll on install — every URL must respond successfully or install can fail.

Used for navigate requests when network/cache miss handling allows (strategy-dependent). Precache this page if you rely on it offline.

Ad placement — mid rectangle

What is a service worker?

A service worker is a script that the browser runs separately from your page. It can intercept network requests, cache responses, and enable offline and faster repeat visits for progressive web apps (PWAs). This generator outputs plain JavaScript using the caches and fetch APIs — no bundler required.

Strategies in plain language

  • Network first — try the network; on failure, use the cache. Good when freshness matters but offline should still work.
  • Cache first — use a cached response if present; otherwise fetch and store. Good for static assets with hashed filenames.
  • Stale-while-revalidate — return a cached copy immediately if available, while updating the cache from the network in the background.
  • Network only — always hit the network (no runtime caching of successful responses). Precache on install still runs if you list URLs.
  • Cache only — only serve from the cache; useful for fully offline shells when combined with precache.

Precache and cache versioning

On install, the generated worker calls cache.addAll(PRECACHE_URLS). If any URL fails (404, CORS, etc.), the install event can fail — test in DevTools → Application → Service Workers. Change Cache name when you ship breaking updates so “delete old caches” can remove previous versions.

Workbox vs. this generator

Google’s Workbox library adds routing, plugins, and build integration for large apps. DroidXP’s output is intentionally small and readable for learning and quick prototypes — swap to Workbox when you need precaching pipelines, runtime caching rules, or background sync.

HTTPS and scope

Service workers require a secure context (HTTPS or localhost). The registration snippet uses scope: '/' — tighten or widen it in your project to match where the SW file is served from.

How to use this tool

  1. Step 1: Set cache name, strategy, and optional precache list.
  2. Step 2: Copy service-worker.js into your site (path must match Register path).
  3. Step 3: Paste the Registration snippet into your app shell (after load).
  4. Step 4: Test with DevTools and adjust offline URLs and strategies for your API.

Frequently Asked Questions

Does DroidXP run or host my service worker?

No. The tool only builds text in your browser. You host the file on your own origin and register it from your pages.

Why does addAll fail during install?

One bad URL fails the whole batch. Verify each precache path returns 200, watch CORS for cross-origin assets, and use DevTools to see which request failed.

Why don’t I see updates after deploying a new SW?

Browsers keep the old worker until tabs close or a new worker takes over. skipWaiting() and clients.claim() help, but you may still need to reload or implement a “refresh to update” UX.

Can I cache cross-origin images or APIs?

Responses must be CORS-enabled for cache.put to store useful copies; opaque responses are hard to reuse. Prefer same-origin assets or APIs with proper CORS headers.

What about POST requests?

The generated fetch handler ignores non-GET requests so forms and APIs are not accidentally cached — extend the script yourself if you need custom POST handling.

Is stale-while-revalidate always the best choice?

It trades a fast paint against possibly stale content. For APIs that must be fresh, prefer network first or skip runtime caching for those paths (add routing logic in your own code).

Do I need a web app manifest for this?

Service workers work without a manifest. A manifest is separate — it is required for “install to home screen” branding, not for basic SW registration.

Can I use this in production as-is?

Treat the output as a starting point. Add error handling, routing for APIs, size limits, and monitoring. For large PWAs, evaluate Workbox or a framework-specific PWA plugin.

Ad placement — sidebar 300×600