独立站PWA：离线访问、安装提示、推送通知与转化率

Границы возможностей трёх функций PWA и когда их стоит применять

独立站PWA：离线访问、安装提示、推送通知与转化率

Сначала вывод: Вклад PWA (прогрессивных веб-приложений) в конверсию B2B-сайтов сильно переоценён. По данным отрасли, установка PWA на B2B-сайтах обычно составляет 2–5%, а доля отказов от push-уведомлений превышает 80%. Реально ценно только офлайн-кэширование — оно улучшает LCP у пользователей в зонах слабого интернета на 30–50%. Контринтуитивный факт: если пользователь заходит на B2B-сайт в среднем всего 1,5 раза, push-уведомления почти не дают результата, потому что база для повторных визитов слишком мала. Критерий: если месячная доля повторных визитов с мобильных ниже 20%, вкладываться в разработку PWA не стоит.

1. Три функции PWA: что действительно работает, а что — показуха

PWA состоит из трёх ключевых возможностей: Service Worker для офлайн-кэширования, Web App Manifest для установки на рабочий стол и Web Push API для push-уведомлений. Звучит заманчиво, но на B2B-сайтах отдача распределяется крайне неравномерно.

Офлайн-кэширование (Service Worker) — самое ценное из трёх. Оно сохраняет HTML, CSS и JS сайта на устройстве пользователя, и при следующем открытии страница загружается мгновенно даже без сети или при слабом сигнале. Для рынков с нестабильным интернетом — Ближнего Востока, Юго-Восточной Азии, Латинской Америки — LCP может упасть с 4 секунд до менее чем 2. Как измерить производительность, см.Оптимизация Core Web Vitals.

Ценность предложения установки на рабочий стол (beforeinstallprompt API) зависит от сайта. Пользователи B2C-магазинов могут захотеть установить сайт как приложение, а посетители B2B-промышленного сайта запрашивают цену и уходят — установка обычно составляет 2–5%. Поддержка PWA в iOS Safari особенно ограничена: предложение установки вообще не появляется автоматически, нужно вручную предлагать пользователю «Добавить на экран «Домой»».

Push-уведомления переоценены больше всего. При первом визите всплывает окно «Разрешить уведомления?», и более 80% пользователей нажимают «Отклонить». Даже при согласии открываемость push обычно ниже 5%. В B2B клиенты предпочитают получать письма, а не браузерные уведомления, поэтому прямой вклад этой функции в конверсию заявок близок к нулю.

Возможность PWA	Техническая реализация	Реальный вклад в B2B-конверсию	Объём работ	Рекомендуемый приоритет
Офлайн-кэширование	Предварительное кэширование Service Worker	LCP в зонах слабого интернета улучшается на 30–50%	2–3 дня	Высокий
Установка на рабочий стол	Manifest + beforeinstallprompt	Установка 2–5%, рост повторных визитов ограничен	1 день	Средний
Push-уведомления	Web Push + серверная отправка	Доля согласий<20%，打开率<5%	3–5 дней	Низкая
Фоновая синхронизация	Background Sync API	Отправка форм при слабом интернете не теряется	2 дня	Средний
Иконка на главном экране	Иконка Manifest + экран запуска	Усиление бренда, прямой конверсии нет	Полдня	Средний

2. Когда стоит браться, а когда не тратить время

Решение принимают по трём показателям: доля мобильного трафика, частота возвратов и качество сети в регионе пользователя. Если все три совпадают, PWA стоит вложений.

Сценарий первый: сайт промышленных клапанов для рынка Ближнего Востока, доля мобильного трафика 65%, пользователи в основном из Саудовской Аравии и ОАЭ, покрытие 4G нестабильное, месячная частота возвратов 25%. В этом случае выгода от офлайн-кэша Service Worker очевидна: пользователь в Саудовской Аравии смотрит параметры продукции с телефона прямо на заводе, и страница открывается мгновенно даже при слабой сети. Такой сайт стоит 2–3 дней работы над предварительным кэшированием Service Worker. Как это сочетать с CDN, читайте в Глобальное ускорение CDN.

Сценарий второй: сайт B2B-оборудования для рынков Европы и США, доля десктопного трафика 70%, пользователь заходит в среднем всего 1,2 раза, частота возвратов всего 8%. В этом случае PWA почти не даёт выгоды. Пользователь приходит, заполняет форму запроса и уходит, устанавливать на десктоп он не станет. Разрешение на push-уведомления дают редко, открывают их тоже редко — чистые потери времени на разработку. Потратьте эти 2 недели на оптимизацию формы и контент — отдача будет в 10 раз выше. Как анализировать процент отказов от формы, читайте в процент отказов от формы запроса.

Показатель	PWA делать не стоит	Можно рассмотреть офлайн-кэш	Стоит сделать полный PWA
Доля мобильного трафика	Меньше 30%	30–60%	Более 60%
Месячная частота возвратов	Ниже 15%	15–25%	Более 25%
Сеть в регионе пользователя	Стабильная сеть в Европе, США, Японии и Корее	Смешанные регионы	Слабая сеть на Ближнем Востоке, в Юго-Восточной Азии и Латинской Америке
Среднее число визитов пользователя	1–1,5 раза	2–3 раза	Больше 3 раз
Ресурсы фронтенд-команды	0–1 человек	1–2 человека	Больше 2

III. Как настроить офлайн-кэш и не запутать его

Самая частая поломка Service Worker — «закэшировал старую версию, и пользователь вечно видит старую страницу». Проблема не в PWA, а в неверно настроенной стратегии кэширования. Правильный подход — многоуровневое кэширование: для статики (CSS/JS/изображения) стратегия «сначала кэш», для HTML-страниц — «сначала сеть»: каждый раз сначала пробуем сеть, при неудаче откатываемся к кэшу. Так пользователь всегда видит свежий контент, а кэш подстраховывает только при отсутствии сети.

Ещё одна практическая деталь: обновление версии Service Worker. Когда вы выпускаете новую версию фронтенда, старый Service Worker всё ещё управляет кэшем на устройствах пользователей. Нужно прописать в Service Worker логику skipWaiting и clients.claim либо показать пользователю на странице «Сайт обновился, нажмите, чтобы перезагрузить». Если этого не сделать, пользователь может неделю сидеть на старой версии.

Пример из практики: сайт мебели для зарубежных рынков запустил PWA и обнаружил жалобы «почему сайт не обновляется». Разобрались: Service Worker кэшировал HTML главной страницы тоже по стратегии «сначала кэш», маркетинг поменял баннер на главной, а у пользователей неделю оставалась старая картинка. После перехода на «сначала сеть» для HTML и «сначала кэш» для статики проблема исчезла, а мгновенное открытие подстраниц при слабой сети сохранилось.

Тип ресурса	Стратегия кэширования	Когда обновлять	Частая ошибка
HTML-страницы	Сначала сеть, при неудаче — кэш	При каждом запросе сначала пробуем сеть	Сначала кэш — контент не обновляется
CSS/JS (с хэшем)	Сначала кэш, долгое хранение	Хэш в имени файла меняется — кэш обновляется сам	Без хэша старый кэш не сбросится
Изображение	Сначала кэш, обновление в фоне	В фоне подтягивается новая версия и заменяет старую	Исходные картинки слишком большие — предкэш забьёт всё хранилище
Данные API	Сначала сеть, кэш как запасной вариант	При каждом запросе сначала пробуем сеть	Цена закэшировалась — пользователь видит устаревшее предложение
Файлы шрифтов	Сначала кэш, долгое хранение	Обновление при смене версии	CORS между доменами настроен неверно

Четвёртое: подсказки об установке и push-уведомления — стоит ли тратить время

Если на вашем сайте уже сделан офлайн-кэш и вы хотите добавить подсказку об установке, слушайте событие beforeinstallprompt: спрячьте стандартное предложение браузера и покажите вместо него свой баннер или кнопку. По клику вызывайте prompt() — так конверсия в установку в 2–3 раза выше, чем при нативном окне браузера, потому что пользователь нажимает уже с готовностью.

Но в B2B какая разница, что установок стало 3–5%? Сколько из этих 3% действительно вернутся лишний раз из-за установленного приложения? По данным прирост возвратов обычно меньше 2%. Отдача от вложений невысокая.

С push-уведомлениями тем более осторожнее. Не спрашивайте «Разрешить уведомления?» при первом визите — 80% откажутся. Правильный момент — после того как пользователь сделал что-то значимое (отправил запрос, скачал белый документ): тогда спросите «Получать уведомления об обновлении цен?» — и доля согласий доходит до 30–40%. Даже с разрешением следите за частотой: не чаще раза в неделю, иначе пользователь сразу отключит уведомления в настройках браузера.

Функции	Нативный опыт браузера	После своего баннера	Реальная выгода в B2B
Момент подсказки об установке	Сразу при визите — 90% отказов	После действия пользователя — 60% отказов	Установок больше на 1–3 п.п.
Момент запроса на push	При первом визите — 80% отказов	После целевого действия — 60% отказов	Согласий больше на 10–20 п.п.
Открываемость push	Не применимо	После оптимизации 4–8%	Прирост возвратов 1–3%
Поддержка в iOS Safari	Автоматическое окно не поддерживается	Нужно вручную подсказать добавить на главный экран	На iOS почти нет выгоды

FAQ: частые вопросы

Помогает ли PWA в SEO?

Сама по себе PWA не фактор ранжирования, но косвенно помогает: Service Worker улучшает LCP у возвращающихся пользователей, а значит и оценку Core Web Vitals; у тех, кто установил приложение на рабочий стол, выше доля возвратов — это хороший сигнал. Google официально заявлял, что PWA не прямой сигнал ранжирования, так что делать PWA ради SEO не стоит. Реальную ценность для SEO дают контент, внешние ссылки и удобство страниц, а PWA — только бонус.

Как сделать PWA на WordPress? Нужно самому писать Service Worker?

Писать самому не нужно. Для WordPress есть готовые PWA-плагины (например, PWA for WP, SuperPWA): после установки они сами создают Service Worker и manifest, а офлайн-кэш и подсказку об установке включают в один клик. В настройках плагина выберите стратегию кэширования: для HTML — network first, для статики — cache first. Базовые возможности PWA заработают за 10 минут. Если нужна кастомизация — правьте исходники плагина.

Работают ли push-уведомления PWA на iOS?

Начиная с iOS 16.4 Safari поддерживает Web Push, но только при условии, что пользователь сначала добавил сайт на главный экран. Для обычного пользователя это высокий барьер, и большинство владельцев iOS этого делать не станут. По фактическим данным, доля согласий на push в PWA на iOS меньше трети от показателя на Android. Если ваши пользователи в основном на iPhone, push-уведомления можно смело не делать — сосредоточьтесь на Android и Chrome на десктопе.

Service Worker закэшировал старую версию — как принудительно обновить?

Два шага. Первый: добавьте в код Service Worker skipWaiting и clients.claim, чтобы новая версия активировалась сразу после установки. Второй: добавьте на страницу логику проверки версии — когда обнаружится обновление Service Worker, покажите в правом верхнем углу небольшую подсказку «Сайт обновлён, нажмите, чтобы перезагрузить». Не перезагружайте страницу принудительно: пользователь в этот момент может заполнять форму и потеряет данные. Пусть он сам решит, когда перезагружать.

Как измерить долю установок PWA и какая она считается нормальной?

Поставьте отдельные события на beforeinstallprompt и appinstalled и отправляйте их в GA4 или на свой бэкенд. Нормальный диапазон для B2B-сайта: Chrome на десктопе — от 0,5% до 2%, Chrome на мобильных — от 2% до 5%, на iOS — практически ноль. Если ваша доля установок ниже 0,5%, значит пользователям вообще не нужно ваше приложение — не вкладывайтесь в это дальше.

Из-за офлайн-кэша пользователи не увидят устаревшие цены и остатки?

Увидят — это самая частая проблема. Решение — многоуровневое кэширование: HTML-страницы всегда network first и читаются из кэша только при отсутствии сети; динамические данные вроде цен и остатков в офлайн-кэш не попадают вообще, их каждый раз тянут из API в реальном времени. Картинки и статику кэшировать можно спокойно. Правило простое: всё, по чему пользователь принимает решение (цена, срок поставки, остатки), не кэшируется.

В заключение

В контексте B2B-сайта PWA — скорее приятное дополнение, чем необходимость. Реально стоит вкладываться только в офлайн-кэш через Service Worker, особенно если на рынки со слабым интернетом — Ближний Восток, Юго-Восточную Азию, Латинскую Америку — приходится больше 30% вашего трафика. Подсказка об установке и push-уведомления дают мало, а без них основной бизнес не пострадает.

Начните с минимально жизнеспособного варианта: поставьте один PWA-плагин, включите только офлайн-кэш и через 2 недели посмотрите, как изменился LCP у вернувшихся пользователей с мобильных. Если в зонах слабой сети LCP упал с 4 секунд до 2,5 — вложения того стоят. Подсказку об установке и push-уведомления добавляйте позже, когда убедитесь, что офлайн-кэш работает, и у команды останутся силы. Не беритесь сразу за все три компонента PWA.

Запомните одну фразу: ценность PWA не в том, что его “ставят на рабочий стол”, а в том, что он мгновенно открывается даже при слабой сети. Первое — приманка, второе — реальная проблема.