Проектирование вашего приложения, позволяющее максимально эффективно использовать технологию, которая делает PWA надежными, легко устанавливаемыми и работоспособными, начинается с понимания вашего приложения и его ограничений, а также выбора подходящей архитектуры для обоих.
СПА против МПА
Сегодня в веб-разработке существуют два основных архитектурных шаблона: одностраничные приложения, или SPA, и многостраничные приложения, или MPA.
Одностраничные приложения определяются тем, что клиентский JavaScript контролирует большую часть или всю HTML-рендеринг страницы на основе данных, полученных или предоставленных приложению. Приложение переопределяет встроенную навигацию браузера, заменяя ее функциями маршрутизации и обработки представлений.
Многостраничные приложения обычно имеют предварительно обработанный HTML-код, отправляемый непосредственно в браузер, часто дополненный клиентским JavaScript после того, как браузер завершил загрузку HTML, и полагающийся на встроенные механизмы навигации браузера для отображения последующих представлений.
Обе архитектуры можно использовать для создания PWA.
У каждого из них есть свои преимущества и недостатки, и выбор правильного варианта использования для вашего случая использования и контекста является ключом к обеспечению быстрого и надежного взаимодействия с вашими пользователями.
Одностраничные приложения
- В основном атомарные обновления на странице.
- Зависимости на стороне клиента загружаются при запуске.
- Последующие загрузки выполняются быстро из-за использования кэша.
- Высокая первоначальная стоимость загрузки.
- Производительность зависит от аппаратного обеспечения устройства и сетевого подключения.
- Требуется дополнительная сложность приложения.
Одностраничные приложения хорошо подходят для архитектуры, если:
- Взаимодействие с пользователем в основном сосредоточено вокруг атомарных обновлений взаимосвязанных данных, отображаемых на одной странице, например, панели мониторинга данных в реальном времени или приложения для редактирования видео.
- Ваше приложение имеет зависимости инициализации только на стороне клиента, например, сторонний поставщик аутентификации с непомерно высокой стоимостью запуска.
- Данные, необходимые для загрузки представления, зависят от определенного контекста только на стороне клиента, например, отображения элементов управления для части подключенного оборудования.
- Приложение небольшое и достаточно простое, поэтому его размер и сложность не влияют на перечисленные выше минусы.
SPA могут оказаться не лучшим выбором архитектуры, если:
- Первоначальная производительность нагрузки имеет важное значение. SPA обычно необходимо загружать больше JavaScript, чтобы определить, что загружать и как это отображать. Время анализа и выполнения этого JavaScript в сочетании с получением контента медленнее, чем отправка обработанного HTML.
- Ваше приложение работает в основном на устройствах с низким и средним энергопотреблением. Поскольку SPA зависят от JavaScript для рендеринга, взаимодействие с пользователем гораздо сильнее зависит от мощности конкретного устройства, чем в MPA.
Поскольку SPA должны заменять встроенную навигацию браузера своей маршрутизацией, SPA требуют минимального уровня сложности для эффективного обновления текущего представления, управления изменениями навигации и очистки предыдущих представлений, которые в противном случае обрабатывались бы браузером, что усложняет их. в целом для поддержания и большей нагрузки на устройство пользователя.
Многостраничные приложения
- В основном полностраничные обновления.
- Начальная скорость рендеринга имеет решающее значение.
- Сценарии на стороне клиента могут быть усовершенствованием.
- Вторичные представления требуют еще одного вызова сервера.
- Контекст не переносится между представлениями.
- Требуется сервер или предварительный рендеринг.
Многостраничные приложения являются хорошим архитектурным выбором, если:
- Взаимодействие с пользователем в основном сосредоточено на представлении одного фрагмента данных с дополнительными контекстными данными, например, новостей или приложения электронной коммерции.
- Начальная скорость рендеринга имеет решающее значение, поскольку отправка уже обработанного HTML-кода в браузер происходит быстрее, чем его сборка из запроса данных после загрузки, анализа и выполнения альтернативы на основе JavaScript.
- Интерактивность или контекст на стороне клиента могут быть включены в качестве улучшения после начальной загрузки, например, путем наложения профиля на отображаемую страницу или добавления вторичных контекстно-зависимых компонентов на стороне клиента.
MPA не может быть хорошим выбором архитектуры, если:
- Повторная загрузка, повторный анализ и повторное выполнение вашего JavaScript или CSS обходятся непомерно дорого. Этот недостаток смягчен в PWA с сервисными работниками.
- Контекст на стороне клиента, например местоположение пользователя, не переносится плавно между представлениями, и повторное получение этого контекста может оказаться дорогостоящим. Его необходимо либо захватить и извлечь, либо повторно запросить между представлениями.
Потому что отдельные представления должны динамически отображаться на сервере или предварительно обрабатываться перед доступом, что потенциально ограничивает хостинг или увеличивает сложность данных.
Какой выбрать?
Даже несмотря на эти плюсы и минусы, обе архитектуры подходят для создания PWA. Вы даже можете смешивать их для разных частей вашего приложения, в зависимости от его потребностей, например, чтобы списки магазинов соответствовали архитектуре MPA, а поток оформления заказа — архитектуре SPA.
Независимо от выбора, следующим шагом будет понимание того, как лучше всего использовать сервис-воркеров для обеспечения наилучшего качества обслуживания.
Сила сервисного работника
Сервис-воркер обладает большими возможностями, помимо базовой маршрутизации и доставки кэшированных и сетевых ответов. Мы можем создавать сложные алгоритмы, которые могут улучшить взаимодействие с пользователем и производительность.
Сервисный работник включает в себя (SWI)
Новая модель использования сервис-воркеров как неотъемлемой части архитектуры сайта — это сервис-воркеры (SWI). SWI разделяет отдельные ресурсы, обычно HTML-страницу, на части в зависимости от их потребностей в кэшировании, а затем объединяет их вместе в сервис-воркере, чтобы улучшить согласованность, производительность и надежность, одновременно уменьшая размер кэша. 
Это изображение представляет собой образец веб-страницы. Он состоит из пяти различных разделов, которые разбивают страницу на:
- Общая планировка.
- Глобальный заголовок (верхняя темная полоса).
- Область содержимого (средние левые строки и изображение).
- Боковая панель (высокая темная полоса посередине справа).
- Нижний колонтитул (темная нижняя панель).
Общая планировка
Общий макет вряд ли будет часто меняться и не имеет зависимостей. Это хороший кандидат для предварительного кэширования .
Верхний и нижний колонтитулы
Глобальный верхний и нижний колонтитулы содержат такие элементы, как верхнее меню и нижний колонтитул сайта, и представляют собой особую проблему: если страница должна быть кэширована целиком, они могут меняться между загрузками страниц, в зависимости от того, когда данная страница была кэширована.
Разделив их и кэшировав независимо от содержимого, вы можете гарантировать, что пользователи всегда будут получать одну и ту же версию, независимо от того, когда они кэшируются. Поскольку они нечасто обновляются, они также являются хорошими кандидатами для предварительного кэширования. Однако у них есть зависимость: CSS и JavaScript сайта.
CSS и JavaScript
В идеале CSS и JavaScript сайта должны кэшироваться с использованием устаревшей стратегии повторной проверки, чтобы обеспечить возможность дополнительных обновлений без необходимости обновления сервис-воркера, как в случае с предварительно кэшированными ресурсами. Тем не менее, их также необходимо сохранять на минимальном уровне всякий раз, когда сервисный работник обновляет новый глобальный верхний или нижний колонтитул. По этой причине их кеш также должен обновляться последней версией ресурсов при установке сервисного работника.
Область контента
Далее идет область контента. В зависимости от частоты обновлений хорошей стратегией здесь может быть либо сначала сеть, либо устаревшие обновления при повторной проверке. Изображения следует кэшировать по принципу «сначала кэшировать», как обсуждалось ранее.
Боковая панель
Наконец, если предположить, что содержимое боковой панели содержит второстепенный контент, такой как теги и связанные элементы, его извлечение из сети не является достаточно важным. Для этого подойдет устаревшая стратегия повторной проверки.
Теперь, пройдя через все это, вы можете подумать, что такой вид кэширования по разделам можно использовать только для одностраничных приложений. Но, приняв в свой сервис-воркер шаблоны, вдохновленные пограничными или серверными включениями , с некоторыми расширенными функциями сервис-воркера, вы можете сделать это для любой архитектуры.
Попробуйте сами
Вы можете попробовать включить сервис-воркера в следующей кодовой лаборатории:
Потоковая передача ответов
Предыдущую страницу можно было создать с использованием модели оболочки приложения в мире SPA, где оболочка приложения кэшируется, затем обслуживается, а контент загружается на стороне клиента. Благодаря внедрению и широкой доступности Streams API оболочка приложения и контент могут быть объединены в сервис-воркере и переданы в потоковом режиме в браузер, что обеспечивает гибкость кэширования оболочки приложения со скоростью MPA.
Это происходит потому, что:
- Потоки могут создаваться асинхронно, позволяя различным частям потока поступать из других источников.
- Запрашивающая часть потока может начать работу над ответом, как только станет доступен первый фрагмент данных, вместо того, чтобы ждать завершения всего элемента.
- Анализаторы, оптимизированные для потоковой передачи, включая браузер, могут постепенно отображать содержимое потока до его завершения, ускоряя воспринимаемую производительность ответа.
Благодаря этим трем свойствам потоков архитектуры, построенные на потоковой передаче, обычно имеют более высокую воспринимаемую производительность, чем те, которые этого не делают.
Работа с API Streams может оказаться сложной задачей, поскольку он сложный и низкоуровневый. К счастью, есть модуль Workbox , который может помочь с настройкой потоковой передачи ответов для ваших сервис-воркеров.
Домены, источники и область действия PWA
Веб-работники, в том числе сервисные работники, хранилища и даже установленное окно PWA, управляются одним из наиболее важных механизмов безопасности в Интернете: политикой одного и того же происхождения. В пределах одного источника предоставляются разрешения, данные могут использоваться совместно, а работник службы может общаться с разными клиентами. За пределами одного источника разрешения не предоставляются автоматически, а данные изолированы и недоступны между разными источниками.
Политика одного и того же происхождения
Два URL-адреса определяются как имеющие точное происхождение, если протокол, порт и хост совпадают.
Например: https://squoosh.app и https://squoosh.app/v2 имеют одно и то же происхождение, но http://squoosh.app , https://squoosh.com , https://app.squoosh.app и https://squoosh.app:8080 имеют разное происхождение. Дополнительную информацию и примеры можно найти в справочнике MDN по политике одного и того же происхождения .
Изменение субдоменов — не единственный способ изменить хост. Каждый хост состоит из домена верхнего уровня (TLD), домена вторичного уровня (SLD) и нуля или более меток (иногда называемых субдоменами), разделенных точками между ними и читаемых справа налево в URL-адресе. Изменение любого из элементов приводит к использованию другого хоста.
В модуле управления окнами мы уже видели, как выглядит браузер в приложении, когда пользователь переходит к источнику, отличному от установленного PWA.
Этот браузер в приложении появится, даже если веб-сайты имеют одинаковые TLD и SLD, но с разными метками, поскольку в этом случае они считаются разным происхождением.
Одним из ключевых аспектов источника в контексте просмотра веб-страниц является то, как работают хранилище и разрешения. Один источник имеет много общих функций для всего контента и PWA в нем, в том числе:
- Квота хранилища и данные (IndexedDB, файлы cookie, веб-хранилище, хранилище кэша).
- Регистрация сервисных работников.
- Разрешения, предоставленные или запрещенные (например, веб-пуш, геолокация, датчики).
- Веб-пуш-регистрации.
При переходе из одного источника в другой весь предыдущий доступ аннулируется, поэтому разрешения необходимо предоставлять заново, и ваш PWA не сможет получить доступ ко всем данным, сохраненным в хранилище.