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

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

Demián Renzulli

Опубликовано 19 августа 2019 г.

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

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

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

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

Правильн

Вот несколько причин, почему это может быть полезно:

• Локализация и язык. Использование национального домена верхнего уровня, чтобы разделить сайты, предназначенные для разных стран (например, 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, в основном из-за правила того же источника, которое накладывает ряд ограничений. Давайте рассмотрим их по очереди.

Скрипты Service Worker

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

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

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

Внимание! Регистрация и использование нескольких активных service worker требует дополнительных ресурсов (памяти, ЦП и т. д.), поэтому тщательно продумайте, сколько активных service worker может понадобиться пользователю для навигации по сайту.

Кеширование

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

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

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

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

Когда сервис-воркер активен и запущен, правило ограничения домена также ограничивает перекрестные запросы, выполняемые внутри сервис-воркеров. К счастью, есть рекомендуемое решение – использовать CORS (как описано здесь). Не рекомендуется использовать режим no-cors при получении ресурсов в сервисе-исполнителе.

Разрешения

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

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

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

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

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

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

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

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

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

Примечание. В контексте доверенных веб-операций рекомендуется избегать этой проблемы, проверяя все источники с помощью Digital Asset Links.

Заключение

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

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

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

Выражаем благодарность за технические обзоры и предложения следующим специалистам: Пенни Маклахлан (Penny Mclachlan), Пол Ковелл (Paul Covell), Доминик Нг (Dominick Ng), Альберто Медина (Alberto Medina), Пит Лепаж (Pete LePage), Джо Медли (Joe Medley), Чейни Цай (Cheney Tsai), Мартин Ширле (Martin Schierle) и Андре Бандарра (Andre Bandarra).