マルチオリジン サイトでのプログレッシブ ウェブアプリ

マルチオリジン サイトでプログレッシブ ウェブアプリを作成する際の課題と回避策。

Demián Renzulli

背景情報

これまで、マルチオリジン アーキテクチャを使用することにはいくつかの利点がありましたが、プログレッシブ ウェブアプリの場合、このアプローチには多くの課題があります。特に、同一オリジン ポリシーでは、Service Worker やキャッシュ、権限などの共有や、複数のオリジン間でのスタンドアロン エクスペリエンスの実現に関する制限が課されます。この記事では、複数オリジンの長所と短所について説明し、マルチオリジン サイトでプログレッシブ ウェブアプリを作成するための課題と回避策について説明します。

複数の生成元の良い使用と悪い使用

サイトでマルチオリジン アーキテクチャを採用する正当な理由はいくつかありますが、そのほとんどは、独立したウェブ アプリケーション セットを提供しているか、互いに完全に分離されたエクスペリエンスを作成するためです。避けるべき使用法もあります。

メリット

まず、有用な理由から見ていきましょう。

• ローカライズ / 言語: 国コードのトップレベル ドメインを使用して、異なる国で配信するサイトを分ける（例: 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 などに表示されることは珍しくありません。e コマースサイトの場合は、商品カテゴリに https://category.example.com、商品ページで https://product.example.com などを使用します。

• ユーザーフロー: もう 1 つの方法として、ログインフローや購入フローのページをサブドメインのページに分割するなど、サイトの小さな部分を分けることもおすすめしません。たとえば、https://login.example.com と https://checkout.example.com を使用します。

注: サイトをゼロから作成する場合は、サブドメインに分割しないことを強くおすすめします。既存のサイトの場合、単一の送信元に移行することが最善の方法です。

単一オリジンへの移行が不可能な場合の課題と、（可能な場合は）プログレッシブ ウェブアプリを作成する際に検討できる回避策を以下に記載します。

オリジンが異なる PWA に関する課題と回避策

複数のオリジンでウェブサイトを構築する場合、統一された PWA エクスペリエンスを提供するのは困難です。その主な原因は、同一オリジン ポリシーでさまざまな制約が発生することです。1 つずつ見ていきましょう

Service Worker

Service Worker スクリプトの URL の生成元は、register() を呼び出しているページの生成元と同じである必要があります。たとえば、https://www.example.com のページでは、https://section.example.com の Service Worker の URL を使用して register() を呼び出すことはできません。

もう一つの考慮事項は、Service Worker は、そのオリジンと所属パスでホストされているページのみを制御できることです。つまり、Service Worker が https://www.example.com でホストされている場合、（scope パラメータで定義されたパスに従って）そのオリジンからの URL のみを制御できますが、https://section.example.com などの他のサブドメインのページは制御できません。

この場合、唯一の回避策は複数の Service Worker を使用することです（送信元ごとに 1 つ）。

注意: 複数のアクティブな Service Worker を登録して、複数のアクティブな Service Worker を使用すると、追加のリソース（メモリ、CPU など）が消費されるため、ユーザーがサイト内を移動するために必要なアクティブな Service Worker の数を慎重に判断してください。

キャッシュ

Cache オブジェクト、indexesDB、localStorage も、単一のオリジンに制限されます。つまり、https://www.example.com に属するキャッシュに（たとえば https://www.section.example.com から）アクセスすることはできません。

このような状況でキャッシュを適切に管理するためにできることを以下に示します。

• ブラウザ キャッシュを活用する: 従来のブラウザ キャッシュのベスト プラクティスに従うことが常に推奨されます。この手法には、送信元間でキャッシュされたリソースを再利用できるという利点もあります。これは Service Worker のキャッシュでは不可能です。Service Worker で HTTP キャッシュを使用する方法に関するベスト プラクティスについては、こちらの投稿をご覧ください。

• Service Worker のインストールを軽量化: 複数の Service Worker を管理している場合は、ユーザーが新しい配信元に移動するたびに多額のインストール コストを支払うことは避けてください。つまり、絶対に必要なリソースのみを事前キャッシュに保存します。

Service Worker がアクティブで動作中になると、同一オリジン ポリシーにより、Service Worker 内で行われるクロスオリジン リクエストも制限されます。この場合は、CORS を使用することが推奨されます（こちらをご覧ください）。Service Worker 内のリソースを取得する際に no-cors モードを使用することはおすすめしません。

権限

権限のスコープもオリジンに限定されます。つまり、ユーザーがオリジンの https://section.example.com に特定の権限を付与しても、その権限が他のオリジン（https://www.example.com など）に引き継がれることはありません。

オリジン間で権限を共有する方法はないため、唯一の解決策は、特定の機能（位置情報など）が必要なサブドメインごとに許可を求めることです。ウェブプッシュなどでは、許可の再リクエストを避けるために、別のサブドメインのユーザーが許可したかどうかを追跡するために Cookie を保持できます。

インストール

PWA をインストールするには、各オリジンに、それ自体に対する相対的な start_url を指定した独自のマニフェストが必要です。つまり、特定のオリジン（例: https://section.example.com）でインストール メッセージを受け取ったユーザーは、別のオリジン（例: https://www.example.com）で start_url を使用して PWA をインストールできません。つまり、サブドメインでインストール メッセージを受け取ったユーザーは、アプリのメイン URL ではなく、サブページに対してのみ PWA をインストールできます。

また、各サブドメインがインストール条件を満たし、PWA のインストールを求める場合、同じユーザーがサイトを移動する際にインストールを促すメッセージが複数回表示されるという問題もあります。

この問題を軽減するには、プロンプトがメインのオリジンでのみ表示されるようにします。ユーザーが訪問したサブドメインがインストール条件を満たしている場合:

1. beforeinstallprompt イベントをリッスンする。
2. プロンプトが表示されないようにして、event.preventDefault() を呼び出します。

こうすることで、サイトの意図しない部分にメッセージが表示されないようにしながら、メインのオリジン（ホームページなど）では引き続き表示させることができます。

スタンドアロン モード

スタンドアロン ウィンドウでの移動中に、PWA のマニフェストで設定されたスコープの外に移動すると、ブラウザの動作が異なります。この動作は、ブラウザのバージョンとベンダーによって異なります。たとえば、最新バージョンの Chrome では、ユーザーがスタンドアロン モードでスコープから外れると、Chrome カスタムタブが開きます。

ほとんどの場合、解決方法はありませんが、サブドメインでホストされている操作の一部（ログイン ワークフローなど）には回避策を適用できます。

1. 新しい URL https://login.example.com は全画面表示の iframe 内で開くことができます。
2. ログイン プロセスなどのタスクを iframe 内で完了すると、postMessage() を使用して、iframe から得た結果の情報を親ページに返すことができます。
3. 最後のステップとして、メッセージがメインページで受信されると、リスナーの登録が解除され、iframe が DOM から削除されます。

注意: 前述の方法では、ユーザーがサブドメインで操作を実行してメインのオリジンに戻る場合（ログインフローなど）に、サイトのごく一部で UI が変更される可能性を軽減できますが、サブドメイン（サイト セクション全体など）でホストされている多くのページを含むパス全体に実装するには効率的な手法ではありません。

注: 信頼できるウェブ アクティビティのコンテキストでは、この問題を回避する方法として、デジタル アセット リンクを使用してすべてのオリジンを検証することをおすすめします。

おわりに

同一オリジン ポリシーでは、複数のオリジン上に構築されたサイトに対して、一貫性のある PWA エクスペリエンスを実現するため、多くの制限が課されます。そのため、ユーザーに最適なエクスペリエンスを提供するため、サイトをオリジンごとに分割しないことを強くおすすめします。

この方法ですでに構築されている既存のサイトの場合、マルチオリジン PWA を正しく機能させることが難しい場合がありますが、考えられる回避策をいくつか検討しました。それぞれにトレードオフが伴うため、ウェブサイトで採用するアプローチは慎重に判断してください。

長期的な戦略やサイトの再設計を評価する際は、マルチオリジン アーキテクチャを維持する重要な理由がない限り、単一オリジンへの移行を検討してください。

Penny Mclachlan、Paul Covell、Dominick Ng、Alberto Medina、Pete LePage、Joe Medley、Cheney Tsai、Martin Schierle、Andre Bandarra に深く感謝します。