Push Notifications & Service Workers: Two Technologies You've Been Confusing for One 🔔

March 5, 20264 min read
service workerPWAofflinecachingweb workersprogressive web appsbackground sync

Two Technologies, Not One

"Push notifications" is commonly treated as a single thing — but Kyle makes an important distinction: it's actually two separate technologies bundled under one permission prompt. Understanding which is which changes how you think about both.

  1. Notifications — the service worker pops a visible message on the user's screen
  2. Push — the server wakes up the service worker to tell it something, even when the tab is closed

They share the same permission request, which is part of why they get conflated. But they're genuinely different capabilities.

The Notification Part 📢

A service worker can send a notification to the operating system — a visible pop-up on the user's screen — even if the page isn't open. Any kind of alert you've seen on your devices: new email, calendar event, tweet, blog post — all of that is possible from a service worker.

Additional capabilities:

  1. If the site isn't open, clicking the notification can launch it in a new tab
  2. If the site is already open, it can navigate to a specific part of the app

"You can only do this if the user has granted permission prior to that point. You can't do it in a spammy way."

The Abuse Problem 😤

Here's the uncomfortable reality. Every time you land on a website you've never visited before and within seconds get a pop-up asking "Allow notifications?" — that's the same API being misused.

The result: most users now blanket-block all notifications. Browsers even have a setting to auto-deny them. And that poisons the well for the legitimate use cases where notifications would actually be welcome.

The right approach: let users engage first, log in, find value — then offer an optional, clearly explained permission request. Not 13 milliseconds after they arrive.

Some people have even talked about removing the API from the web platform entirely. Kyle hopes that doesn't happen — but it's a real conversation because of how badly it's being abused.

The Push Part — The Really Exciting Bit ⚡

Push is what Kyle finds genuinely mind-blowing. Here's what it enables:

Your server can send a message directly to a user's browser — even if the tab has been closed for days or weeks — and wake up the service worker to do something.

How? When the user grants permission, an encrypted key exchange happens between the browser and your server. From that point on, your server knows how to reach that specific browser anywhere in the world, on any Wi-Fi network, without the browser initiating the connection.

That's the server making an outbound request that finds the browser and says: "Hey service worker, wake up — I've got something for you."

Push Without Visible Notifications 🤫

Here's the use case that really clicked for me. Push doesn't have to show the user anything at all. Consider this flow:

  1. You publish a new blog post
  2. Your server pushes a message to all subscribed service workers
  3. Each service worker silently downloads the new content and adds it to the cache
  4. The next time the user opens your site — instant load, content already there

No notification shown. No interruption. Just a seamlessly primed cache, delivered in the background.

A student in the class made the connection to app updates:

"You could pre-push a new version of the app and have it already installed by the time the user opens it."

Kyle: "Exactly — it's already installed by the time they get there. That's really cool."

Why Service Workers Are the Entry Point 🚪

Web sockets have existed for over a decade — if the tab is open, you've always been able to do real-time communication. The difference service workers bring is doing all of this even when the tab is closed.

"Service workers live independent of an open tab. That's what unlocks all of these auxiliary technologies — push, background sync, notifications, cache priming — things that were simply not possible before."

Section Recap 🎯

  1. What a service worker is — a programmable browser proxy that intercepts every outbound request
  2. The fetch handler — once you add one, you own all the traffic routing
  3. CORS in the service worker context — cross-origin requests need special handling
  4. The Cache API — programmatic, developer-controlled caching paired with the fetch handler
  5. Six creative use cases — offline, background sync, URL rewriting, synthetic responses, prefetching, dependency injection
  6. Push vs. Notifications — two separate technologies, one permission; notifications show UI, push wakes the worker silently
  7. Silent cache priming — using push to pre-load content before the user even opens the tab
Back to Service Workers