← Все статьи

Что такое прогрессивное веб-приложение (PWA) и нужно ли оно вам?

Burncode Team 4 минуты чтения

Прогрессивное веб-приложение, или PWA, — это сайт, который после нескольких посещений начинает вести себя как установленное приложение. Его можно добавить на главный экран телефона, он может работать офлайн или при плохом соединении и умеет присылать push-уведомления — и всё это без магазина приложений. По сути, это по-прежнему сайт. Разница в нескольких браузерных технологиях поверх него: service worker, который кэширует ресурсы и отвечает за работу офлайн, манифест веб-приложения, который сообщает браузеру, как отображать иконку и экран загрузки, и HTTPS, без которого всё это по умолчанию не работает.

Что вы получаете на самом деле

Реальная практическая польза от превращения сайта в PWA сводится к трём вещам.

  • Надёжность при плохой связи. Когда сеть пропадает, service worker может отдавать закэшированные страницы и ресурсы, так что приложение не превращается в пустой экран при первой же потере сигнала. Для контента, который не меняется каждую секунду, ради одного этого уже стоит постараться.
  • Установка без установки. Добавить сайт на главный экран можно в два касания — без модерации в магазине приложений, без графика выкатки обновлений и без барьера в виде отзывов и оценок между исправлением и человеком, который пользуется приложением.
  • Push-уведомления, которые раньше были доступны только приложениям, а теперь на большинстве платформ работают (с разрешения пользователя) прямо из браузера.

Чего PWA не заменит

PWA подходит на замену нативному приложению далеко не всегда, и стоит честно признать, в чём оно уступает. Глубокая интеграция с операционной системой — Bluetooth, отслеживание местоположения в фоне, полноценный доступ к камере или NFC, сложная синхронизация данных офлайн — по-прежнему лучше, а иногда и исключительно, реализуется в нативном приложении. Поддержка возможностей PWA в iOS исторически отставала от Android, поэтому если ваши пользователи в основном на iPhone, а вам нужны фоновые push-уведомления или продвинутая работа офлайн, протестируйте нужные функции до того, как делать ставку на PWA, а не рассчитывайте, что всё будет как на Android.

Кроме того, по умолчанию PWA не появится в App Store или Google Play, а это важно, если оптимизация в магазинах приложений (ASO) и поиск в сторах входят в ваши планы по привлечению пользователей.

Нужно ли оно вам?

Важен не вопрос «модно ли PWA», а вопрос «нужно ли для ключевого сценария моего продукта что-то, чего не может дать сайт с service worker». Контентный сайт, интернет-магазин, сервис бронирования, внутренний дашборд, приложение с каталогом объявлений — обычно это хорошие кандидаты в PWA, потому что их ценность в быстром доступе к информации и нескольких чётко определённых действиях, а не в глубокой интеграции с железом.

Несколько честных признаков того, что PWA — правильный выбор:

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

Если большая часть этих пунктов к вам не относится или приложение изначально мобильное и активно использует камеру, фоновое местоположение или железо, лучшей инвестицией обычно будет нативное или кроссплатформенное приложение, а PWA всегда можно сделать позже как лёгкое дополнение к нему.

Что на самом деле входит в разработку PWA

Ничего экзотического в этих технологиях сегодня нет — service worker и манифест веб-приложения поддерживаются во всех основных современных браузерах, — но чтобы сделать всё хорошо, мало просто добавить файл манифеста. Важна стратегия кэширования: если кэшировать слишком агрессивно, после деплоя пользователи будут видеть устаревший контент, если слишком мало — преимущество работы офлайн пропадёт полностью. Иконки и экраны загрузки нужно сгенерировать в правильных размерах для каждой платформы. И всё это необходимо протестировать на реальных устройствах, а не только в эмуляторе инструментов разработчика на десктопе, ведь предложения установки и поведение офлайн заметно различаются в Android и iOS.

Именно такой работой мы занимаемся в рамках проектов по веб-разработке в Burncode: правильно встраиваем логику кэширования и работы офлайн в сайт, а не прикручиваем файл манифеста в самом конце, — чтобы приложение действительно вело себя так, как ожидают люди, когда оно оказывается у них на главном экране.