Активы и данные

Прогрессивное веб-приложение — это веб-сайт; все его ресурсы такие же, как и в Интернете, но с новыми инструментами, позволяющими ускорить загрузку этих ресурсов в сети и сделать их доступными в автономном режиме.

Компоненты приложения

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

Прогрессивное веб-приложение — это веб-сайт, поэтому все его ресурсы такие же, как и в Интернете:

  • HTML для контента и рендеринга начальной страницы.
  • JavaScript для логики, включая возможность запуска модулей WebAssembly (скомпилированный код) и рендеринга 2D- и 3D-графики, оптимизированной для аппаратного обеспечения.
  • CSS для макета, стиля и анимации.
  • Изображения в веб-форматах, таких как PNG, JPEG, WebP и SVG.
  • Видео в веб-форматах, таких как MPEG-4 и WebM.
  • Веб-шрифты.
  • Данные в JSON или других форматах.

По умолчанию веб-сайты загружают ресурсы по сети, начиная с HTML и заканчивая остальными ресурсами.

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

Приложения для конкретной платформы и PWA

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

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

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

Кэши и хранилище

С момента появления Интернета разработчики не имели полного контроля над тем, как кэшируется ресурс. Браузер отвечает за кэш HTTP, и он может кэшировать и обслуживать ресурсы, а может и не кэшировать их в зависимости от разных политик. Другие варианты хранения, такие как Web Storage и IndexedDB, предназначались для хранения простых данных и объектов.

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

  • Веб-хранилище : включает localStorage и sessionStorage . Эти API хранят простые пары строк «ключ/значение». Веб-хранилище ограничено и имеет синхронный API, поэтому его следует избегать, когда это возможно.
  • IndexedDB : объектно-ориентированная база данных (без SQL) с асинхронным API, которая хороша для веб-производительности. IndexedDB может хранить структурированные и двоичные данные на стороне клиента. Обычно это то, что вы будете использовать для хранения данных, например, то, что вы получите или отправите в виде запроса API. Также полезно сразу сохранить данные локально, а затем синхронизировать их с сервером. API IndexedDB используется для взаимодействия с базой данных.
  • Хранилище кэша : совокупность пар HTTP-запросов и ответов, которые можно использовать для хранения и извлечения ресурсов (с их HTTP-заголовками) точно так же, как они доставляются с сервера. API Cache Storage позволяет хранить, извлекать, обновлять и удалять сетевые запросы, например, для ваших активов, даже в автономном режиме.

Требуются работники сферы обслуживания

PWA может хранить свои ресурсы в Cache Storage и IndexedDB, но как мы можем использовать эти ресурсы, чтобы обеспечить быструю работу ваших пользователей в автономном режиме? Ответ? Работники сферы обслуживания.

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

Готов к работе в автономном режиме

Пользователи ожидают, что ваше приложение будет быстрым и всегда готовым к работе. Это означает, что ваше приложение должно работать в автономном режиме.

Готовность к работе в автономном режиме не означает, что весь ваш контент или услуги должны быть доступны без подключения к сети. Однако наличие хотя бы базового опыта, когда пользователь находится в автономном режиме, например страницы, которая просит вас подключиться к Интернету для продолжения, обеспечит лучший пользовательский опыт, позволяя пользователю работать с вашим приложением вместо общей ошибки браузера. . В некоторых браузерах это обязательная функция для соответствия критериям установки PWA. Лучше отображать пользовательский интерфейс вашего PWA вместе с кэшированным контентом. Предоставление пользователям возможности продолжать использовать весь PWA и синхронизировать изменения сервера, когда они снова подключаются к сети, — это золотой стандарт для работы в автономном режиме.

Чтобы сделать ваше приложение доступным в автономном режиме, вам необходимо кэшировать ресурсы, необходимые для работы в автономном режиме, и заставить вашего сервисного работника обслуживать их позже. Обязательно добавьте автономные ресурсы в свой кеш, прежде чем они вам понадобятся. Это частный случай, когда вы не можете кэшировать их по запросу.

Часто используемые подходы к кэшированию

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

  • Предварительное кэширование: выберите ресурсы, которые вы хотите установить при первой загрузке; они должны включать HTML и минимальные ресурсы для рендеринга приложения. При использовании precache помните, что вы используете пространство и сеть устройства. Будьте сознательны и ответственны при загрузке ресурсов и их кэшировании.
  • Кэшировать по мере необходимости: используется для добавления ресурсов в кеш при их запросе. Обычно это ресурсы, которые могут меняться независимо от версии вашего приложения, например изображения или контент. См. раздел «Кэширование» , чтобы узнать о различных стратегиях кэширования по мере необходимости.
  • API и веб-сервисы: вызовы API можно кэшировать; или вместо кэширования ответов API вы можете хранить их данные в IndexedDB.

Обновление активов

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

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

Размер и срок службы

Обычно приложения для конкретной платформы не имеют ограничений по размеру; при установке приложения могут иметь размер в гигабайты и более. Пока устройство имеет емкость, установка будет разрешена. Кроме того, пока приложение установлено, оно будет использовать этот общий объем памяти независимо от того, используете вы его или нет. Для PWA хранилище обрабатывается по-другому. Браузер будет хранить ваши ресурсы на основе политик, которые вы определяете в логике вашего PWA.

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

Браузеры могут удалять ресурсы из-за нехватки места или после нескольких недель бездействия, если пользователь использует ваше PWA в браузере. На некоторых платформах, если пользователь установит ваше PWA, выселения не произойдет. Там, где это возможно, код может запросить постоянное хранилище через API, чтобы избежать такого вытеснения.

Ресурсы