Push-уведомления и рассылки
Push-рассылка и уведомления в веб-приложениях
Push-рассылка (Push Notifications) — возможность отправлять уведомления пользователям даже тогда, когда они не находятся на сайте. Работает через Service Worker и Push API, интегрированный с облачными сервисами (Firebase Cloud Messaging, Mozilla Push Service). Пользователь должен дать разрешение, что обеспечивает контроль над уведомлениями.
Push-уведомления — это короткие сообщения, которые веб-приложение может показать пользователю даже тогда, когда вкладка с сайтом закрыта, браузер свёрнут или работает в фоне.
Они напоминают системные уведомления операционной системы — появляются в углу экрана, могут вибрировать на телефоне, воспроизводить звук, отображать иконку и заголовок. При нажатии — открывают конкретную страницу приложения.
Такой уровень взаимодействия стал возможен благодаря трём технологиям, появившимся в 2015–2017 годах и принятым всеми основными браузерами:
- Service Worker — фоновый скрипт вне контекста страницы;
- Push API — интерфейс для получения внешних событий;
- Notifications API — интерфейс для отображения уведомлений.
Эти три компонента работают вместе как команда — Push API получает сигнал извне, Service Worker обрабатывает его и решает, стоит ли показывать уведомление, а Notifications API превращает решение в визуальное сообщение.
Service Worker
Service Worker — это JavaScript-файл, который браузер загружает и исполняет в фоновом режиме. Он не привязан к конкретной вкладке и может жить дольше, чем сама страница.
Основные свойства Service Worker:
- Запускается один раз на домен (или на область действия — scope);
- Не имеет доступа к DOM и не может напрямую менять интерфейс;
- Может перехватывать сетевые запросы, кэшировать ресурсы, планировать фоновые операции;
- Имеет ограниченное время жизни — браузер "усыпляет" его при бездействии, но пробуждает по событиям (сетевой запрос, push-сообщение, таймер);
- Требует HTTPS (даже на
localhost— для безопасности).
Сайт регистрирует Service Worker через navigator.serviceWorker.register(). Жизненный цикл: install → activate → idle/waiting → running по событию.
💡 Пример жизненного цикла:
Пользователь впервые зашёл на сайт → Service Worker загрузился и выполнилinstall→ сохранил критические файлы в кэш → перешёл в состояниеactivated→ начал слушать события.
На следующем визите — браузер сразу использует кэшированную версию, даже если интернет отсутствует. Это основа работы Progressive Web Apps.
Push API
Push API — это механизм, позволяющий внешнему серверу отправить сигнал в браузер пользователя через облачный push-сервис.
Важно понимать: веб-приложение не может напрямую отправить сообщение в браузер пользователя, если тот не находится на сайте. Соединение разорвано. Чтобы преодолеть эту преграду, используется посредник — push-сервер, управляемый браузерным вендором или доверенной третьей стороной.
Стандартная схема:
- Пользователь заходит на сайт и разрешает получать уведомления.
- Браузер генерирует уникальный push-токен — адрес, по которому можно доставить сообщение именно этому устройству и профилю.
- Push-токен отправляется на сервер приложения и сохраняется в базе данных в привязке к пользователю.
- Когда сервер хочет отправить уведомление — он обращается к облачному push-сервису (например, Firebase Cloud Messaging или Mozilla Push Service) и передаёт туда push-токен и payload (содержимое).
- Push-сервис находит браузер по токену и доставляет сигнал.
- Браузер пробуждает Service Worker и передаёт ему событие
push. - Service Worker создаёт и показывает уведомление через
self.registration.showNotification().
Play ITЗагрузка интерактивного демо…
Эта схема называется web push protocol. Она не зависит от конкретного фреймворка или языка: любой сервер (Node.js, Python, Java, PHP) может отправлять push-сообщения, если умеет подписываться на push-сервис.
🔐 Безопасность:
Push-токен не содержит персональных данных, но он уникален и должен храниться конфиденциально. Если токен украден — злоумышленник может отправлять пользователю фишинговые уведомления от имени доверенного сайта. Поэтому:
— токен передаётся только по HTTPS;
— сервер валидирует, кому именно он отправляет сообщение;
— уведомления не содержат критически важных данных (например, код подтверждения из SMS лучше не слать в push — это нарушение принципа least privilege).
Notifications API
Notifications API — это интерфейс, через который Service Worker или веб-страница могут показать системное уведомление.
Вызов прост:
self.registration.showNotification('Новое сообщение', {
body: 'Вам ответили в чате',
icon: '/icons/chat-48.png',
badge: '/icons/badge-12.png', // маленькая иконка в списке уведомлений (Android)
tag: 'chat-reply', // группировка: повторные уведомления с тем же tag заменят старое
data: { chatId: 42 }, // произвольные данные — Service Worker передаст их при клике
requireInteraction: true // уведомление не исчезнет автоматически
});
Уведомление появляется в системной области уведомлений ОС. Пользователь может:
- кликнуть по нему — тогда сработает обработчик события
notificationclickв Service Worker, и можно открыть нужную страницу; - отклонить — сообщение исчезнет;
- настроить глобальные разрешения для сайта (разрешить/запретить/настроить тихий режим).
📱 Особенности на мобильных устройствах:
— На iOS push-уведомления работают, но Service Worker ограничен (не поддерживает фоновую синхронизацию, Push API требует Safari 16.4+, апрель 2023);
— На Android — полная поддержка, включая rich notifications (кнопки действий, изображения в уведомлении);
— Некоторые браузеры (например, Samsung Internet) используют свой push-сервис, но API остаётся единым.
От пользователя — к разрешению
Push-уведомления невозможны без явного согласия. Браузер не позволяет сайту отправлять их просто так — это нарушало бы приватность и могло превратиться в спам.
Типичный сценарий запроса разрешения:
- Пользователь проводит время на сайте, взаимодействует с контентом — это сигнал доверия.
- В подходящий момент (не при заходе!) сайт показывает собственную кнопку: "Получать уведомления о новых статьях?".
- При клике вызывается
Notification.requestPermission(). - Браузер выводит системный диалог: "site.ru хочет отправлять вам уведомления" с кнопками "Разрешить" / "Заблокировать".
- Если пользователь разрешил — сайт регистрирует Service Worker и подписывается на push-сервис.
🚫 Плохая практика:
— Запрашивать разрешение сразу при загрузке страницы;
— Скрывать кнопку "Отклонить" или делать её малозаметной;
— Использовать push для рекламы без ценности (скидки, акции без подписки на них).
Это ведёт к массовому отключению уведомлений и потере доверия.
✅ Хорошая практика:
— Объяснить, зачем нужны уведомления и какую пользу они принесут;
— Разрешить легко отписаться (например, ссылка "Настроить уведомления" в каждом сообщении);
— Отправлять только релевантные события (статус заказа, ответ в обсуждении, начало трансляции — не "Мы вас помним!" раз в неделю).
Базовый разбор HTTP и HTTPS находится в отдельной статье — HTTP как основа веб-интеграций.
Практика push-рассылок без "спама"
События, которые обычно полезны пользователю
- Изменение статуса заказа.
- Ответ на комментарий или сообщение.
- Напоминание о действии, которое пользователь сам инициировал.
Базовые правила качества
- Один тип уведомлений -> одна ценность и понятный заголовок.
- Легкая отписка прямо из интерфейса профиля.
- Ограничение частоты, чтобы не вызывать усталость.
- A/B-тест текстов по клику и удержанию.
Разбор ситуаций — push на практике
Ситуация 1. Пользователь случайно нажал "Блокировать"
Что видите: сайт больше не может запрашивать уведомления, хотя пользователь хотел бы получать статус заказа.
Почему так: браузер запоминает решение по домену. После блокировки повторный системный запрос не показывается автоматически.
Что делать (для пользователя):
- Откройте настройки сайта в браузере (значок замка/информации слева от адреса).
- Найдите раздел "Уведомления" и переключите на "Разрешить".
- На сайте снова нажмите кнопку подписки на уведомления.
Что делать (для разработчика):
- Не запрашивать разрешение при первом заходе.
- Показать собственный экран с объяснением ценности до системного диалога.
- Дать понятную инструкцию, как включить уведомления вручную, если доступ заблокирован.
Ситуация 2. Уведомление приходит, но клик открывает не ту страницу
Что видите: push показывается, но при клике открывается главная, а не заказ или чат.
Почему так: в data уведомления не передан нужный URL, или обработчик notificationclick в Service Worker открывает фиксированный маршрут.
Что делать:
- В payload уведомления передавайте
orderId,chatIdи целевой путь. - В Service Worker в
notificationclickчитайтеevent.notification.data. - Открывайте конкретный URL:
/orders/123или/chat/42. - Проверьте сценарий: вкладка сайта уже открыта / сайт закрыт / браузер свёрнут.
Пример логики:
self.addEventListener('notificationclick', (event) => {
event.notification.close();
const targetUrl = event.notification.data?.url || '/';
event.waitUntil(clients.openWindow(targetUrl));
});
Ситуация 3. Слишком много уведомлений, пользователи отписываются
Что видите: после подписки CTR высокий, но через неделю растёт отписка и жалобы.
Почему так: отправляются малозначимые события ("заходите снова", "новая акция") без персональной ценности.
Что делать:
- Оставьте только high-value события — статус заказа, ответ в чате, дедлайн.
- Введите лимит частоты (например, не больше 2 push в сутки на пользователя).
- Добавьте настройки уведомлений в профиле: "только важное", "тихий режим".
- Измеряйте не только доставку, но и отписки/блокировки.
Ситуация 4. На iPhone push работает нестабильно
Что видите: на Android всё стабильно, на iOS уведомления приходят с задержкой или не приходят.
Почему так: ограничения Safari/iOS по фоновой активности, энергосбережению и версии системы.
Что делать:
- Проверьте, что сайт открыт через Safari (не только встроенный WebView).
- Убедитесь, что iOS и Safari обновлены.
- Проверьте, что пользователь не отключил уведомления для Safari в настройках iOS.
- Для критичных сценариев дублируйте канал: email или in-app badge.
Подробнее про фоновые механизмы — в офлайн-режиме и Service Worker.
Ситуация 5. Push доставлен, но не показан из-за "тихого" режима ОС
Что видите: сервер получил успешную доставку, а пользователь уведомление не видит.
Почему так: включён режим "Не беспокоить", фокус-режим или сайт в списке тихих приложений.
Что делать:
- Проверьте системные настройки уведомлений для браузера.
- Для важных событий используйте
requireInteraction: trueв уведомлении. - Не отправляйте чувствительные данные в тексте push (только безопасные статусы).
- В интерфейсе показывайте дублирующий in-app индикатор (badge/колокольчик).