Service worker is one of those phrases that gets used in a meeting and makes everybody nod. I have done it myself. It sounds like infrastructure, or a background process, or something you would need a server for. It is none of those.
A client in Hull asked me last month what she was actually paying for when I said her site would work offline. Fair question, and the answer took about two minutes once I stopped using the words developers use. So here is that explanation, written down.
The one sentence version
A service worker is a small file of JavaScript that sits between your website and the internet, and gets to decide what happens to every request the site makes.
That is it. Your browser downloads it once, keeps it, and from then on it runs quietly in the background whenever somebody visits your site. When the page asks for an image, or a stylesheet, or the text of an article, the request goes to the service worker first. The service worker can pass it on to the internet as normal, or it can answer from a copy it saved earlier, or it can do something in between.
Why that one thing matters so much
Because almost everything people like about a well built modern site comes from that single ability to intercept a request.
Offline pages, because the service worker can answer from its saved copy when there is no signal
Instant repeat visits, because the logo and the fonts and the layout never have to be downloaded twice
An app that opens from the home screen and does not show a browser address bar
Push notifications, because the service worker is still running when nobody has the site open
None of those are separate features you buy. They are all consequences of the same small file being allowed to answer requests.
What it is not
It is not on your server. It runs in the visitor's browser, on their phone or their laptop, which is why it keeps working when their train goes into a tunnel.
It is not a worker in the sense of a member of staff, and it is not doing anything while nobody is on your site apart from handling push messages. It is also not automatic. Somebody has to write it and decide what it caches, and that decision is where all the actual craft is.
And it is not a plugin you tick on. You can get one from a plugin, and for a simple site that is often fine, but the default settings almost never match what your site actually needs.
The bit that goes wrong
The interesting question is never can we cache this. It is how long should the cached copy live, and that answer is different for different parts of a site.
Your logo can be cached for a year. It is not going to change, and if it does you can change its filename. Your stylesheet is similar. But your opening hours, your prices, your latest blog post: cache those too aggressively and you get the classic complaint, which is that the client updated the site, looked at it on their phone, and saw the old version. They then ring you convinced the update did not save.
That is a service worker doing exactly what it was told and being told the wrong thing. I have caused it. Most developers who work with these have caused it at least once. The fix is deciding upfront which parts of your site are allowed to be slightly stale and which have to be fresh every time.
Images, fonts, icons, CSS: cache hard, they change rarely and you can rename them
Article and page content: serve the saved copy immediately, then quietly fetch a fresh one for next time
Prices, stock, anything a customer acts on: go to the network first, every time
Do you need one
Honestly, not every site does. A five page site for a business that gets found on Google, read once, and phoned: a service worker adds complexity for very little gain. I would rather spend that budget on the site being fast in the first place.
Where it earns its keep is anywhere people come back, anywhere the connection is bad, and anywhere somebody is using the site while doing something else. Field work, warehouses, sports clubs on a pitch with one bar of signal. I have written more about why offline is not really optional any more for those situations.
If you are trying to work out which side of that line you are on, the app or PWA question covers the same ground from the business end rather than the technical end.
How I explain the cost
Adding a service worker to a site is not a big job on its own. Half a day gets you a sensible caching setup on a normal site. What takes the time is the thinking: going through the site section by section and deciding what can be stale.
The other thing worth budgeting for is testing it properly, on a real phone, with the network turned off, and then again after you publish an update. A service worker that caches your site perfectly and then never lets go of an old version is worse than not having one.
The short version
A service worker is a small script that sits in the visitor's browser and decides what happens to every request your site makes. Everything else people talk about, offline, installability, speed on repeat visits, notifications, comes out of that one ability.
It is worth having when people come back to your site or use it somewhere with a poor connection, and it is worth skipping when they do not. If you are not sure which one you are, book a free thirty minute surgery and we will look at your site together. No pitch, and if the answer is that you do not need one I will say so.
If speed is the real thing you are after rather than offline, the numbers that actually matter is probably a better place to start.
Free 30-min surgery
Working on something similar?