Web push уведомления — сообщения, которые сайт или PWA отправляет на устройство пользователя; приходят они даже при закрытой вкладке. Механика такая: сервис-воркер держит подписку и показывает уведомление, сервер отправки по этой подписке шлёт запрос. На Android механизм поддерживается давно и почти во всех популярных браузерах, на iPhone — только для PWA, добавленного на экран «Домой». Ниже — из чего состоит цепочка, что такое VAPID, чем веб-пуши отличаются от пушей мобильного приложения и на чём чаще всего спотыкаются при внедрении; общая механика канала собрана в разделе про пуши.
Что такое web push уведомления и чем они не являются
Push-уведомления от сайта и от PWA
Web push — канал доставки коротких сообщений от владельца сайта на устройство подписчика в обход почты, мессенджеров и SMS. Инициатор отправки — сам сайт: он хранит подписку конкретного браузера и в нужный момент запускает показ. Пользователь видит сообщение в системной шторке или центре уведомлений, с иконкой и именем домена, и по клику попадает на нужную страницу.
Отличие от email и SMS — адрес доставки. Почта или номер телефона не нужны: идентификатором получателя становится подписка, которую браузер создал на конкретном устройстве. Доставка идёт через инфраструктуру браузера и операционной системы, а не через почтовый сервер или оператора связи. Поэтому письмо можно потерять в спаме, а пуш приходит сразу на экран — если пользователь не отключил уведомления для сайта.
Для продукта это самый короткий путь к возврату пользователя: не нужна ни открытая вкладка, ни приложение из магазина. Именно поэтому веб-пуши популярны у проектов, которые живут в вебе и не хотят зависеть от сторов.
Чем web push отличается от пушей нативного приложения
Задача у обоих каналов одна — дотянуться до пользователя вне сессии, — но устроены они принципиально по-разному.
В нативном случае приложение скачивают из App Store или Google Play, при первом запуске оно регистрируется в push-сервисе платформы, получает токен устройства и передаёт его на сервер. Обновления проходят через стор, а установка — отдельное действие пользователя с высоким порогом: скачать, дождаться, разрешить.
В вебе скачивать нечего. Пользователь заходит на сайт, нажимает «Разрешить» — и браузер сам создаёт подписку. Магазина приложений и модерации стора в цепочке нет, обновлять нечего: сервис-воркер и логика отправки живут на стороне сайта. «Установки» как таковой тоже нет — у PWA она означает лишь добавление ярлыка на домашний экран, а подписка всё равно привязана к браузеру и устройству.
Отсюда практические следствия. Пользователь очистил данные браузера или удалил PWA с домашнего экрана на iPhone — подписка исчезла, сервер получит ошибку при отправке и должен убрать такой адрес из базы. Дублировать подписки по устройствам тоже нужно аккуратно: телефон и ноутбук одного человека — это две подписки, а не одна. Насколько такой формат вообще нужен без сторов, разобрано в материале нужен ли стор для PWA.
Граница темы: пуш-сети как источник трафика — это другое
Пуш-сети, где закупают показы у чужих приложений, — способ купить трафик, а не механизм доставки уведомлений от собственного сайта; здесь речь только о втором.
Как работают веб-пуши: цепочка от разрешения до уведомления
Почти каждая жалоба «пуши не приходят» — это обрыв на конкретном звене, и звено надо уметь назвать. Всего их четыре: разрешение, подписка, отправка с сервера, показ через сервис-воркер.
Шаг 1: запрос разрешения
Пока пользователь явно не разрешит, браузер не даст сайту показывать уведомления. Разрешение запрашивается средствами браузера, показывается от имени домена и имеет три состояния: по умолчанию (не спрашивали), разрешено и заблокировано. Пока состояние «по умолчанию», сайт может спросить; после отказа повторный запрос через тот же интерфейс уже невозможен — пользователь должен сам зайти в настройки сайта в браузере и вернуть разрешение.
Важный нюанс: разрешение — это ещё не подписка. Разрешение говорит «этому домену можно показывать уведомления», подписка — конкретный адрес доставки, созданный для этого браузера. Одно без другого не работает: без разрешения браузер не выдаст подписку, без подписки серверу некуда отправлять.
Браузеры относятся к таким запросам настороженно, потому что сайты долго злоупотребляли ими при загрузке страницы. Поэтому запрос стоит показывать не сразу, а по действию пользователя — после клика по собственному баннеру с объяснением, зачем нужны уведомления и что будет приходить.
Шаг 2: подписка и endpoint
После разрешения сайт через API браузера создаёт подписку: браузер обращается к своему push-сервису, получает уникальный адрес доставки — endpoint — и пару ключей шифрования, которые нужны, чтобы только браузер этого пользователя мог прочитать содержимое сообщения. Весь объект сохраняется на сервере проекта и привязывается к конкретному устройству или анонимному профилю.
Endpoint — это адрес получателя, длинная ссылка на push-сервис. Он уникален для пары «браузер + устройство + сайт» и может перестать существовать: пользователь удалил данные, отозвал разрешение, переустановил браузер, удалил PWA с домашнего экрана. На отправку по такому адресу push-сервис вернёт ошибку, и это нормальная рабочая ситуация, а не сбой. Задача серверной части — распознавать такие ответы и удалять мёртвые подписки, иначе база распухает и рассылка начинает упираться в лимиты.
Шаг 3: VAPID и зачем нужны ключи
VAPID — это способ доказать push-сервису, что запрос на отправку пришёл от владельца сайта, а не от постороннего. Работает он на паре ключей: публичный встраивается в клиентский код и участвует в создании подписки, приватный лежит только на сервере и подписывает каждый запрос на отправку.
Зачем это нужно: push-сервису браузера всё равно, кто именно шлёт сообщение, — ему нужен проверяемый признак отправителя, чтобы связать подписку с конкретным доменом. VAPID даёт такую связку без предварительной регистрации у каждого провайдера и без сложных интеграций. Практическое правило простое: приватный ключ не попадает в клиентский код, в репозиторий и в аналитику, а публичный может лежать открыто — он для этого и предназначен. Если ключи перегенерировать, старые подписки, привязанные к прежнему публичному ключу, перестанут работать.
Шаг 4: сервер отправляет, сервис-воркер показывает
Сервер берёт сохранённую подписку, шифрует текст сообщения и делает запрос на endpoint. Дальше в дело вступает push-сервис браузера: он будит сервис-воркер на устройстве, тот получает событие и вызывает показ уведомления — заголовок, текст, иконку, ссылку перехода.
Два важных свойства этой схемы. Содержимое сообщения push-сервис не читает: оно зашифровано ключами подписки. Показ уведомления — обязанность сайта: обработчик события должен явно отрисовать сообщение, иначе браузер может показать своё служебное уведомление вида «сайт обновился в фоне», что выглядит бесполезно и раздражает. Именно поэтому корректный сервис-воркер — не формальность, а обязательное звено.
| Этап | Что происходит | Где живёт |
|---|---|---|
| Разрешение | Пользователь разрешает показ уведомлений домену | Настройки браузера |
| Подписка | Браузер создаёт endpoint и ключи шифрования | Браузер + база сайта |
| VAPID | Сервер подписывает запрос приватным ключом | Приватный — на сервере, публичный — в коде |
| Отправка | Запрос на endpoint с зашифрованным текстом | Инфраструктура push-сервиса |
| Показ | Сервис-воркер рисует уведомление, клик ведёт на URL | Устройство пользователя |
Web Push API глазами практика: шаги без кода
Web Push API — это набор браузерных интерфейсов и серверного протокола, который связывает четыре вещи: разрешение, подписку, отправку и показ. Порядок внедрения почти всегда одинаковый.
Сначала HTTPS. Без защищённого соединения сервис-воркер не зарегистрируется, а значит, и показывать уведомления будет некому. Это условие нулевого шага, а не деталь.
Затем регистрация сервис-воркера. Отдельный файл, который браузер держит в фоне и который переживает закрытие вкладки. У него есть область действия — набор страниц сайта, которыми он управляет; если файл лежит в подкаталоге, часть страниц может остаться вне зоны.
Дальше — свой интерфейс запроса разрешения. Вместо системного окна при загрузке страницы — собственный баннер с объяснением пользы и кнопкой.
Вопрос–ответ
Нужно ли приложение, чтобы получать веб-пуши? Нет. Достаточно браузера: подписку создаёт он сам, магазин приложений в цепочке не участвует. Исключение — iPhone, где механизм работает только для PWA, добавленного на экран «Домой».
**Почему пуши не приходят после того, как пользователь нажал «Заблок
Проверено: 26.10.2026. Правила сторов и возможности платформ описаны на дату проверки; точные формулировки смотрите в официальной справке Apple, Google и MDN. Нашли неточность — напишите на redakciya@pwa-arbitrazh.com.