How Push Notifications Work

The process of sending push notifications can be divided into the following procedural steps.

Requesting user permission

We must obtain the user’s consent before sending push notifications. Without the user’s permission, we cannot display notifications. The Notifications API allows us to request permission from the user via a prompt. This is a one-time task.

The user can decline permission from the browser settings even if they had previously accepted it. If the user enables notifications, we can then begin displaying notifications.

Although the browser may automatically prompt the user for notification permission, it’s preferable to request it manually. This allows us to handle the user’s response and gives us control over when to display the consent prompt (such as in response to a button click). Requesting permission this way can increase the likelihood that the user will consent.

Generating and storing subscriptions

Subscriptions contain information like an endpoint URL and the user’s public key. These are required for the browser and the web app to establish a push notification channel. This allows the app server to send messages to the user’s browser. Each browser vendor has its own push server, which refers to the browser-device combination (a browser on a given device).

The subscription object is created once the user grants permission for notifications. This subscription object is then sent to the app server and stored. It’s important to correctly store a user’s subscription information to target the push messages to the right endpoint.

Note: Unregistering a service worker will revoke all existing push notification subscriptions associated with that service worker.

Sending push messages

After storing the subscription object, the app server can then send push messages. To send a push message to any user, the app server must use the endpoint URL and public key from the user’s subscription. This ensures the message is delivered to the correct browser.

Push messages are sent via the HTTP/2 POST requests to the endpoint URL. The request includes a payload with the following:

• A JSON blob containing the notification data like the title, body, and icon.
• An optional data object that contains additional data for the web app.

The above illustration shows the flow of the push messages sent from the app server, received by the app’s service worker, and a notification shown by the service worker to the user.

Receiving push messages

The service worker in the browser receives the push message. We can set a TTL (time-to-live) on the push messages to specify how long the browser should try to deliver the notification.

The Push API allows us to target specific users or send to all subscribers. We can also send push messages to a specific notification channel.

Displaying notifications

After receiving push messages, the service worker displays the actual notification to the user. Sending push messages is best-effort. Browsers attempt to deliver messages as soon as possible, but there are no hard guarantees. Factors influencing delivery speed include the user’s network connectivity and how often their browser polls for messages.

Most browsers show a banner at the top of the screen with the notification message and an option to dismiss or expand the notification. The browser passes any user actions back to your app.