What we see in ecommerce performance audits is a tempting promise: install a service worker, cache the storefront, and make repeat visits feel instant. The same feature can also preserve an old promotion, show stale availability, delay a release, or intercept every request with extra startup cost.
Service workers are powerful because they sit between the storefront and the network. That power needs a commerce-specific policy. Static assets, product data, account state, cart mutations, and checkout requests do not have the same freshness or failure tolerance.
Table of Contents
- Keyword decision
- What a service worker changes
- Build the scorecard
- Match strategy to resource
- Protect commerce freshness
- Release and recovery controls
- Measure real performance
- Composite operator scenario
- A 30-day plan
- Common questions
- EcomToolkit point of view
Keyword decision
- Primary keyword: ecommerce service worker performance
- Secondary keywords: ecommerce cache strategy, offline ecommerce, service worker precaching, repeat visit performance
- Search intent: technical evaluation and implementation planning
- Funnel stage: middle of funnel
- Why this page can win: general PWA guides rarely separate safe static caching from volatile price, inventory, cart, account, and checkout behavior.
Use it with our cache-hit and origin-load framework and release regression controls.
What a service worker changes
MDN’s Service Worker API guide describes service workers as proxy-like scripts between an application, the browser, and the network. They can intercept requests, return custom responses, manage cached resources, and support offline experiences.
The service-worker cache is not the HTTP cache. web.dev’s caching-layer guide explains that a request can pass through a service-worker strategy before the browser’s HTTP cache and the network. That means an application can override normal server-controlled caching behavior—helpful when intentional, risky when ownership is unclear.
A service worker can improve repeat navigation and resilience, but it can also add startup delay when it must wake before a network request. MDN notes that static routing can avoid unnecessary startup cost when the destination is known in advance. The correct question is not “Do service workers make ecommerce fast?” It is “Which requests benefit after freshness, startup, storage, and recovery costs?”
Build the scorecard
Measure experience and correctness together.
| Metric | Definition | Diagnostic use | Guardrail |
|---|---|---|---|
| Controlled-session share | sessions under the active service worker ÷ eligible sessions | sizes exposure | segment first visit vs repeat |
| Cache response rate | service-worker cache responses ÷ intercepted eligible requests | validates strategy use | exclude volatile requests |
| Service-worker startup delay | fetch start to handler execution | catches cold-start overhead | p75/p95 by device |
| Cache freshness error rate | stale commercial responses ÷ cached commercial responses | protects price/stock truth | zero tolerance for checkout mutations |
| Repeat navigation improvement | controlled repeat timing vs comparable network timing | estimates benefit | match device, network, template |
| Update adoption lag | new release to active worker version | finds long-lived old clients | monitor tail, not average |
| Recovery time | incident declaration to safe bypass or corrected cache | tests reversibility | drill before peak trading |
Do not publish a cache-hit rate without the eligible-resource definition. A high rate achieved by caching volatile product JSON is not a success.
Match strategy to resource
MDN’s PWA caching guidance emphasizes that strategy depends on the resource and that freshness is the central tradeoff. Map every request class before writing a global fetch handler.
| Resource | Typical strategy | Reason | Required control |
|---|---|---|---|
| hashed CSS/JS/fonts | cache first or precache | immutable versioned assets | purge obsolete versions |
| product images | cache first with limits | high reuse, content-addressable variants | quota and version policy |
| navigational HTML | network first or carefully bounded stale-while-revalidate | merchandising changes | timeout, offline fallback, version check |
| product price/availability | network first with minimal safe fallback | commercial volatility | visible freshness state |
| search results | network first | intent and inventory change | graceful connection failure |
| account/cart data | network only in most designs | identity and mutation risk | never leak across users |
| cart/checkout POST | network only | non-idempotent business action | explicit retry and error UX |
web.dev’s precaching guidance uses an ecommerce example where product-page CSS and JavaScript are precached from a listing experience. It also warns that precaching consumes bandwidth, storage, and CPU, and recommends caching only resources likely to be used.
Precache the shell, not the entire catalog. A large manifest can compete with critical first-visit resources and waste mobile data on products the shopper never opens.
Protect commerce freshness
Define a freshness budget per data class. “Stale” has different consequences:
- an old icon is usually harmless;
- an old category title is confusing;
- an old promotional price may create a customer-service and compliance problem;
- an old inventory state can cause overselling;
- an old cart or account response can expose or corrupt customer data.
Use versioned URLs for static assets and explicit cache names by release. For runtime data, store the response timestamp and source version. If a fallback must be shown, label it as offline or potentially outdated and disable actions that cannot be completed reliably.
Never cache personalized HTML or API responses under a key that ignores authentication, market, currency, language, price list, customer group, or experiment state. Audit Vary behavior and application-level cache keys together. Logging out must remove customer-specific cached data where any exists.
Release and recovery controls
Service-worker updates have a lifecycle. A newly installed worker can wait while an older worker still controls open tabs. Aggressively calling skipWaiting() and clientsClaim() can shorten adoption lag, but it can also put a running page under a worker built for a different asset graph.
Create an update contract:
- Give every worker and cache a build identifier.
- Keep compatible assets until old clients have moved forward.
- Notify users when a refresh is required for a breaking release.
- Delete only caches proven obsolete.
- Expose a kill switch or network-bypass path.
- Monitor worker version in every performance and error event.
Chrome’s service-worker deployment guidance warns that precaching can compete for network resources and that service-worker startup can add navigation delay. It recommends considering registration timing and navigation preload. Test the install/update path on constrained mobile devices, not only on a developer laptop with an already warm cache.
Your incident playbook should cover a poisoned cache, syntax error, redirect loop, offline fallback loop, API response cached under the wrong identity, and a worker that cannot activate. Practice shipping a no-op or bypass worker and verify that existing clients actually recover.
Measure real performance
Separate first uncontrolled visit, installing visit, controlled cold start, controlled warm cache, and offline fallback. Mixing them can produce a flattering average that describes nobody.
| Segment | Main question | Evidence |
|---|---|---|
| first visit | did registration compete with critical work? | LCP/INP, bytes, registration time |
| controlled cold start | did worker startup delay navigation? | startup duration and TTFB |
| controlled warm cache | did reuse improve repeat experience? | cache response timing |
| new release | how quickly and safely did clients update? | version adoption curve |
| flaky network | did fallback preserve honest, usable state? | failure recovery and stale-state errors |
Report Core Web Vitals by worker version and control state. Add business guardrails: add-to-cart failures, price mismatch, inventory rejection, checkout errors, and support contacts mentioning old content. Synthetic tests should clear storage, install the worker, repeat navigations, update versions, switch offline, and restore connectivity.
Composite operator scenario
A mobile retailer launches a PWA and precaches HTML plus catalog JSON. Repeat category visits become faster, but customers occasionally see expired promotions and available sizes that fail in cart. During releases, some users retain old JavaScript that expects a previous API response shape.
The team narrows precaching to hashed shell assets and likely next-template resources. Product price and availability move to network-first requests with a short timeout and clearly labeled fallback. Cart and account traffic bypass runtime caching. Build IDs flow into telemetry, old/new asset compatibility is preserved, and a bypass worker is tested.
The outcome is not one synthetic speed score. The team tracks warm repeat timing, startup overhead, stale-state errors, update lag, cart rejection, and recovery time.
A 30-day plan
| Week | Work | Output |
|---|---|---|
| 1 | inventory intercepted requests, cache keys, lifetimes, and owners | request-class map |
| 2 | instrument worker version, strategy, source, age, and timing | baseline scorecard |
| 3 | narrow policies, add identity/freshness tests, build kill switch | controlled release candidate |
| 4 | run update, offline, quota, and poisoned-cache drills | recovery evidence |
Roll out to a small cohort. Compare repeat benefits against first-visit cost and commerce errors. Pause if the storefront becomes faster but less truthful.
Common questions
Does every ecommerce site need a service worker?
No. Strong HTTP caching, CDN delivery, and conventional navigation may be sufficient. Add a service worker only for a defined repeat-performance, resilience, or offline job with clear ownership.
Can checkout work offline?
The interface can explain lost connectivity, but payment and order creation generally require current server confirmation. Never imply an order succeeded until the backend confirms it.
What should be precached?
Small, versioned, high-probability assets that materially improve the next experience. Avoid catalog-scale manifests and volatile commerce data.
EcomToolkit point of view
Service workers can turn repeat visits into an advantage, but they also move cache policy into application code. The winning design is conservative: cache immutable assets confidently, treat commercial truth as volatile, measure startup and update behavior, and keep a tested escape route.
Need a cache and repeat-visit performance review? Claim a free ecommerce performance audit.
