A service worker is a JavaScript script that the browser runs in the background, independently of the open page. It can intercept network requests, cache content and provide features such as offline operation, background synchronisation or push notifications.
A service worker is like a personal assistant between your website and the internet: it remembers content that has already been loaded, serves it instantly when needed and can even keep working when the connection drops. As a result, visitors experience noticeably faster subsequent pages.
Why do I need a service worker?
A service worker sits between the web page and the network as a programmable layer. It can intercept every request and decide whether the response comes from the local cache, from the network or from a combination of both. This makes repeat visits significantly faster, allows selected content to be available offline and enables features such as push notifications or background synchronisation.
Service workers are also the technical foundation of progressive web apps (PWA): websites that behave like installed apps – including a home screen icon and offline capability. Our article on progressive web apps in e-commerce describes what PWAs can do for online retail.
Practical relevance for shop and website owners
In a shop context, a service worker can keep static resources such as logos, fonts, CSS and JavaScript available locally so that subsequent pages load noticeably faster. This improves perceived speed and can support good Core Web Vitals. Sensitive areas such as the shopping cart, checkout and prices, however, do not belong in a long-lived cache – this data must always be up to date. Important to know: a service worker only works over HTTPS and requires a well-thought-out caching concept including versioning.
Technically, the service worker is registered once by the website and then applies to a defined area (scope), usually the entire domain. It runs in its own process, has no direct access to the page content and communicates with the page via messages. A crash of the service worker therefore does not block rendering – but faulty caching rules can lead to visitors seeing outdated content without noticing.
Common mistakes
- Caching too aggressively: Permanently caching HTML pages means serving outdated content after updates – a real risk in a shop when it comes to prices and stock levels.
- No update concept: Without versioned caches, old files remain on users' devices indefinitely.
- Missing fallbacks: If the network fails and there is no offline page, users see cryptic error messages.
- Set up once, never tested: Service worker bugs often only show up for returning visitors and remain invisible in standard tests.
What to look for
Define an appropriate caching strategy for each resource type – for example cache-first for fonts and logos, network-first for HTML and product data. Version your caches and clean up old entries with every update. New service worker versions should be checked on a staging environment before going live, because faulty caching logic can linger stubbornly for returning visitors. Implementation requires JavaScript experience and careful testing – we support you as part of our custom development and page speed optimisation services.
A CDN caches content server-side close to the user, while a service worker caches directly in the user's browser. The two layers complement each other and are ideally coordinated.