Cobra Developers
Blog, Web apps

Web push notifications explained: what they are and when to use them

The short answer

Web push notifications are messages a website sends to a user's device through the browser, even when the site is closed. They rely on a service worker, a push subscription the user grants, and VAPID keys that identify the sender. Use them for timely, expected messages, and cap how often you send so users do not turn them off.

Two of our products depend on reaching someone who is not looking at the screen. CoverageCobra sends text and push alerts when a court appearance needs covering, because a hearing posted late in the day has to reach an available attorney quickly. Regulars puts a message on a customer's lock screen when there is a reason to come back to the shop.

Both use Web Push, the browser standard for notifications. It is a useful channel and an easy one to ruin. This post covers how it works and how to keep the permission once a user grants it.

What are web push notifications?

Web push notifications are messages sent from a website to a user's phone or computer through the browser. They appear in the same place as app notifications, including the lock screen, and they arrive even when the site is not open. The user must grant permission first.

They are different from the alerts a page shows while you are looking at it. A push notification is delivered by the browser and the operating system, not by an open tab. That is what makes it useful for anything time sensitive.

No app store is involved. The site asks, the user agrees, and the browser remembers.

How do web push notifications work?

Web push works through three parts: a service worker that runs in the background, a push subscription the browser creates when the user grants permission, and a pair of VAPID keys that prove which server is sending. Your server sends a message to the browser maker's push service, which delivers it to the device.

  1. The site registers a service worker. This is a script the browser keeps available in the background, even with the site closed.
  2. The site asks for permission. The browser shows its own prompt. The site cannot style or skip it.
  3. The browser creates a subscription. It contains a unique endpoint URL at the browser maker's push service, plus encryption keys.
  4. The site sends the subscription to your server, which stores it against the user.
  5. Your server sends a message to that endpoint, encrypted for the device and signed with your VAPID private key.
  6. The push service delivers it, the browser wakes the service worker, and the service worker shows the notification.

VAPID keys are a public and private key pair you generate once. The public key goes in the page when subscribing. The private key stays on your server and signs each message, so the push service knows it came from you.

Subscribing in the page:

const registration = await navigator.serviceWorker.ready;
const subscription = await registration.pushManager.subscribe({
  userVisibleOnly: true,
  applicationServerKey: VAPID_PUBLIC_KEY,
});
await fetch('/api/push/subscribe', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(subscription),
});

And showing the message in the service worker:

self.addEventListener('push', (event) => {
  const data = event.data.json();
  event.waitUntil(
    self.registration.showNotification(data.title, { body: data.body })
  );
});

When should you use web push instead of email or SMS?

Use web push for short, timely messages that the user has asked to receive and that lose value within hours. Use email for anything long, anything that needs to be kept, and anyone who has not opted in to push. Use SMS when the message is urgent enough to justify a per-message fee.

Web pushEmailSMS
Opt-inBrowser permission promptEmail addressPhone number and consent
Reaches the lock screenYesDepends on the mail appYes
Message lengthA title and a line or twoAnyShort
Fee per messageNone from the push serviceLow, through an email providerCharged by the carrier or provider
Kept for laterNo, it is dismissedYesYes
Works if the user changes devicesNo, tied to one browserYesYes
Best forAlerts that matter nowReceipts, records, detailUrgent alerts and codes

Most products need more than one channel. CoverageCobra sends both text and push alerts, so one missed channel is not a missed job. Anything a user will need to find again, like a receipt, belongs in email. We compare the other two channels in SMS and email notifications in apps. Text messaging is regulated, so check the consent rules that apply to you before sending.

Why do frequency caps matter for push notifications?

Frequency caps matter because permission is easy to revoke and hard to win back. A user who feels pestered turns notifications off in two taps, and the site cannot ask again in the same way. A cap on how often you send keeps the channel open.

We built this into Regulars. Its campaign scheduler has a weekly frequency cap, so a shop owner cannot message the same customer more often than the limit allows, however many promotions are queued. For a shop that is locked out of most ad platforms, the lock screen may be the only direct line to a customer. Losing it to over-sending would be an expensive mistake.

The cap also forces a useful question for each message: is this worth one of the week's slots? Regulars pairs that with holdout groups, so an owner can see whether a promotion moved sales instead of guessing. An owner can stop sending the messages that do nothing. We write more about that situation in marketing when you cannot advertise.

When should you ask for notification permission?

Ask for notification permission after the user has done something that makes the benefit obvious, never on first page load. Explain in your own words what you will send and how often, then trigger the browser prompt only when the user agrees. A refused prompt is very hard to undo.

Rules worth following:

  • Ask in context. After an order is placed: "Want a notification when it is ready?" The reason is on the screen.
  • Ask yourself first. Show your own small message with a yes button. Only a yes opens the browser's prompt. A no costs you nothing and can be asked again later.
  • Say what and how often. "Up to one message a week" is a promise people can accept.
  • Give an off switch in your own settings, so users do not have to dig through browser menus.

On iPhone there is an extra step: web push only works after the user has added the site to the home screen. Plan the install prompt before the notification prompt. Our PWA vs native app comparison covers installation.

Frequently asked questions

Do users need to have the website open to receive a push?

No. The push service delivers the message to the browser, which wakes the service worker to display it. On phones the operating system handles delivery, so notifications arrive with the browser closed. On a desktop computer, the browser generally needs to be running.

Do web push notifications cost money to send?

The push services run by browser makers do not charge per message. Your costs are building the feature and running the server code that sends messages. That makes push much cheaper per message than SMS, though it reaches only users who opted in on that device.

Can a user turn web push notifications off?

Yes, at any time, from the browser's site settings or the device's notification settings. A good site also offers its own switch. Once a user blocks notifications at the browser level, the site cannot show the permission prompt again unless the user changes that setting.

What happens to subscriptions that stop working?

Subscriptions expire or are removed when a user clears data, uninstalls, or revokes permission. The push service then returns an error saying the subscription is gone. Your server should delete that subscription when it sees the error, so it stops sending to dead endpoints.

Can web push notifications include images and buttons?

Some browsers support icons, images, and action buttons, and others show only a title and text. Write every message so it works as plain text.

If your product needs to reach people at the right moment, tell us who you are trying to reach and we will suggest the channels that fit.

Who wrote this

The Cobra Developers team. We are a software studio in Arizona that builds and runs its own products and builds websites, web apps, and automation for clients. This post draws on our work on Regulars, CoverageCobra. Everything here comes from projects we shipped; see all 30 of them.

guest@cobra: ~