Spring GDS 25th Anniversary
A logistics company that ships to 190 countries built something to ship to itself.
A service worker is a script the browser runs in the background, separate from the web page, acting as a programmable proxy between the page and the network. Because it sits in that position, it can intercept network requests and decide how to answer them: from the network, from a cache it controls, or some mix of the two. It runs even when the page is closed, which is what makes background behaviour on the web possible at all.
This is the engine behind Progressive Web Apps. A service worker is what lets a web app keep working with no connection, by serving cached pages and assets when the network is gone. It powers push notifications, lets the app sync data in the background once a connection returns, and gives the developer fine control over caching strategies. A news PWA, for example, can use a service worker to cache the latest articles so a commuter can keep reading after the train dives into a tunnel.
It comes with strict rules. Service workers only run over HTTPS, for security reasons, and they have a defined lifecycle of install, activate, and fetch that you have to handle correctly or you ship stale content to users. Caching is powerful and easy to get wrong. Done well, the page feels instant and survives a dropped connection. Done carelessly, users get served old assets and wonder why nothing updates.
We build with service workers when a project actually needs what they offer: offline use, instant repeat loads, or push. A client whose field staff worked in places with patchy signal needed their tool to keep functioning regardless. We built a service worker that cached the app shell and the data those users relied on, so the experience held up when the connection did not, then synced cleanly once it came back.
Caching strategy is where service worker work is won or lost, so we treat the lifecycle and the cache rules as something to design, not bolt on. In our web development and progressive web app development work, that means deciding deliberately what to cache, when to refresh it, and how updates reach the user, so nobody ends up staring at a stale screen. Reliable offline behaviour, and no surprises when new content ships.
Need a web app that works when the connection doesn't? Let's build it to last offline.
A logistics company that ships to 190 countries built something to ship to itself.
Turning a brand into a working business.
Half a million people. One app. Zero chaos.















