Эта страница переведена с помощью Cloud Translation API.

Прогрессивные веб-приложения на сайтах с несколькими источниками

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

Demián Renzulli

Фон

В прошлом использование архитектур с несколькими источниками имело некоторые преимущества, но для Progressive Web Apps такой подход создает множество проблем. В частности, политика одного источника накладывает ограничения на совместное использование таких вещей, как service worker и caches, разрешения и достижение автономного опыта в нескольких источниках. В этой статье будут описаны хорошие и плохие варианты использования нескольких источников, а также будут объяснены проблемы и обходные пути для создания Progressive Web Apps на сайтах с несколькими источниками.

Хорошее и плохое использование множественного происхождения

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

Хороший

Давайте сначала рассмотрим полезные причины:

Локализация/Язык: использование домена верхнего уровня с кодом страны для разделения сайтов, обслуживаемых в разных странах (например, https://www.google.com.ar ), или использование поддоменов для разделения сайтов, ориентированных на разные местоположения (например, https://newyork.craigslist.org ), или для предложения контента на определенном языке (например, https://en.wikipedia.org ).
Независимые веб-приложения: использование различных поддоменов для предоставления опыта, цель которого значительно отличается от цели сайта на основном источнике. Например, на новостном сайте веб-приложение кроссвордов может быть намеренно предоставлено с https://crosswords.example.com и установлено и использовано как независимое PWA, без необходимости совместного использования каких-либо ресурсов или функций с основным сайтом.

Плохой

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

Несмотря на это, многие сайты продолжают структурироваться таким образом без особой причины или по причинам «устаревания». Одним из примеров является использование поддоменов для произвольного разделения частей сайта, которые должны быть частью единого опыта.

Например, крайне не рекомендуется использовать следующие шаблоны:

Разделы сайта: Разделение различных разделов сайта на поддомены. На новостных сайтах не редкость увидеть домашнюю страницу по адресу: https://www.example.com , в то время как спортивный раздел находится по адресу https://sports.example.com , политический раздел — по адресу https://politics.example.com и т. д. В случае сайта электронной коммерции, используйте что-то вроде https://category.example.com для категорий продуктов, https://product.example.com для страниц продуктов и т. д.
Поток пользователя: Другой подход, который не рекомендуется, — это разделение различных более мелких частей сайта, таких как страницы для входа или потоков покупки в поддоменах. Например, используя https://login.example.com и https://checkout.example.com .

Для случаев, когда миграция на единый источник невозможна, ниже приведен список проблем и (где это возможно) обходных путей, которые можно рассмотреть при создании прогрессивных веб-приложений.

Проблемы и обходные пути для PWA разного происхождения

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

Работники сферы услуг

Источник URL скрипта service worker должен совпадать с источником страницы, вызывающей register() . Это означает, что, например, страница по адресу https://www.example.com не может вызвать register() с URL service worker по адресу https://section.example.com .

Другое соображение заключается в том, что service worker может контролировать только страницы, размещенные под источником и путем, к которым он принадлежит. Это означает, что если service worker размещен на https://www.example.com , он может контролировать только URL-адреса из этого источника (в соответствии с путем, определенным в параметре scope ), но не будет контролировать никакие страницы в других поддоменах, например, в https://section.example.com .

В этом случае единственным решением является использование нескольких Service Worker (по одному на источник).

Кэширование

Объект Cache, indexedDB и localStorage также ограничены одним источником. Это означает, что невозможно получить доступ к кэшам, которые принадлежат https://www.example.com , например, из: https://www.section.example.com .

Вот несколько действий, которые вы можете выполнить для правильного управления кэшами в подобных сценариях:

Используйте кэширование браузера: всегда рекомендуется использовать традиционные лучшие практики кэширования браузера . Этот метод обеспечивает дополнительное преимущество повторного использования кэшированных ресурсов между источниками, что невозможно сделать с кэшем service worker. Для лучших практик использования HTTP Cache с service worker, вы можете взглянуть на этот пост .
Сохраняйте установку service worker легкой: если вы поддерживаете несколько service worker, не заставляйте пользователей платить большую стоимость установки каждый раз, когда они переходят к новому источнику. Другими словами: предварительно кэшируйте только те ресурсы, которые абсолютно необходимы.

Разрешения

Разрешения также ограничены источниками. Это означает, что если пользователь предоставил данное разрешение источнику https://section.example.com , оно не будет перенесено на другие источники, например https://www.example.com .

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

Установка

Для установки PWA каждый источник должен иметь свой собственный манифест с start_url , который относится к нему самому . Это означает, что пользователь, получающий приглашение на установку в данном источнике (например, https://section.example.com ), не сможет установить PWA с start_url в другом (например, https://www.example.com ). Другими словами, пользователи, получающие приглашение на установку в поддомене, смогут устанавливать PWA только для подстраниц, а не для основного URL-адреса приложения.

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

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

Прослушивание события beforeinstallprompt .
Предотвратите появление подсказки , вызвав event.preventDefault() .

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

Автономный режим

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

В большинстве случаев для этой проблемы нет решения, но можно применить обходной путь для небольших частей интерфейса, размещенных в поддоменах (например, рабочие процессы входа в систему):

Новый URL-адрес https://login.example.com может открываться внутри полноэкранного iframe.
После завершения задачи внутри iframe (например, процесс входа в систему) можно использовать postMessage() для передачи любой полученной информации из iframe обратно на родительскую страницу.
В качестве последнего шага, как только сообщение получено главной страницей, можно отменить регистрацию слушателей и окончательно удалить iframe из DOM.

Заключение

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

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

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

Выражаем огромную благодарность за технические обзоры и предложения: Пенни Маклахлан, Полу Ковеллу, Доминику Нг, Альберто Медине, Питу ЛеПейджу, Джо Медли, Чейни Цаю, Мартину Ширле и Андре Бандарре.