Что такое PWA

Представим директора магазина, который велел сделать приложение без магазинов приложений, ожидания и расходов на поддержку. На следующий день ему показали иконку на телефоне: расходы пока не обнаружили, потому что до оформления заказа еще не дошли.

PWA – это веб-приложение, которое использует возможности браузера для работы, похожей на отдельную программу. Установка, офлайн-режим и уведомления доступны в зависимости от реализации, устройства и поддержки браузером.

Что скрывается за тремя буквами

Progressive Web App переводится как «прогрессивное веб-приложение». Его основа – веб-технологии: HTML, CSS и JavaScript. Пользователь открывает адрес, как у обычного сайта, а разработчик добавляет возможности, которые делают повторную работу удобнее: запуск с отдельной иконки, сохранение части данных, работу с некоторыми функциями устройства.

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

Когда говорят «PWA-версия сайта», обычно имеют в виду веб-интерфейс с такими дополнениями. Это может быть тот же продукт по тому же адресу, а не отдельный проект с собственной базой товаров. Но общая кодовая база не отменяет проверки разных экранов, систем и способов запуска.

Паспорт приложения и дежурный по сети

Два важных элемента часто складывают в одну техническую коробку, хотя обязанности у них разные. Web app manifest – файл с описанием приложения для браузера: названием, иконками, стартовым адресом и параметрами отображения. Он помогает представить сайт как устанавливаемое приложение. Сам по себе manifest не сохраняет каталог, не принимает оплату и не чинит связь.

Service worker – скрипт, который работает отдельно от кода открытой страницы и может участвовать в обработке сетевых запросов. С его помощью организуют кеширование ресурсов и поведение при потере соединения. Он также участвует в работе веб-push. Для рабочего сайта такие возможности требуют защищенного соединения HTTPS.

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

Офлайн – это конкретный договор с пользователем

Для условного каталога можно сохранить описания просмотренных товаров и показать их без связи. Но цена могла измениться, остаток – закончиться, а выбранный интервал доставки – занять другой покупатель. Поэтому рядом с сохраненными данными нужны понятные признаки актуальности. Фраза «работает офлайн» слишком широка, если автономно работает только заставка.

Другой сценарий – сотрудник заполняет черновик заявки в дороге. Интерфейс хранит ввод локально и явно сообщает, что документ пока не отправлен. После восстановления сети данные передаются на сервер, а пользователь получает подтверждение. Если заявка конфликтует с уже измененной записью, необходимо правило разрешения конфликта. Интернет вернулся, договоренности сами не вернулись.

Особенно важно отделять локальное действие от завершенной операции. Нажатая кнопка не означает, что сервер принял заказ или платеж. Если приложение складывает запросы в очередь, для каждого нужен статус, безопасный повтор и защита от дублей. Очередь должна переживать предусмотренные проектом сбои, а ее состояние – быть видимым человеку.

Установка и push зависят от среды

Установка PWA устроена по-разному в разных браузерах и операционных системах. Где-то пользователь увидит предложение, где-то потребуется действие через меню, а доступный результат будет отличаться. Нельзя обещать одну универсальную кнопку всем посетителям. Проверять нужно реальные сочетания устройства и браузера, которыми пользуется аудитория.

Веб-push тоже требует поддержки, подписки пользователя и разрешенных условий работы. Наличие PWA не выдает компании бессрочный пропуск к уведомлениям человека. Пользователь может отказать, отозвать разрешение или изменить настройки. Поэтому важный статус заказа стоит сохранять в самом интерфейсе, а коммуникацию проектировать с учетом недоступности push.

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

Когда подход полезен и что проверить до запуска

PWA стоит рассматривать для сервисов, куда люди возвращаются: личного кабинета, каталога для постоянных заказчиков, рабочего интерфейса полевых сотрудников. Выигрыш появляется, если быстрый повторный доступ и продуманный режим слабой связи помогают закончить конкретную работу. Для страницы, которую читают один раз, приглашение установить приложение может оказаться самой сложной частью знакомства.

• Открыть ключевой сценарий по обычной ссылке и после установки
• Отключить сеть до загрузки и посреди заполнения формы
• Проверить, какие данные видны без связи и как обозначена их актуальность
• Обновить приложение и убедиться, что старые сохраненные ресурсы не ломают новый интерфейс
• Выйти из учетной записи и проверить обращение с локально сохраненными личными данными
• Повторить проверки на устройствах и браузерах основной аудитории

Оценивать результат лучше по завершенным задачам: смог ли клиент повторить заказ, сохранил ли сотрудник черновик, понял ли человек причину задержки. Число установок полезно, но иконку легко принять за достижение. Настоящее приложение начинается там, где после торжественного запуска удается что-нибудь сделать.