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

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

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

Demián Renzulli

Фон

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

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

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

Добро

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

Локализация/язык: использование домена верхнего уровня с кодом страны для разделения сайтов, которые будут обслуживаться в разных странах (например, https://www.google.com.ar ), или использование субдоменов для разделения сайтов, ориентированных на разные местоположения (например, 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-адреса сценария сервисного работника должно совпадать с источником страницы, вызывающей Register() . Это означает, что, например, страница https://www.example.com не может вызвать register() с URL-адресом сервисного работника по адресу https://section.example.com .

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

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

Кэширование

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

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

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

Разрешения

Разрешения также распространяются на источники. Это означает, что если пользователь предоставил данное разрешение источнику 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 , когда пользователь выходит за пределы области действия в автономном режиме.

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

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

Заключение

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

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

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

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