Service Worker Cache
Cache assets in the browser on first visit so every return visit loads from memory in milliseconds.
Metrics
This technique can move up to 100% of LCP's share of the Lighthouse score, and can also make it worse when misapplied.
This technique does not move TBT.
This technique does not move CLS.
This technique can move up to 100% of FCP's share of the Lighthouse score.
This technique can move up to 100% of SI's share of the Lighthouse score.
This technique can move up to 67% of TTFB's share of the Lighthouse score.
Overview
A Service Worker is a JavaScript file that runs in a background thread and intercepts all network requests from your page. Using the Cache API, it stores responses on first visit and serves them instantly on subsequent visits — bypassing DNS, TCP, TLS, and server response time entirely. For return visitors, FCP drops from 1–3 seconds to under 100 ms. Combined with a stale-while-revalidate strategy, users always get instant loads while assets update silently in the background.
Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: TBT, CLS.
The Problem
Browser HTTP caching (Cache-Control) is powerful but limited — it requires the server to respond before the browser knows whether the cache is valid (revalidation round-trip). The Cache Storage API used by Service Workers bypasses the HTTP layer entirely, serving assets from a local store with no network involvement. On repeat visits, all cached assets are available before the DNS query completes.
Performance Impact
LCP
800–2500ms
repeat visits: LCP image served from cache with zero transfer time
FCP
800–2500ms
repeat visits: HTML, CSS, and JS served from local cache with no network
SI
600–2000ms
all viewport assets available instantly from local storage
TTFB
assets served from Cache API on repeat visits; network bypassed entirely, response time approaches zero for cached resources
LCP
+100–200ms
first-visit overhead while the service worker installs and caches assets
Risk: Medium
stale content risk if cache invalidation is not handled; first visit unaffected
How it works
01
Register the service worker
Include a small registration script on every page. The browser downloads and installs the service worker file in the background on first visit — no user impact. The worker activates on the next page load.
02
Cache assets on install
In the service worker’s
installevent, precache a list of critical assets — main CSS, core JS bundles, offline fallback HTML — usingcache.addAll(). These files are cached before the worker takes control.03
Intercept fetches and serve from cache
In the
fetchevent handler, implement a caching strategy. Cache-first for static assets (CSS, JS, fonts, images): check cache, serve from there, fall back to network. Network-first for HTML: fetch fresh content, cache the response, fall back to cached version if offline.04
Revalidate in the background with stale-while-revalidate
Serve the cached version immediately, then fetch a fresh copy from the network in the background. When the new response arrives, update the cache for the next visit. Users always get instant loads; content is never more than one visit stale.
Limitations
- Service workers only activate from the second page load — first-time visitors receive no benefit.
- Stale content risk: if the cache version is not incremented on deploy, users may see outdated CSS or JavaScript until the worker updates.
- Service workers require HTTPS (localhost is exempt for development).
- Debugging service worker caching issues requires clearing the Cache Storage in DevTools — standard browser cache clearing does not affect it.
Common Mistakes
Caching HTML responses with a long-lived cache-first strategy
HTML contains links to versioned assets. Caching HTML indefinitely means users receive old markup even after a deploy. Use network-first or stale-while-revalidate with short max-age for HTML; reserve cache-first for fingerprinted static assets.
Not versioning the cache name on deployment
When you deploy new JS or CSS, the old service worker serves the old cached files until it detects an update. Increment the CACHE constant on every deploy and clear old caches in the activate event to ensure users get fresh assets.
Need help applying this to your site?
Targeted fixes, not guesswork. We identify which techniques move the needle for your specific WordPress stack.
Start an Engagement